정의
DMARC(Domain-based Message Authentication, Reporting, and Conformance)는 도메인 소유자가 DNS에 기계 가독 정책을 게시해, 들어오는 메시지가 SPF나 DKIM 정렬 검사에서 실패할 때 수신 메일 서버가 어떻게 처리해야 할지를 선언하고, 수신 서버가 도메인 소유자에게 구조화된 보고를 다시 보낼 수 있게 하는 확장 가능한 이메일 인증 메커니즘입니다. DMARC의 세 가지 정책 값 — none, quarantine, reject — 은 도메인 소유자에게 자신의 도메인에서 온 것으로 보이는 인증되지 않은 이메일이 글로벌 수신 인프라에서 어떻게 처리될지에 대한 단계적 통제권을 제공합니다.
DMARC는 PayPal, Google, Microsoft, Yahoo, ReturnPath를 비롯한 이메일 생태계 이해관계자 그룹이 협력해 개발했고, 2015년 3월 IETF RFC 7489로 처음 발표되었습니다. 사양은 DMARC.org 워킹 그룹이 유지 관리합니다. SPF(RFC 7208)와 DKIM(RFC 6376)이라는 기존 두 인증 표준을 확장하고 조율합니다. 두 표준을 입력 신호로 사용하지만 대체하지는 않습니다.
작동 방식
DMARC 정책은 _dmarc.<도메인>에 DNS TXT 레코드로 게시됩니다. 대표적인 레코드는 다음과 같습니다. v=DMARC1; p=quarantine; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100; adkim=s; aspf=s. 주요 태그는 다음과 같습니다.
v=DMARC1— 버전 식별자p=— 정책:none(모니터링만),quarantine(스팸/정크함으로 전달),reject(메시지를 완전히 폐기)rua=— 집계 보고 수신 URI; 참여 메일박스 공급자로부터 인증 결과의 일일 XML 요약을 받습니다ruf=— 포렌식 보고 수신 URI; 개별 실패에 대해 편집된 메시지 수준 보고를 받습니다pct=— 정책이 적용되는 메시지의 비율(단계적 출시를 가능하게 함)adkim=과aspf=— 정렬 모드:s(strict, 정확한 도메인 일치 필요) 또는r(relaxed, 서브도메인 일치 허용)
DMARC가 도입한 핵심 혁신은 식별자 정렬입니다. SPF 통과나 DKIM 통과는 인증된 도메인이 RFC5322.From 헤더 도메인 — 이메일 사용자가 보는 “From:” 주소 — 과 정렬될 때만 DMARC를 준수한다고 간주됩니다. 이는 SPF와 DKIM이 독립적으로 작동할 때 남는 틈을 막습니다. 메시지가 다른 도메인(envelope sender)에서 SPF를 통과하고 외부 서명 도메인에서 DKIM을 통과하더라도, From 헤더가 다른 도메인을 보여주면 여전히 부정 메시지일 수 있습니다. DMARC는 SPF나 DKIM 중 적어도 하나가 정렬된 통과를 만들 것을 요구합니다.
집계 보고(RUA)는 보통 보고 기간 종료 후 24시간 안에 압축된 XML 파일로 Google(Gmail), Microsoft(Outlook/Exchange Online Protection), Yahoo Mail, Apple iCloud Mail, Comcast 등 메일박스 공급자가 전송합니다. 이 보고에는 출발지 IP별 메시지 수, SPF 결과, DKIM 결과, DMARC 처리 결과가 포함됩니다. DMARCIAN, Valimail, Postmark DMARC Digests, Google Postmaster Tools 같은 도구가 이런 보고를 파싱하고 시각화하는 대시보드를 제공합니다.
어디에서 마주치게 되나
DMARC는 대량이거나 고위험 이메일 발송이 있는 곳이라면 어디서나 등장합니다. 2024년 2월부터 Google과 Yahoo는 Gmail이나 Yahoo Mail 주소로 하루 5,000개를 넘는 메시지를 보내는 발송자에게 최소 p=none의 DMARC 레코드를 요구합니다. 이는 대량 발송자에게 사실상 DMARC를 의무화한 의미 있는 산업 정책 변화였습니다. Microsoft는 2025년 Outlook.com 소비자 메일박스에 대해 유사한 요구를 발표했습니다.
대규모로 이메일 확인 투표를 발송하는 콘테스트 플랫폼에 DMARC는 두 가지 역할을 합니다. 첫째, 위조된 메시지를 거부하도록 수신 서버에 지시함으로써 발신 도메인의 평판을 보호합니다. 이는 제3자가 콘테스트 플랫폼의 From 주소를 피싱 캠페인에서 가장하는 것을 막아주며, 그렇지 않다면 도메인의 도달성에 손상이 갈 수 있습니다. 둘째, DMARC 집계 보고는 운영 모니터링 채널을 제공합니다. 도메인 소유자는 참여 메일박스 공급자 전반에 걸쳐 발신 메시지 중 어느 비율이 SPF와 DKIM을 통과하는지 확인하고, 대량 확인 메일 실패가 발생하기 전에 인프라 오설정을 표시할 수 있습니다.
SendGrid, Mailgun, Amazon SES, Postmark, SparkPost 같은 이메일 서비스 공급자는 자사 발송 인프라와 함께 DMARC를 구성하는 가이드를 발표합니다. MXToolbox DMARC Lookup, DMARCIAN의 DMARC Inspector, EasyDMARC의 레코드 검사기 같은 DNS 진단 도구를 사용하면 도메인 소유자가 게시된 정책을 검증할 수 있습니다.
실무 예시
한 콘테스트 회사가 새 서브도메인 confirm.votes.example.com을 사용해 확인 메일을 발송하기 시작합니다. 부모 도메인 votes.example.com은 DMARC 레코드에 p=reject가 있습니다. 새 서브도메인의 SPF와 DKIM 레코드가 아직 구성되지 않았기 때문에 확인 메일이 DMARC 정렬에 실패하고 Gmail에서 거부됩니다. 관리자는 서브도메인에서 DMARC 실패율 100%를 보여주는 집계 보고 데이터를 통해 문제를 진단하고, 적절한 SPF include와 DKIM 셀렉터 DNS 레코드를 추가한 뒤, 출시 기간 동안 일시적으로 서브도메인의 DMARC 서브도메인 정책을 sp=none으로 재설정합니다.
한 브랜드가 총상 5만 달러 규모의 사진 출품 콘테스트를 운영합니다. 어떤 사기꾼이 콘테스트 도메인을 From 주소로 사용해 피싱 메일을 보내려 하고, 유권자를 가짜 확인 페이지로 유도해 이메일 자격 증명을 가로채려 합니다. 도메인의 DMARC 정책이 p=reject이기 때문에, Gmail, Outlook, Yahoo Mail 모두 위조 메시지를 배달 전에 폐기해 콘테스트 참가자와 브랜드의 발신 평판을 모두 보호합니다.
관련 개념
DMARC는 인증 입력으로 **SPF Record**와 **DKIM**에 의존합니다. DMARC 통과는 둘 중 적어도 하나가 From 헤더 도메인과 정렬될 것을 요구합니다. 콘테스트 운영에서 SPF, DKIM, DMARC가 인박스 도달에 미치는 결합 효과는 Email Confirmation Vote 확인 메시지가 유권자의 인박스에 도달하는지를 결정하는 가장 큰 기술적 요인입니다. 인박스 클라이언트에 브랜드 로고를 표시하는 BIMI 표준은 신뢰 지표로서 p=quarantine이나 p=reject DMARC 정책을 전제 조건으로 요구합니다.
