어느 날 자기 회사 도메인에서 온 것처럼 보이는 수상한 메일이 자기 받은편지함에 떨어진다. 먼저 — 숨을 고르라. 대부분의 경우 이것은 침입이 아니라 발신자 위조다. 구분하는 법과 막는 법을 본다(공격 절차 없음).
먼저, 안심: 스푸핑 ≠ 점령
이것이 핵심 오해다. 이메일 봉투의 "발신자"는 보내는 사람이 자유롭게 쓸 수 있다. 그러니 당신의 도메인 이름이 적힌 메일 한 통이 집이 털렸다는 뜻은 아니다.
다만, 진짜로 침해된 메일박스가 불가능한 것은 아니다. 둘을 구분하는 방법은 헤더를 읽는 것이다.
헤더로 "침해"와 "위조"를 구분하라
본문 뒤에서 모든 메일은 "헤더" — 배달 기록 — 를 지닌다(Gmail에서는 "원본 보기"). 다섯 필드가 가장 중요하다.
| 헤더 | 볼 것 | 읽는 법 |
|---|---|---|
| Authentication-Results | spf= / dkim= / dmarc= 결과 | dmarc=fail은 "진짜 인증을 통과 못 함 = 위조 가능성 높음"을 뜻함 |
| Received (스택) | 맨 아래 줄 = 진짜 출발점 | 자기 호스트가 아닌 곳에서 떠났다면 외부 위조 |
| Return-Path (봉투 발신자) | 보이는 From과 일치하나? | 불일치는 위조 신호 |
| Reply-To (회신 대상) | 회신이 실제로 가는 곳 | From은 내부처럼 보이는데 Reply-To가 무관한 외부 주소 → 회신하게 만드는 함정 |
| X-Mailer (발송 소프트웨어) | 멀쩡한 이름인가? | 무작위 횡설수설 = 자동 스팸 도구의 지문 |
Reply-To는 사람들이 놓치는 것이다. From은 동료와 똑같아 보여도, 회신이 완전히 다른 외부 주소로 날아가 — 거기서 시크릿이나 연락처(채팅 QR 코드 등)를 회신하게 해 당신의 소통 채널을 가로채려 한다. From을 겉모습만으로 믿지 않는 것이 가장 강력한 사람 측 방어다(→ 피싱이란 무엇인가).
애초에 받은편지함에 도달하는 이유
위조 메일이 스팸함도 아닌 받은편지함에 슬쩍 들어오는 것은 — 수신 측에 가짜를 거부할 근거가 없기 때문이다.
DMARC 정책 부재
도메인에 DMARC 정책이 없으면, 수신 측은 From 위조를 감지할 수는 있어도 거부하도록 강제될 수 없다. 이것이 받은편지함에 도달하는 가장 큰 단일 이유다.
'느슨한' SPF 설정
SPF가 ~all(softfail = "수상하나 거부는 말 것")로 끝나면, 수신 측은 떨어뜨릴 결정적 이유가 없다.
전달이 SPF를 깨뜨림
받은 메시지를 다른 주소로 전달하면, SPF는 전달 서버에 대해 "pass"처럼 보이는 반면 From은 다른 도메인으로 남는다. 그 불일치를 최종적으로 판정하는 것이 DMARC다.
여기서 DKIM이 제 값을 한다. SPF는 전달을 거치며 깨지지만, DKIM 서명은 살아남는다. 그래서 reject에 도달했을 때 정상 메일이 잘못 떨어지지 않게 하는 생명줄이 DKIM이며 — 바로 그래서 DKIM을 토대로 가장 먼저 설정한다.
해법: SPF → DKIM → DMARC, 단계적으로
작동 원리는 SPF / DKIM / DMARC란 무엇인가에 있다. 여기서는 안전한 순서만 다룬다. 철칙: 절대 reject로 바로 가지 마라.
올바른 SPF 레코드 하나
DKIM 서명 켜기(토대)
DMARC를 p=none(모니터링만)으로 시작
p=none 더하기 보고서 수집으로 시작해, 1~2주간 정상 메일이 떨어지지 않는지 지켜보라.끝까지 reject로 올리기
p=quarantine → p=reject로 가라. "위조가 수신 측에서 거부됨"이 달성될 때 비로소 이런 메일이 표적의 받은편지함에 닿기 전에 사라진다."빠진 조각"은 도메인마다 정반대다
여러 도메인을 점검해보면 빈틈이 흔히 거울상임을 알게 된다 — 발송 구성이 다르면 서비스가 대신 채워주는 부분도 다르기 때문이다.
메일 서비스 구성
- 예: 트랜잭션 메일을 외부 발송 서비스로 보냄
- 온보딩 시 DKIM / DMARC가 자동 구성되는 경향
- 하지만 SPF는 직접 DNS에 추가해야 함 → 그게 빈틈
호스팅 기본 구성
- 예: 호스팅 서버에서 직접 메일 발송
- SPF는 보통 처음부터 있음
- 하지만 DKIM은 수동 토글, DMARC는 직접 게시 → 그 둘이 빈틈
둘 다 "셋이 다 있는 것은 아님" — 빈틈이 거울상일 뿐이다. 첫 단계는 내 도메인이 어느 패턴인지 아는 것이다.
본 사이트의 견해: 설정함은 멈춤이 아니다 — 검증해야 작동한다
본 사이트는 이메일 인증을 "설정하고 잊는 것"이 아니라 검증해야 비로소 작동하는 것으로 다룬다. SPF / DKIM / DMARC 점검기나 사이트 보안 점검으로 자기 도메인의 현재 상태를 한 번에 확인할 수 있다. 값 하나에도 함정이 있다 — 예컨대 실패 보고 주소(ruf)가 없는 레코드에 fo를 넣으면, 규격상 그냥 무시되는 죽은 태그가 된다. 이런 "무해하지만 무의미한" 설정은, 검토에서만 잡히는데 흔하다. 그리고 진짜 목표는 두 층이다: 수신 측이 위조를 거부하게(DMARC) 하고 사람이 함정에 회신하지 않게 하는 것. 탐지나 설정보다, 구조로 막는 설계를 먼저 두라.
다음으로 읽기
- 용어집: SPF / DKIM / DMARC란 무엇인가(작동 원리)
- 용어집: 피싱이란 무엇인가
- 도구: SPF / DKIM / DMARC 점검기 / 사이트 보안 점검
- 관련: 다중 인증(MFA) 가이드
FAQ
Q내 도메인을 쓴 메일이 도착했는데, 서버가 해킹된 건가요?
보통 아닙니다. 이메일 전송(SMTP)은 발신자가 From 줄을 자유롭게 쓰게 합니다. 봉투 뒷면에 남의 주소를 적는 것처럼, 누구나 당신의 서버를 건드리지 않고도 '당신의 도메인으로' 메일을 보낼 수 있습니다. 그러니 그런 메일을 받았다고 침해된 것은 아닙니다. 실제로 침해됐는지 단지 위조됐는지는 메시지 헤더를 읽으면 알 수 있습니다.
Q위조 메일이 스팸으로 표시되지도 않고 받은편지함에 도달하는 이유는 무엇인가요?
수신 측에 가짜를 거부할 근거가 없기 때문입니다. 도메인에 DMARC 정책이 없으면, 수신 측은 From 위조를 감지할 수 있어도 거부하도록 강제될 수 없습니다. 전달(forwarding)은 결과를 더 흐립니다. 해법은 SPF, DKIM, DMARC를 설정하고 DMARC를 단계적으로 p=reject까지 올리는 것입니다.
Q어디서부터 시작하면 되나요?
먼저 도메인의 현재 상태를 확인하세요(SPF/DKIM/DMARC 점검기가 한 번에 보여줍니다). 그런 다음 reject로 바로 가지 말고, DMARC를 p=none(모니터링만)으로 시작해, 보고서에서 정상 메일이 떨어지지 않음을 확인한 뒤에야 p=quarantine → p=reject로 옮기세요. DKIM을 먼저 켜세요. DKIM 서명은 reject에 도달했을 때 전달을 거쳐도 정상 메일을 통과시키는 생명줄이기 때문입니다.