DMARC는 2012년부터 존재해 왔습니다. 이는 수신 메일 서버에 귀하의 도메인으로부터 인증되지 않은 이메일이 도착했을 때 어떻게 처리할지(보고, 격리 또는 즉시 거부)를 알려주는 무료 DNS 레코드입니다. 이는 주로 가시적인 From 주소에서 도메인이 무단으로 사용되는 것을 방지하는 데 중점을 둡니다. 유사 도메인(lookalike-domain) 등록, 표시 이름 스푸핑(display-name spoofing), 또는 탈취된 정상 계정에서 발송되는 피싱 이메일을 차단하지는 못합니다. 14년이 지난 지금, 우리는 2026-04-14부터 2026-07-28 사이에 CipherCue가 추적하는 엔티티 세트에 포함된 67,336개 도메인의 DNS 레코드를 확인했습니다. 이는 CipherCue 데이터셋의 스냅샷이며, 전 세계 모든 기업을 통계적으로 대표하는 표본은 아닙니다. 코호트(cohort)가 구축된 방식은 아래의 방법론 노트를 참조하십시오. 이 중 30,362개(45.1%)는 여전히 레코드가 없습니다.

레코드가 있는 도메인들도 상황이 크게 나아지지는 않았습니다. 실제로 무언가를 강제(enforce)하는 도메인은 10,963개(레코드가 있는 도메인의 29.7%)에 불과합니다: p=reject 설정 시, 인증에 실패한 메일은 폐기됩니다. 10,258개(27.7%)는 p=quarantine 상태로, 스팸함으로 이동하지만 차단되지는 않습니다. 가장 큰 단일 그룹인 15,709개 도메인(42.5%)은 p=none으로 설정되어 있습니다. p=none 정책은 인증 데이터와 집계 보고서(aggregate reports)를 수집하지만, 수신 메일 시스템에 DMARC 인증에 실패한 메시지를 격리하거나 거부하도록 요청하지는 않습니다. 본 분석에서 강제(enforcement)란 p=quarantine 또는 p=reject 정책을 게시하는 것을 의미하며, p=none을 사용하는 도메인은 미강제(non-enforcing)로 분류됩니다.

p=none은 일반적으로 강제 단계로 넘어가기 전의 일시적인 모니터링 단계로 의도되었으며, 보통 몇 주 정도 지속됩니다. 표준이 출시된 지 14년이 지났음에도 불구하고, 우리 데이터에서 가장 큰 단일 그룹에게는 이것이 영구적인 상태처럼 보입니다.

두 수치를 종합하면 단일 수치보다 더 극명한 그림이 그려집니다: 우리가 확인한 67,336개 도메인 전체 중 46,071개(68.4%)가 DMARC 레코드가 없거나 정책을 강제하지 않는 레코드를 가지고 있습니다. 이 데이터셋에서 DMARC 레코드를 게시하는 것은 더 이상 주요 채택 격차(adoption gap)가 아닙니다. 모니터링에서 강제로 넘어가는 것이 핵심 격차입니다.

정책 세부 분석 전문

p=none이 진전되지 않는 이유

일반적인 설명은 관성 또는 무지입니다. 하지만 우리의 데이터는 더 구체적이고 기계적인 원인을 가리킵니다. 즉, 실제로 무엇이 메일을 보내고 있는지 아무도 알 수 없다는 점입니다.

DMARC의 보고 플래그(reporting flag)가 활성화된 모든 도메인은 인증 통과 여부와 관계없이 해당 도메인을 사칭하여 메일을 보낸 모든 소스를 나열하는 일일 집계 보고서(rua=)

)를 받습니다. 강제 적용(enforcement) 단계로 넘어간다는 것은 해당 목록을 검토하며 소스별로 "네, 이건 우리가 보내는 게 맞습니다" 또는 "아니요, 차단하세요"라고 결정하는 것을 의미합니다. 우리는 36,974개의 DMARC 레코드에서 원시 rua=

주소를 추출하여 보고서가 실제로 어디로 전송되는지 집계했습니다.

그중 일부는 몇몇 명확한 곳에 집중되어 있습니다. Proofpoint의 자체 보고 엔드포인트(reporting endpoint)가 1,605회, Cloudflare가 1,273회 나타났으며, dmarcian의 다양한 지역별 엔드포인트(ag.eu.dmarcian.com
, ag.us.dmarcian.com
, 그리고 8개의 국가 코드 변형)를 합치면 1,000회가 넘습니다. 그리고 Brevo, Postmark, Barracuda, 그리고 여러 DMARC-as-a-service 벤더들(EasyDMARC, PowerDMARC, dmarcian, Red Sift, DMARC Analyzer, dmarcly, sdmarc.net, hornetdmarc.com)이 나머지의 대부분을 차지합니다.

하지만 진짜 발견은 롱테일(long tail)에 있습니다. 상위 약 60개의 도메인을 넘어서면, 주소들은 더 이상 식별 가능한 벤더가 아니라 일회성이고 종종 해시(hashed) 처리된 메일함 이름으로 나타나기 시작합니다: ivrejeuw@ag.c1.dmarcian.com
, a.8hyzr404@sdmarc.net
, 2fa9a7572f@rua.easydmarc.eu
, 자체 도메인에서 보고서를 셀프 호스팅하는 기업(dmarc@axa.com
, rua@lseg.com
), 또는 아무런 단서도 주지 않는 메일함(watchdog@watchdog.kevlarr.io
) 등이 그 예입니다. 이러한 보고서를 일주일 치나 들여다보고 있는 관리자는 벤더 목록을 보고 있는 것이 아닙니다. 그들은 명확한 소유자가 없는 IP 주소와 발신자 문자열 더미를 보고 있으며, 강제 적용을 하려면 이들 각각을 먼저 식별해야 하는 상황에 놓여 있습니다.

그것은 설정 변경이 아니라 연구 과제이며, 무기한으로 우선순위가 밀려나는 종류의 작업입니다. 우리는 이것이 위에서 언급한 p=none 수치가 이토록 높은 가장 큰 단일 이유라고 생각합니다.

누가 DMARC 모니터링을 수행하는가

우리는 우리가 확신을 가지고 식별할 수 있는 DMARC 모니터링 및 메일 인프라 (mail-infrastructure) 제품을 다루는 벤더 사전 (vendor dictionary)을 기준으로 rua= 보고 주소 (reporting-address) 도메인을 매핑했습니다. 이는 단일 사실 유형과 대조하는 것보다 다르고 더 넓은 측정 방식입니다. 사전 구축된 벤더 사전만 사용했을 때의 1,400개와 비교하여, 이 방식은 29개의 명명된 목적지에 걸쳐 8,862개의 식별된 엔티티 (entities)를 포착합니다. 이는 여전히 최솟값(floor)일 뿐, 최댓값(ceiling)은 아닙니다. 우리가 확신을 가지고 귀속시킬 수 있는 도메인만을 집계했기 때문입니다. 위에서 설명한 8,113개의 일회성 목적지들은 단 한 번의 발생만으로는 벤더의 이름을 확신할 수 없기에 여기에서 제외되었습니다.

이 표를 읽을 때는 표 자체에 담을 수 없는 주의 사항이 필요합니다. Brevo, Cloudflare, Postmark는 Valimail, dmarcian, 또는 Red Sift와 같은 방식의 "DMARC 모니터링 벤더"가 아닙니다. 이들은 도메인 소유자가 rua=를...

자신의 플랫폼에 있는 사서함에서 확인하도록 합니다. 이는 대개 해당 플랫폼이 도메인의 아웃바운드 전송(outbound sending) 또는 DNS 제공업체이기 때문이지, 도메인 소유자가 해당 업체로부터 전용 모니터링 제품을 구매했기 때문이 아닙니다. 핵심 제품이 DMARC 모니터링인 벤더들로 범위를 제한하면, Valimail, DMARC Analyzer, dmarcian, DMARC Advisor, EasyDMARC, Red Sift, PowerDMARC, 그리고 Fortra (Agari)가 식별된 8,862개 엔티티 중 3,619개(40.8%)를 차지합니다. 이 더 좁은 기반 내에서 Valimail은 29.5%로 가장 큰 단일 벤더이며, DMARC Analyzer(16.6%)와 dmarcian(16.1%)이 그 뒤를 잇고 있습니다. 어느 벤더도 과반을 점유하고 있지는 않지만, 시장이 균등하게 분할되어 있지도 않습니다.

국가별 분석

강제(Enforcement) 단계는 국가마다 다릅니다. 폴란드는 이 코호트(cohort) 내에서 DMARC 레코드가 전혀 없는 도메인의 비중이 가장 높습니다. 영국은 레코드가 없는 도메인의 비중이 가장 낮지만, 레코드가 존재하는 경우 그에 상응하여 더 높은 강제율을 보입니다.

DMARC 외에 누락된 것들

DMARC는 단독으로 작동하지 않습니다. SPF와 DKIM은 DMARC가 그 위에 구축하는 두 가지 인증 메커니즘(authentication mechanisms)입니다. MTA-STS, DNSSEC, 그리고 BIMI는 관련은 있지만 별개의 문제를 다루는 세 가지 인접한 DNS 기반 제어 수단입니다. 우리는 동일한 67,336개 도메인 코호트를 대상으로 이 다섯 가지를 모두 확인했습니다.

SPF는 여기서 가장 널리 채택된 제어 수단이며, 이는 SPF가 가장 오래되었고 구성하기 가장 간단하다는 점(보고 인프라가 필요 없는 단일 DNS TXT 레코드)과 일치합니다. SPF를 사용하는 48,962개 도메인 중 25,657개(52.4%)는 하드 페일 (hard fail, -all)을 사용하고, 21,103개(43.1%)는 소프트 페일 (soft fail, ~all)을 사용합니다. 이 둘의 차이는 SPF 검사를 통과하지 못한 메일에 대해 "거부(reject)"할 것인지, 아니면 "표시하되 수락(flag but accept)"할 것인지의 차이입니다.

MTA-STS와 BIMI는 모두 3% 미만입니다. DNSSEC는 이 코호트에서 검증된 도메인이 0개로 나타났는데, 우리는 이를 연구 결과라기보다는 측정상의 주의 사항 (measurement caveat)으로 표시합니다. CipherCue의 현재 DNSSEC 검사는 전체 서명 체인 (full signing chain)을 검증하며, DNSKEY 또는 RRSIG 레코드의 존재 여부만 확인하는 더 느슨한 검사보다 더 엄격한 검사가 더 적은 통과율을 보일 것입니다. 우리는 0.0%라는 수치를 코호트 내의 어떤 도메인도 DNSSEC를 전혀 구성하지 않았다는 주장으로 제시하지는 않을 것입니다. 다만 우리의 검사에서 전체 체인 검증을 통과한 도메인이 하나도 없다고 자신 있게 말할 수 있으며, 검사 자체를 감사하기 전까지 실제 채택률은 미지수 (open question)로 취급합니다.

이 기술의 배경이 되는 RFC, 그리고 최근의 변화

DMARC의 핵심 사양은 2026년에 변경되었습니다. 2015년 3월에 정보 제공용 산업 작성 문서로 발표되었던 기존 DMARC 사양인 RFC 7489는 2026년 5월에 발표된 세 가지 새로운 IETF 문서에 의해 폐기(obsoleted)되었습니다:

• RFC 9989: 핵심 DMARC 프로토콜
• RFC 9990: 집계 보고 (aggregate reporting, 이 기사에서 다루는 rua= 보고서)
• RFC 9991: 실패 보고 (failure reporting, ruf=)

실질적인 의미는 DNS 레코드에 새로운 태그가 추가되는 것보다는 그 위상에 관한 것입니다. RFC 7489는 정보 제공용 (Informational)으로서 독립 제출 (Independent Submission) 스트림을 통해 발표되었으며, 이는 IETF 워킹 그룹의 합의를 거치지 않았음을 의미합니다. 반면 RFC 9989는 표준 트랙 (Standards Track, 제안 표준)으로, DMARC가 처음으로 공식적인 IETF 표준 지위를 갖게 되었습니다. 여러분이 이미 사용 중인 태그인 v=, p=, sp=, rua= 등은...

, ruf=

, adkim=

, aspf=

, 그리고 fo=

는 기존의 의미를 그대로 유지하며, 현재 여러분이 변경해야 할 사항은 없습니다.

실질적인 메커니즘의 변화는 단 하나로, 수신자가 자체적인 DMARC 레코드가 없는 서브도메인(subdomain)에 대해 어떻게 "조직 도메인(organisational domain)"을 찾아내는지에 관한 것입니다. RFC 7489는 Public Suffix List를 사용했습니다. 이는 커뮤니티에서 관리하는 파일로, 어떤 도메인 접미사가 등록 가능한 것인지(예를 들어, co.uk가 회사가 아니라 접미사라는 점을 아는 것)를 정의합니다. RFC 9989는 이를 DNS 트리 워크(DNS Tree Walk)로 대체합니다. 즉, 수신자가 정확한 송신 도메인에서 DMARC 레코드를 확인한 다음, 레코드를 찾거나 레이블(label)이 소진될 때까지 각 상위 도메인을 확인하며 도메인 트리를 따라 올라가는 방식입니다. 이를 통해 DNS 자체의 일부가 아닌, 외부에서 관리되는 리스트에 대한 의존성을 제거합니다.

성숙도에 대한 맥락을 위해 이 글에서 언급된 인접한 두 표준을 살펴보면 다음과 같습니다. RFC 8461 (MTA-STS)은 2018년 9월부터 완전한 IETF 인터넷 표준(Internet Standard)이었습니다. 반면, BIMI는 IETF 작업 그룹(working group)에 채택된 적이 없습니다. 이 글 작성 시점을 기준으로 최신 버전은 개별 인터넷 초안(Internet-Draft, 2026년 5월 기준 버전 14)이며, 여기에는 "IETF 표준 프로세스에서 공식적인 지위를 갖지 않음"이라고 명시되어 있습니다. 이러한 지위의 격차는 우리 데이터에서 SPF의 채택률이 72.7%인 것에 비해 BIMI가 2.6%에 머물러 있는 타당한 이유 중 하나입니다. 완성된 사양(specification)이 없고 추가적인 인증 비용(BIMI는 소수의 기관으로부터 Verified Mark Certificate를 요구함)이 발생하는 통제 항목을 구현하는 것은, 비준된 표준에 따른 DNS TXT 레코드를 구현하는 것보다 설득하기가 더 어렵기 때문입니다.

SOC 2 또는 ISO 27001이 이를 요구합니까?

SOC 2나 ISO 27001 모두 DMARC를 특정 명칭의 통제 항목으로 보편적으로 요구하지는 않습니다. 조직은 이메일 인증, 사칭(impersonation) 및 도메인 남용 방지를 위한 위험 기반 통제(risk-based controls)의 일부로 DMARC를 여전히 구현할 수 있습니다.

SOC 2는 고정된 기술적 체크리스트가 아니라 AICPA의 신뢰 서비스 기준(Trust Services Criteria)을 중심으로 구축되었습니다. 감사인은 기업이 선택한 통제 항목(controls)이 기준(가장 흔하게는 보안(Security), 때로는 가용성(Availability), 기밀성(Confidentiality), 처리 무결성(Processing Integrity) 또는 개인정보 보호(Privacy))을 충족하는지 평가합니다. 기업은 자체적으로 통제 항목을 선택하며, DMARC는 기준 문서에 명시된 예시 중 하나가 아닙니다.

ISO 27001:2022도 동일한 방식으로 작동합니다. 부속서 A(Annex A) 통제 항목 5.14인 정보 전송(Information Transfer)은 조직 내부 및 제3자와의 정보 이동을 규정하는 "규칙, 절차 또는 합의"를 요구하며, 이는 이메일 인증(email authentication)을 명시하지 않고도 이를 포괄할 수 있을 만큼 충분히 광범위합니다. 2022년 개정판은 2013년 버전(이전 조항 8.7.1부터 8.7.4까지)에서 네 개의 별도 통제 항목이었던 것을 이 단일 통제 항목으로 통합했습니다.

이것이 하나의 도메인에 적용되는 모습

영국의 식품 생산 업체인 Cranswick(cranswick.co.uk)은 데이터셋에 포함된 실제 사례입니다. 이 회사의 DMARC 레코드는 p=none입니다.