회사의 DMARC 정책을 십 초에 읽는 방법 (그리고 그것이 당신에게 말해주지 않는 것)

한 번의 DNS 조회로 회사가 자신의 이름으로 보낸 위조된 메일에 대해 세상의 메일 서버들이 할 행동을 알 수 있습니다. 이 기록은 공개되어 있으며, 명령어는 한 줄입니다: dig +short TXT _dmarc.example.com. 반환되는 것은 짧은 설정 문자열이며, 그 안에는 한 가지 지시문 — p=none, p=quarantine 또는 p=reject — 이 그 도메인을 사용한 메시지가 인증에 실패했을 때 도메인 소유자의 선호도를 명시합니다.

현재 명세서인 RFC 9989는 May 2026에 IETF 표준 추적 문서로 발행되었으며, 이전 RFC 7489를 대체했습니다. 이 명세서는 세 가지 값을 거의 간단히 정의합니다:

• p=none — "도메인 소유자는 선호도를 표현하지 않습니다."
• p=quarantine — "도메인 소유자는 이러한 메일을 의심스러운 것으로 봅니다. 메일이 유효할 가능성이 있지만, 인증 실패는 상당한 우려를 만듭니다."
• p=reject — "도메인 소유자는 모든 이러한 실패를 도메인 이름의 사용이 유효하지 않다는 명확한 표시로 봅니다."

이 말들을 다시 읽어보십시오. DMARC에 대한 대부분의 설명이 인정하는 것보다 약합니다. 정책은 송신자가 발행하여 수신자가 고려하도록 한 선호도입니다. 수신자가 따를 의무가 있는 지시문이 아닙니다. RFC 9989는 한 문장으로 이를 말합니다: "모든 메시지의 최종 처리는 항상 로컬 정책의 문제이며 메일 수신자의 재량에 맡겨집니다." 같은 섹션에서는 결과의 양쪽을 모두 추가합니다 — 수신자는 "DMARC 검증 확인을 통과한 메시지도 거부하거나 격리할 수 있으며(MAY)", "거부(reject)의 발행된 정책만을 이유로 메시지를 거부해서는 안 됩니다(SHOULD NOT)". 이는 DMARC가 설명할 수 없는 방식으로 보낸 합법적인 메일과 메일링 리스트가 이 과정에서 손상되지 않도록 하기 위함입니다.

그렇다면 p=none은 실제로 무엇을 드러냅니까? 보통 비난받는 것보다 적습니다. 명세서 자체의 용어로는 모니터링 모드입니다: 도메인 소유자는 집계 보고서를 수집 중이며 "DMARC 검증에 실패한 메시지에 대한 처리 선호도를 표현하지 않으며", DMARC를 배포하는 수신자는 여전히 도메인의 사용을 검증할 수 있습니다. 수신 끝에서 아무것도 전환하지 않습니다. 당신의 제공자의 스팸 필터링, 평판 점수 매김, URL 확인 및 첨부 파일 분석은 송신자가 발행한 것이 무엇이든 상관없이 실행되는 별도의 메커니즘입니다. p=none 도메인에 도착한 위조된 메시지는 기록으로 인해 받은편지함으로 승격되지 않습니다. 이는 단순히 명시된 선호도 없이 수신자에게 전달되며, 수신자가 결정합니다.

오해의 다른 절반은 반대 방향으로 진행됩니다. DMARC는 피싱 이메일의 위험한 부분을 읽지 않습니다. 자신의 명세서는 의도적으로 범위를 벗어난 것들을 나열하고 있으며, "콘텐츠 분석(content analysis)"이 그 목록에 있습니다. 또한 DMARC는 "시각적으로 유사한 도메인 이름의 사용이나 RFC5322.From 인간이 읽을 수 있는 표시 이름의 악용을 다루지 않습니다" — 대부분의 브랜드 사칭 메일을 수행하는 두 가지 방법입니다. 그리고 통과값에 대해: "DMARC 통과 자체만으로는 수신자의 받은편지함에 대한 전달이 안전하거나 바람직할 것을 보장하지 않습니다." 일회용 도메인에서 올바르게 인증된 메시지는 DMARC를 깨끗하게 통과합니다. DMARC는 From: 헤더의 도메인을 사용할 수 있는 권한이 있는 사람을 답변할 뿐입니다. 그 이상은 아닙니다.

여기서 2024년 대량 송신자 규칙은 이 기사의 초기 버전을 포함하여 일반적으로 잘못 보도됩니다. Google의 송신자 가이드라인은 하루 5,000개 이상의 메시지를 Gmail 계정으로 보내는 송신자들에게 "송신 도메인에 대한 DMARC 이메일 인증을 설정하십시오"를 요구하고, 바로 다음에 말합니다: "DMARC 강제 정책은 none으로 설정할 수 있습니다." Yahoo의 자체 Sender Hub는 Google을 복사하는 것으로 가정하기보다는 별도로 읽어야 하며, 요구 사항을 "최소 p=none — DMARC는 통과해야 함의 유효한 DMARC 정책을 발행합니다"로 명시하고, 숫자 볼륨 임계값을 발행하지 않습니다. 두 요구 사항 세트 모두 February 2024부터 시행되었습니다. 누구도 p=none에서 벗어나도록 강제하지 않습니다. 실제로 두 가지 모두 강제하는 것은 정렬된 인증입니다: Google은 "송신자의 From: 헤더의 도메인이 SPF 도메인 또는 DKIM 도메인과 정렬되어야 한다"고 요구하며, Yahoo는 완화된 정렬이 허용된다고 말합니다. 정렬, 심각성이 아니라, 게이트입니다.

이는 도메인이 모니터링에 머물러 있는 실제 이유를 남기며, 이는 겁쟁이가 아닌 운영상의 문제입니다. quarantine 또는 reject로 이동하는 것은 먼저 당신의 이름으로 메일을 보내는 모든 서비스 — 급여, 티켓팅, 마케팅, 문서화되지 않은 지원 데스크 — 를 찾고 정렬되도록 각각을 인증하는 것을 의미합니다. 표준 자체는 이를 느리게 만드는 위험을 인정합니다: 제삼자 송신자는 DMARC에 의해 소개되거나 제외되지 않으며, 전달 및 메일링 리스트는 송신자의 잘못 없이 정렬을 손상시킬 수 있으며, 명세서는 수신자에게 정확히 이러한 실패 모드에 대해 RFC 7960을 가리킵니다. p=none을 발행하고 보고서를 읽는 조직은 명세서가 설명하는 순서대로 작업을 수행하고 있습니다. p=none을 발행하고 보고서를 무시하는 조직은 그렇지 않습니다. 외부에서 기록 자체만으로는 두 가지 중 어느 것을 보고 있는지 알 수 없습니다.

터미널이 필요하지 않습니다. dmarcian의 도메인 체커, MXToolbox의 DMARC 체크 같은 무료 조회 도구가 기록을 가져와서 정책을 인쇄합니다. 당신의 은행, 급여 제공자, 당신이 비행하는 항공사에 대해 이를 수행합니다. 단지 답변을 그것이 무엇인지로 읽으십시오: 도메인 소유자의 의도 진술, 당신의 메일 제공자가 자체적으로 하는 결정에 대한 많은 입력 중 하나, 한 가지 특정한 종류의 위조에 대한 것입니다. 이것은 십 초에 읽을 수 있는 진정으로 유용한 것입니다. 그 브랜드에서 온다고 주장하는 다음 메시지가 안전한지에 대한 판정은 아닙니다.

정정, 20 October 2026. 이 기사의 이전 버전은 p=none을 위조품을 받은편지함으로 전달하는 것으로 설명했고 p=reject를 위조된 메시지를 차단하는 유일한 설정으로 말했으며, 2024년 Google 및 Yahoo 대량 송신자 규칙이 송신자들을 p=none에서 벗어나도록 강제했다고 말했고, 대략 삼 분의 일 도메인이 강제 상태에 있다는 수치를 인용했습니다. 정책 설명은 RFC 9989에 대해 정정되었습니다; Google과 Yahoo 모두 실제로 p=none을 수용하며, 위에서 자체 문서에서 인용됩니다; 그리고 강제 수치는 제거되었습니다. 기본 보고서가 샘플이나 분모를 발행하지 않기 때문입니다. 이 기사는 이제 또한 DMARC가 검토하지 않는 것을 명시합니다.