p=none은 이메일 보안에서 방화문을 사서, 빨간색으로 칠한 다음, 벽돌로 열어놓는 것과 같다.

미치게 하는 건 이게 엣지 케이스가 아니라는 점이다. DMARC 배포의 기본 감정 상태가 이렇다. 사람들은 도메인이 “DMARC가 있다”고 말하면 이야기가 끝난 것처럼 행동한다. 끝이 아니다. p=none인 DMARC 레코드는 수신 서버에게 리포트 수집하고 그대로 진행하라고 말한다. 격리 없음. 거부 없음. 집행 없음.

정당한 임시 단계가 될 수 있다.

임시라는 말을 다들 잊는다.

p=none이 실제로 하는 일

리포팅한다. 그게 전부다.

DMARC에는 세 가지 집행 레벨이 있다. p=none은 메일을 그냥 전달하고 리포트를 보낼 수도 있다. p=quarantine은 실패한 메일을 스팸함에 넣는다. p=reject는 완전히 차단한다. 의도된 진행 과정은 명확하다. p=none으로 데이터를 모으고, 생태계를 파악하면 p=quarantine으로, 확신이 서면 p=reject로 졸업한다.

“DMARC 채택률”이라는 표현이 미끄러운 이유다. “DMARC TXT 레코드를 게시하는 도메인이 몇 개?”라고 물으면 답이 좋아 보인다. “실제로 스푸핑된 이메일을 차단하는 도메인이 몇 개?”라고 물으면 금세 암울해진다.

RIPE Labs가 2026년 7월 스냅샷으로 Tranco 상위 100만 도메인을 분석한 결과, DMARC 레코드를 게시한 도메인은 458,467개였다. 괜찮아 보인다. 그다음 줄을 읽으면 얘기가 달라진다. 그중 뭐라도 집행하는 곳 — 모든 메일에 p=quarantine이나 p=reject를 적용하는 곳 — 은 46.9%뿐이었다. 데이터 전체에서 가장 흔한 DMARC 레코드는 맨몸의 v=DMARC1; p=none;이었다. 집행 비율은 오르기는커녕 직전 30일 동안 조금 떨어졌다.

장식이라는 표현이 부당하지 않다.

일어나지 않는 진행

공식 스토리는 깔끔하다. 감시, 그다음 격리, 그다음 거부. 이건 브로셔다.

실제 조직은 오래된 집이 전선을 축적하듯 메일 시스템을 축적한다. 마케팅은 한 플랫폼에서 보내고, 빌링은 다른 데서, HR은 문서화 안 된 서드파티 워크플로우를 쓰고, 서포트는 3년 전 누군가 추가하고 잊어버린 포워딩 규칙이 있고, 대표이사 비서는 한 국가의 레거시 파트너 때문에 이상한 릴레이 어플라이언스를 쓰고, 누군가 도메인으로 SaaS 트라이얼을 시작하고 해지를 안 했다.

그러고 DMARC 리포팅을 켜면 이메일 생태계가 시스템이 아니라 고고학이라는 걸 알게 된다.

그 시점에서 p=none은 주차장이 된다. 전환 상태가 아니라 서식지.

두려움이 가상이 아닌 건 맞다. 너무 빨리 집행으로 넘어가면 정상 메일이 깨질 수 있다. 포워딩은 여전히 고통을 준다. 메일링 리스트가 흐름을 망친다. 레거시 시스템이 바보 같은 방식으로 정렬을 놓친다. 하지만 두려움이 마이그레이션 경로를 라이프스타일로 바꿔버렸다.

조직이 여기 머무는 이유

고장 불안. RFC를 읽어야 이해할 수 있는 방식으로 스푸핑 메시지가 이론적으로 가능했다고 해서 잘리는 사람은 없다. 정상 메일이 안 오기 시작하면 확실히 혼난다. 너무 빨리 움직이는 운영 비용은 즉각적이고 시끄럽다. p=none에 머무는 사업 비용은 분산되어 있고 지연된다. 관료조직은 이런 선택 앞에서 매우 예측 가능한 동물이다.

리포트를 아무도 안 읽는다. DMARC 집계 리포트는 XML 파일이다. 밀도 높고, 못생겼고, 대량으로 온다. 처리하려면 전용 도구가 필요하다. 많은 조직이 rua 주소를 설정하고 수천 개 리포트를 받고 하나도 안 본다. 리포트를 안 읽으면 비인가 발신자를 식별할 수 없다. 식별 못 하면 집행으로 넘어갈 수 없다. 피드백 루프가 첫 단계에서 고장 나 있다.

기한도 없고 긴급함도 없다. 날짜가 붙은 컴플라이언스 감사와 달리, p=none에서 벗어나라는 외부 압박이 없다. 페널티도 없다. 감사인에게 정책 레벨 안 밝히고 “DMARC 있습니다”라고 말할 수 있다. 체크박스는 체크됐다. CISO가 보고서를 받는다. 대시보드가 초록색이 된다.

그리고 아무것도 바뀌지 않는다.

SPF도 같은 페이크 문제가 있다

SPF의 softfail(~all)은 같은 병에 다른 이름이다. -all(hardfail)은 비인가 발신 전부 거부. ~all은 “뭐 플래그 할까요? 안 해도 돼요. 잘 모르겠어요.” 그렇게 끝나는 SPF 레코드가 수두룩하다. 기술적으로 존재하고, 기능적으로 소심하다.

RFC 7208은 softfail이 도메인이 해당 호스트가 인가되지 않았다고 생각하지만 강한 정책 진술을 할 준비가 안 됐다는 뜻이라고 말한다. ~all이 신중한 전환 도구로 쓸모 있다는 얘기다. (SPF 편을 조금 들자면, ~all이 영구적인 정답인 경우가 하나 있다. 이미 p=reject인 도메인이다. 집행은 DMARC가 하고, SPF를 하드 페일로 두면 DKIM이 메일을 살려 주기도 전에 거부당할 수 있다. 하지만 대부분의 ~all 레코드는 그런 처지가 아니다.)

익숙한 패턴 아닌가?

이메일 보안의 더 넓은 패턴이다. 게시는 쉽고, 집행은 감정적으로 비싸다.

Google-Yahoo 압박

2024년 2월, Google과 Yahoo가 대량 발신자에게 DMARC를 요구하기 시작했다. Google은 개인 Gmail 계정으로 하루 5,000통 안팎을 보내는 발신자를 기준으로 삼았고, Yahoo도 자기 쪽 대량 발신자에게 같은 요구를 했다. 게시율이 급등했다.

하지만 요구사항이 “DMARC 레코드가 있을 것”이지 “집행이 있는 DMARC 레코드가 있을 것”이 아니다. 조직들은 p=none 레코드를 급하게 추가했다. 보안 없는 컴플라이언스. 익숙한 패턴.

주요 이메일 제공자들이 p=none을 “DMARC 없음”으로 취급하기 시작하면 — 집행을 거부하는 도메인의 메일을 필터링하면 — 진짜 채택이 하룻밤에 급등할 것이다. 하지만 마케팅 플랫폼의 DKIM 설정을 미처 못 한 Fortune 500 기업의 메일을 깨는 제공자가 되고 싶은 곳은 없다.

DNS 존 파일 장식하기

DMARC 자체에 화가 나는 건 아니다. 프로토콜은 제 역할을 했다. 짜증나는 건 업계가 감시 정책을 게시하고 자축한 다음, 스푸핑이 여전한 것에 놀라는 방식이다.

잠금 화면은 잠금이 아니다. 리포트는 통제가 아니다. p=none 레코드는 보호가 아니다.

어느 시점에서 정책이 메일 흐름을 바꾸려는 건지 DNS 존 파일을 장식하려는 건지 결정해야 한다.