당신도 모르게 당신 도메인의 이름으로 피싱 메일이 나갈 수 있습니다. SPF / DKIM / DMARC가 그것을 막습니다. 각각의 역할과 안전하게 설정하는 법을 설명합니다.
각각의 역할
| 설정 | 역할 (한 줄) |
|---|---|
| SPF | 이 도메인을 위해 어느 서버가 보낼 수 있는지를 DNS에 선언 |
| DKIM | 메일이 변조되지 않았고 정당한 출처임을 증명하는 암호학적 서명을 추가 |
| DMARC | SPF/DKIM이 실패하면 무엇을 할지 선언하고 보고서를 받음 (셋을 하나로 묶는 설정) |
세 가지 모두 DNS의 텍스트(TXT) 레코드입니다. example.com이라면 다음과 같습니다(값은 예시).
| 설정 | 두는 곳 | 값의 예 |
|---|---|---|
| SPF | example.com | v=spf1 include:_spf.mail-service.example ~all |
| DKIM | selector._domainkey.example.com | v=DKIM1; k=rsa; p=(발신 서비스가 발급한 공개 키) |
| DMARC | _dmarc.example.com | v=DMARC1; p=none; rua=mailto:dmarc@example.com |
SPF의 include:에는 메일 발신 서비스가 안내하는 값을 씁니다. DKIM 공개 키도 발신 서비스가 발급하므로 직접 만들 필요는 없습니다.
메일이 검증되는 과정
수신 측(Gmail 등)은 들어온 메시지에 대해 SPF와 DKIM을 검사한 뒤, 당신의 DMARC 정책을 적용해 "통과 / 격리 / 거부"를 결정합니다.
그래서 SPF와 DKIM만으로는 "검사는 하지만 아무것도 하지 않을" 수 있고, DMARC 정책이 있어야 비로소 "위장을 막는" 일이 됩니다.
놓치기 쉬운 부분: 도메인 정렬
DMARC 판정의 핵심은 도메인이 맞아떨어지는 것입니다. 수신자가 메일 앱에서 보는 보낸 사람(From 헤더)의 도메인이 SPF나 DKIM으로 검증된 도메인과 일치할 때만 DMARC를 통과합니다.
SPF는 눈에 보이는 보낸 사람이 아니라, 배달에 쓰이는 뒤쪽 봉투 발신자의 도메인을 검사합니다. 그래서 공격자는 자기 도메인으로 SPF를 통과하면서 From 칸에만 당신의 도메인을 적을 수 있습니다. SPF가 통과해도 From 도메인과 일치하지 않고 DKIM으로도 일치가 확인되지 않으면, DMARC는 그 메일을 실패로 판정합니다. 이 일치를 확인하기 때문에 DMARC가 From 주소 위장을 막을 수 있습니다.
안전하게 설정하는 법
올바른 SPF 레코드 하나
모든 정당한 발신자(자체, 메일 서비스 등)를 허가하세요. 도메인당 SPF 레코드는 하나로 유지하세요(여러 레코드는 망가지기 쉽습니다).
DKIM 서명 활성화
메일 플랫폼에서 DKIM을 켜고 공개 키를 DNS에 게시해, 정당한 메일이 서명되게 하세요. 발신에 쓰는 서비스가 여럿이라면 각각 별도 셀렉터로 서명을 켜, 한 곳이라도 서명이 빠져 DMARC에서 탈락하는 일이 없게 하세요.
DMARC를 p=none에서 시작
곧바로 거부하지 마세요. p=none(모니터링만) + 보고로 시작해, 정당한 메일이 누락되지 않는지 확인하세요. 보고서를 받을 주소(rua)를 반드시 지정해야 무엇이 통과하고 무엇이 실패하는지 실제로 보입니다 — 주소가 없으면 p=none은 그저 켜 두기만 한 상태입니다.
점진적으로 조이기
보고서에서 누락되는 정당한 발신자가 없음이 확인되면, p=quarantine → p=reject 로 옮겨, 마침내 "위장은 거부됨"에 도달하세요.
1단계의 "하나"는 사양에서 나온 것입니다. RFC 7208은 한 도메인에 SPF 레코드가 둘 이상 있으면 결과가 permerror(영구 오류)가 된다고 정합니다. 같은 사양은 include 등에 의한 DNS 조회를 평가 전체에서 10회로 제한하며, 넘어도 permerror입니다. 메일 서비스를 추가할 때는 레코드를 새로 만들지 말고 기존의 레코드 하나에 덧붙이세요.
흔한 실수
| 실수 | 일어나는 일 | 고치는 법 |
|---|---|---|
| SPF 레코드가 두 개 | SPF가 permerror를 돌려준다 | 하나로 합친다 |
중첩된 include가 너무 많음 | DNS 조회가 10회를 넘어 permerror | 쓰지 않는 서비스의 include를 지운다 |
| 발신 서비스에서 DKIM을 켜지 않음 | 그 서비스에서 보낸 메일이 DMARC에 실패한다 | 서비스에서 DKIM을 켜고 DNS에 게시한다 |
| DMARC를 p=none에 방치 | 위장 메일이 계속 통과한다 | 보고서를 읽고 reject까지 올린다 |
| 메일을 보내지 않는 도메인에 아무 설정도 없음 | 쓰지 않는 그 도메인의 이름을 쓴 위장을 막을 수 없다 | v=spf1 -all과 DMARC p=reject를 게시한다 |
내 도메인에서 확인하는 방법
- SPF / DKIM / DMARC 검사에 도메인을 입력해 세 레코드가 있는지, 무엇이 잘못되었는지 확인합니다
- 명령줄에서 직접 보려면
dig +short TXT example.com(SPF)과dig +short TXT _dmarc.example.com(DMARC)을 실행합니다 - 내 도메인에서 Gmail 주소로 메일을 보내고, Gmail의 "원본 보기"에서
SPF,DKIM,DMARC가 모두PASS인지 확인합니다 - DMARC 보고서(rua)가 오기 시작하면 매주 모르는 발신자가 없는지 확인합니다
소유를 확인한 사이트라면 사이트 보안 점검이 웹 쪽 설정과 함께 이것들을 검사합니다.
실제 사례: "내 주소에서 온" 위장 메일
"내 주소에서 나에게 협박 메일이 왔다"는 일본 IPA 등이 주의를 환기해 온 전형적인 사례입니다. 대부분은 계정 탈취가 아니라 보낸 사람 칸을 바꿔 쓴 것뿐입니다. 보낸 사람 칸에는 무엇이든 쓸 수 있으므로, DMARC를 reject까지 올리지 않은 도메인이라면 이런 메일이 받은편지함에 도착할 수 있습니다. 구별하는 법과 대처법은 다음에서 다룹니다.
- 내 주소에서 온 스팸(영문)(해킹당했는지 5분 만에 확인)
- 내 도메인을 사칭한 메일(헤더 읽는 법과 SPF·DKIM·DMARC로 막는 법)
사양 개정(2026년 5월)
DMARC는 2026년 5월 RFC 9989로 개정되어, 이전의 RFC 7489를 대체했습니다. p=none, p=quarantine, p=reject의 세 가지 정책은 바뀌지 않았습니다. 바뀐 점은 pct 태그(적용 비율)가 없어지고 테스트 모드를 나타내는 t 태그로 대체된 것, 그리고 존재하지 않는 서브도메인에 대한 정책을 정하는 np 태그가 추가된 것입니다. 기존 레코드가 하루아침에 동작을 멈추지는 않지만, 새로 작성할 때는 pct를 쓰지 마세요.
본 사이트의 견해: 당신의 사용자도 함께 지키는 것이다
SPF/DKIM/DMARC는 당신의 메일이 도착하는 것만의 문제가 아닙니다. 당신의 도메인을 사칭하는 피싱으로부터 당신의 사용자를 지킵니다. 피싱은 결국 자격 증명과 키 탈취하는 수단입니다. 많은 도메인이 SPF/DKIM에서 멈추고 DMARC를 집행(reject)까지 올리지 않습니다. p=none에서 멈추지 말고, 보고서를 읽고 reject까지 끝까지 올려야 의미가 있습니다.
출처(1차 자료)
- IETF RFC 7208, "Sender Policy Framework (SPF)" — datatracker.ietf.org(도메인당 레코드 하나, DNS 조회 최대 10회)
- IETF RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures" — datatracker.ietf.org
- IETF RFC 9989, "Domain-Based Message Authentication, Reporting, and Conformance (DMARC)"(2026년 5월, RFC 7489를 대체) — datatracker.ietf.org
- Google, "Email sender guidelines" — support.google.com(2024년 2월 1일부터의 요건, 하루 5,000통 이상 발신자의 요건)
다음으로 읽기
- 대처: 위장 메일을 구별하고 막기 · 내 주소에서 온 스팸(영문)
- 용어집: 피싱이란 · .env란
- 도구: SPF / DKIM / DMARC 검사