DMARC 적용 격차 지속: 2026년 기업 도메인의 68.4%가 적용 미비

DMARC 적용 격차 지속: 2026년 기업 도메인의 68.4%가 적용(Enforcement) 미비

개요

DMARC는 2012년부터 인증에 실패한 이메일을 수신 메일 서버가 어떻게 처리해야 하는지 알려주는 무료 DNS 레코드로 존재해 왔습니다. CipherCue가 추적한 67,336개 기업 도메인의 2026년 현황을 살펴보면, 68.4%가 DMARC 레코드가 없거나 p=none으로 설정되어 있어 quarantine(격리) 또는 rejection(거부)을 적용하지 않고 있습니다.

적용 격차 상세 내용

조사된 67,336개 도메인 중 30,362개(45.1%)는 DMARC 레코드가 없습니다. 레코드를 게시한 36,974개 도메인 중 15,709개(레코드 보유 도메인의 42.5%, 전체 도메인의 23.3%)가 p=none으로 설정되어 있습니다. 오직 10,258개 도메인(전체의 15.2%)만이 p=quarantine을 사용하며, 10,963개 도메인(전체의 16.3%)이 p=reject를 사용합니다. 따라서 총 46,071개 도메인(전체의 68.4%)이 레코드가 없거나 적용되지 않는 p=none 정책을 사용하고 있습니다.

p=none이 지속되는 이유

p=none에서 적용(Enforcement) 단계로 넘어가는 데 있어 주요 장애물은 일일 집계 보고서(rua=)를 해석하는 데 드는 노력입니다. 보고서 기능이 활성화된 각 도메인은 해당 도메인을 사칭하여 보낸 모든 소스의 목록을 받게 됩니다. 적용을 위해서는 관리자가 발신자가 정당한지 소스별로 결정해야 합니다. rua= 주소들은 소유자가 불분명한 일회성 또는 해시된 메일박스(예: ivrejeuw@ag.c1.dmarcian.com, a.8hyzr404@sdmarc.net)를 가리키는 경우가 많아, 정책 적용을 우선순위에서 밀려나는 리서치 작업으로 만듭니다.

DMARC 모니터링 주체

rua= 보고 주소 도메인을 벤더 사전과 매핑한 결과, 29개의 지정된 목적지에 걸쳐 8,862개의 엔티티가 식별되었습니다. 주요 목적지는 Brevo (1,297개 엔티티, 14.6%), Proofpoint (1,094개, 12.3%), Valimail (1,068개, 12.1%), Cloudflare (978개, 11.0%)입니다. 핵심 제품이 DMARC 모니터링인 벤더로 한정할 경우, Valimail, DMARC Analyzer, dmarcian, DMARC Advisor, EasyDMARC, Red Sift, PowerDMARC, Fortra (Agari)가 합쳐서 3,619개 엔티티(식별된 엔티티의 40.8%)를 차지합니다.

국가별 차이

해당 코호트 내에서 적용 수준은 국가별로 다릅니다:

  • 폴란드: 레코드 없음 64.6%, p=none 16.3%, p=quarantine 11.3%, p=reject 7.7%.
  • 네덜란드: 레코드 없음 51.1%, p=none 21.1%, p=quarantine 14.2%, p=reject 13.6%.
  • 독일: 레코드 없음 45.7%, p=none 26.3%, p=quarantine 12.9%, p=reject 15.0%.
  • 미국: 레코드 없음 42.1%, p=none 19.0%, p=quarantine 16.7%, p=reject 22.2%.
  • 이탈리아: 레코드 없음 40.9%, p=none 36.8%, p=quarantine 11.7%, p=reject 10.5%.
  • 영국: 레코드 없음 37.0%, p=none 19.2%, p=quarantine 18.3%, p=reject 25.5%.
  • 스페인: 레코드 없음 36.9%, p=none 29.5%, p=quarantine 18.1%, p=reject 15.5%.
  • 프랑스: 레코드 없음 43.0%, p=none 29.1%, p=quarantine 12.8%, p=reject 15.1%. (참고: 원문 데이터 중 스페인과 프랑스 중복 기재 및 수치 오류 포함) 미국과 영국은 가장 높은 p=reject 비율(22.2% 및 25.5%)을 보이는 반면, 이탈리아는 상대적으로 낮은 레코드 미보유율에도 불구하고 가장 높은 p=none 비율(36.8%)을 기록했습니다.

관련 DNS 제어 항목

DMARC 외에 해당 코호트에서 나타난 현황은 다음과 같습니다:

  • SPF 존재: 48,962개 도메인 (72.7%).
  • DMARC 존재: 36,974개 도메인 (54.9%).
  • BIMI 존재: 1,726개 도메인 (2.6%).
  • MTA-STS 존재: 957개 도메인 (1.4%).
  • DNSSEC는 전체 체인 검증(full-chain validation) 하에 0.0%를 기록했습니다; 저자들은 이것이 측정상의 한계이지, DNSSEC가 설정된 도메인이 없다는 의미는 아니라고 언급했습니다. SPF가 활성화된 도메인 중 52.4%는 hard fail (-all)를 사용하며, 43.1%는 soft fail (~all)를 사용합니다.

최근 RFC 변경 사항

2026년 5월, IETF는 RFC 7489를 대체하는 세 개의 표준 트랙 RFC를 발표했습니다:

  • RFC 9989: 핵심 DMARC 프로토콜 (현재 Standards Track, Proposed Standard).
  • RFC 9990: 집계 보고 (rua=).
  • RFC 9991: 실패 보고 (ruf=). 기존 레코드에 미치는 실질적인 영향은 미미합니다; v=, p=, sp=, rua=, ruf=, adkim=, aspf=, fo= 태그의 의미는 유지됩니다. 한 가지 실질적인 변화는 조직 도메인 발견을 위한 Public Suffix List 조회를 DNS 트리 워크(DNS tree walk)로 대체하여 외부 목록에 대한 의존성을 제거한 것입니다.

SOC 2 및 ISO 27001 고려 사항

SOC 2와 ISO 27001:2022 모두 DMARC를 명시된 제어 항목으로 보편적으로 요구하지는 않습니다. SOC 2는 조직이 선택한 제어 항목이 신뢰 서비스 기준(Trust Services Criteria)을 충족하는지 평가합니다; DMARC는 이메일 인증 리스크 관리의 일부로 사용될 수 있지만 예시로 나열되어 있지는 않습니다. ISO 27001:2022 Annex A 제어 항목 5.14 (정보 전송)은 DMARC를 구체적으로 언급하지 않고도 이메일 인증을 포괄할 수 있을 만큼 광범위합니다.

예시 도메인

Cranswick (cranswick.co.uk)은 세 개의 rua= 주소(dmarc_agg@vali.email, eu.cp-dmarc.com의 자체 등록 메일박스, rua.easydmarc.eu의 해시된 주소)와 함께 p=none 설정의 DMARC 레코드를 게시하고 있습니다. 이는 단일 도메인이 여러 관련 없는 목적지로부터 보고를 집계할 수 있음을 보여주며, 관리자가 적용(enforcement) 단계로 넘어가기 전에 이러한 스트림들을 조정해야 함을 시사합니다.

방법론 참고

데이터는 2026-04-14에서 2026-07-28 사이에 수행된 CipherCue의 자체 DNS 관측(DMARC, SPF, MTA-STS, BIMI, DNSSEC에 대한 직접 쿼리)을 통해 수집되었으며, 67,336개 도메인을 대상으로 합니다. 카운트는 중복 제거된 조직이 아닌 도메인 기준입니다; 대기업은 여러 도메인을 소유한 경우 여러 번 나타날 수 있습니다. 벤더 매핑은 40개의 알려진 rua= 보고 엔드포인트 도메인으로 수동 유지되는 사전을 사용하며, 이는 전수 조사가 아닌 최소 수치입니다. DNSSEC 결과는 전체 체인 검증 결과만을 반영합니다.

커뮤니티 인사이트 (HN 댓글)

댓글 작성자들은 몇 가지 실질적이고 인식적인 장벽을 강조했습니다:

  • 일부 소규모 운영자들은 SPF와 DKIM이 이미 잘 작동하고 있는 상황에서 DMARC의 추가적인 가치에 의문을 제기합니다.
  • 다른 이들은 DNS 변경이 종종 이해도가 낮은 직원에 의해 이루어져, p=none 상태로 남게 되는 복사-붙여넣기 설정으로 이어진다고 지적합니다.
  • 몇몇은 주요 이메일 제공업체들이 남용 보고를 무시하여 DMARC의 체감 이점이 감소한다고 주장합니다.
  • 일부는 이메일이 없는(또는 MX 레코드가 없는) 도메인이 "레코드 없음" 그룹에 포함되어 통계의 관련성을 왜곡할 수 있다고 제안합니다.
  • 몇몇 댓글 작성자들은 스팸이 종종 SPF/DKIM/DMARC를 통과하기 때문에 DMARC가 수신함 신뢰도를 높이지 못하면서 복잡성만 더한다고 주장합니다.
  • 반대로, 일부 사용자는 Terraform를 통해 DMARC 레코드를 추가하는 것을 포함하여 DNS 변경을 자동화하기 위해 LLM을 사용한다고 설명합니다. 이러한 의견들은 주요 격차가 DMARC의 존재에 대한 인지 문제가 아니라, 모니터링에서 적용 단계로 넘어가기 위해 필요한 운영 작업에 있다는 기사의 주장을 뒷받침합니다.

Sources