DMARC 적용 격차: 2026년 1분기 데이터 | DMARCeye

DMARC의 핵심은 결국 적용(enforcement)입니다. 인증에 실패한 메시지를 어떻게 처리할지를 수신 메일 서버에 알려주는 레코드가 DMARC입니다. p=quarantine으로 스팸함에 보내거나, p=reject로 아예 거부하도록 지정할 수 있습니다. 이 두 정책 중 하나에 도달하기 전까지 DMARC는 단지 가시성만 제공할 뿐입니다. 유용하기는 하지만, 보호는 아닙니다. DMARCeye 모니터링 플랫폼의 2026년 1분기 데이터에 따르면, DMARC를 도입한 도메인 중 3분의 1 이상은 끝내 그 단계까지 가지 못합니다.

이 글은 DMARCeye의 2026년 1분기 산업 리포트에서 정책 분포에 관한 발견을 풀어 설명합니다. 12개 차트와 방법론을 모두 담은 전체 리포트는 아래에 있습니다.

2026년 1분기 기준, DMARC를 도입한 도메인은 어디에 머물러 있나

DMARCeye가 상시 모니터링하는 수천 개 도메인의 정책 분포는 이렇습니다.

• 36.7%가 p=none: 모니터링 전용. DMARC 레코드는 존재하지만, 인증이 실패해도 수신 서버에는 아무 조치도 지시하지 않습니다.
• 36.8%가 p=quarantine: 인증 실패 메시지가 스팸함으로 이동합니다.
• 26.5%가 p=reject: 완전 적용. 인증 실패 메시지는 거부됩니다.

모니터링 대상 도메인의 약 3분의 1은 여전히 가시성 단계에 있습니다. 완전 적용에 도달한 도메인은 4분의 1 정도에 불과합니다. 가장 큰 단일 구간은 중간 단계인 quarantine입니다.

이 수치는 이미 DMARC를 도입한 도메인을 대상으로 한 것입니다. 전체 리포트에서는 도입 그룹과 별개로, 공개된 인터넷 도메인을 대상으로 한 스캐너 샘플과도 비교합니다. 이 샘플에서는 28%의 도메인에 DMARC 레코드 자체가 아예 없었습니다.

'모니터링 전용'이 실제로 보호하는 것

p=none 상태의 DMARC 레코드는 수신 서버에 이렇게 말합니다. "메시지가 SPF와 DKIM 정렬에 실패해도 일단 전달하되, 리포트만 보내라." 도메인 소유자는 가시성을 얻습니다. 잊고 있던 서비스에서 나가는 정상 메일과, 사칭 시도가 모두 보입니다. 하지만 차단은 일어나지 않습니다. 위조된 메시지도 정상 메일과 똑같이 받은 편지함에 도착합니다.

모니터링 전용은 출발점으로는 괜찮습니다. 모니터링 데이터 없이 정책을 안전하게 강화할 수는 없으니까요. 하지만 p=none에 무기한 머물러 있다는 건, 사칭의 증거를 모으기만 하고 그에 대해 아무것도 하지 않는다는 뜻입니다.

p=none에 머무는 것이 실제로 치르는 비용

대부분의 회사에서 p=none에 머무는 데 따른 실질적 위험은 세 군데에서 나타납니다.

• 스푸핑이 받은 편지함까지 도달합니다. 여러분의 도메인을 사칭한 피싱 캠페인이 고객이나 직원의 메일함에 그대로 들어옵니다. 막을 정책이 없기 때문입니다.
• 정상 메일이 점점 스팸함으로 흘러갑니다. 수신 서버는 모니터링 전용 자체를 직접 처벌하지는 않지만, 인증에 실패한 메시지를 도메인 평판에 누적해서 기록합니다. 여러분의 이름으로 위조된 메일은 인증에 실패합니다. 공격자의 활동이 몇 주간 이어지면, 그렇게 쌓인 패턴이 정상 메일의 도달 위치에 영향을 미치기 시작합니다.
• 대량 발신자 요건은 형식적으로만 충족됩니다. Google과 Yahoo의 2024년 2월 가이드라인은 하루 5,000건 이상을 발송하는 발신자에게 DMARC 레코드를 요구합니다. 리포팅을 켜둔 p=none 레코드를 게시하면 최소 요건은 충족됩니다. 하지만 두 회사의 필터링 알고리즘은 도달 결정에 DMARC 자세를 계속 반영합니다. 게시는 되어 있지만 적용은 되지 않는 레코드는 '서류상 컴플라이언스' 단계로 분류됩니다.

주문 확인과 배송 안내를 보내는 이커머스 매장이라면 이렇게 나타납니다. 정상적인 트랜잭션 메일은 시간이 갈수록 도달이 어려워지는 한편, 위조된 메일은 여전히 고객의 받은 편지함에 꽂힙니다. 한 번 무너진 발신자 평판은 회복이 더딥니다.

왜 도메인은 p=none에 머무는가

1분기 리포트는 무엇이 일어나고 있는지를 보여줍니다. 특정 도메인이 왜 모니터링 전용에 남아 있는지는 알려주지 않습니다. 아래 이유들은 데이터셋의 결론이 아니라, 고객사들에서 반복적으로 보이는 패턴입니다. 여러분의 상황과 대조해 볼 만한 정보에 근거한 추정으로 받아들이시면 됩니다.

• 정상 메일이 깨질까 봐 걱정된다. 팀이 그 자리에 머무는 가장 흔한 이유입니다. 정책을 강화하면 팀이 문서로 남겨두지 않은 외부 서비스의 메일이 quarantine되거나 reject될 수 있습니다. 해법은 회피가 아니라 문서화입니다.
• 다음 단계에 대한 명확한 가이드가 없다. 대부분의 모니터링 도구는 가공되지 않은 집계 리포트를 그대로 보여주고, 해석은 팀에 맡깁니다. "이 도메인을 다음 단계로 옮겨도 안전한가?"에 대한 도메인별 답을 받지 못하면, 팀은 그냥 그 자리에 머무는 쪽을 택합니다.
• 담당자가 사라졌다. DMARC 모니터링을 처음 설정한 사람이 퇴사했고, 다른 누구도 스위치를 넘길 권한도, 의지도 없습니다.
• 얻을 것을 과소평가한다. 사칭 사고가 실제로 터지기 전까지, 적용은 주의를 다투는 여러 우선순위 중 하나일 뿐입니다. 한 번 터지고 나면 그것만 우선순위가 됩니다. 대부분의 팀은 어렵게 깨닫습니다.

리포트는 이 격차가 존재한다는 사실을 보여줍니다. 그 원인은 여러분의 환경에서 직접 따져볼 가치가 있습니다.

모니터링에서 적용으로 안전하게 옮겨가는 법

p=none에서 p=reject까지의 경로는 잘 정리되어 있고, 무리한 도약을 요구하지도 않습니다.

1. 최소 2~4주간 집계 리포트를 읽으세요. 여러분의 도메인을 사용해 발신되는 메일의 안정적인 그림이 필요합니다. 일회성 캠페인의 스파이크에 휘둘리면 판단을 그르칩니다.
2. 모든 정상 발신자를 인증하세요. ESP, 트랜잭션 서비스, 마케팅 플랫폼, 결제 시스템, 내부 메일 릴레이까지 전부 SPF나 DKIM에서 정렬되어 있어야 합니다. 가능하면 둘 다 맞추는 것이 좋습니다. DKIM은 포워딩에서도 살아남지만 SPF는 그렇지 않기 때문입니다.
3. 먼저 p=quarantine으로 옮기세요. 실패한 메일은 /dev/null이 아니라 스팸함으로 갑니다. 1~2주간 리포트를 지켜보세요. 정상 메일이 그대로 통과하는지 확인하세요.
4. 그다음 p=reject로 옮기세요. 2단계를 제대로 했다면, 전환은 거의 티가 나지 않습니다.

1분기 리포트의 관련 발견 한 가지. 적용 단계에 도달한 도메인 중 단계적 퍼센트 롤아웃을 위한 DMARC 내장 태그인 pct=를 사용하는 비율은 약 6%에 그칩니다. 대부분의 팀은 p=none에서 곧장 100% 완전 적용으로 건너뜁니다. 곧 나올 DMARCbis 개정안은 pct=를 아예 제거합니다. 결국 '준비를 제대로 하는 것'이 사실상 유일한 길이 됩니다.

구체적인 진행 과정이 필요하다면, DMARC 구현 완벽 가이드에서 전체 절차를 다룹니다.