DMARC 란? 정렬(Alignment), 정책 및 2026 RFC

DMARC 란 무엇인가? From 헤더에서 귀사 도메인을 주장하지만 인증에 실패한 메시지에 대해 받는 메일 서버가 수행해야 할 작업을 알려주는 DNS 레코드입니다. 또한 이에 대한 보고서를 어디로 보낼지도 지시합니다. DMARC는 그 자체로 아무것도 인증하지 않습니다. SPF 또는 DKIM이 통과했는지, 그리고 그들이 검증한 도메인이 독자가 보는 도메인과 일치하는지 확인할 뿐입니다.

이 일치를 정렬(alignment)이라고 부르며, 대부분의 팀이 잘못 이해하는 부분입니다. 메시지가 SPF를 통과하고 DKIM을 통과해도 DMARC에서 실패할 수 있습니다.

DMARC는 SPF와 DKIM 위에 있는 정책 계층

SPF는 도메인에 대해 메일을 보낼 수 있는 IP를 나열합니다. DKIM은 메시지에 서명하여 받는 측에서 변조되지 않았으며 서명 도메인이 승인했음을 확인할 수 있도록 합니다. 둘 다 사람이 읽는 From 주소를 보지 않습니다.

DMARC가 이 격차를 메웁니다. 이것은 한 가지 질문을 던집니다: 보이는 From 헤더의 도메인이 SPF 또는 DKIM을 통과한 도메인과 일치하는가? 맞다면 메시지가 통과합니다. 아니라면 받는 측에서 정책을 적용합니다.

레코드는 _dmarc.yourdomain.com에 TXT 레코드로 있습니다. 최소한의 유효한 레코드는 다음과 같습니다:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

세 가지 태그가 실제 작업을 수행합니다. p는 정책이고, rua는 집계 보고서가 가는 위치이며, adkim / aspf는 정렬이 얼마나 엄격한지 설정합니다. 나머지는 모두 선택사항입니다.

정렬(Alignment)이 좋은 설정이 실패하는 곳

SPF는 Return-Path 도메인인 봉투 발신자를 인증합니다. DKIM은 서명의 d= 태그에 있는 도메인을 인증합니다. DMARC는 이 중 최소 하나가 From 도메인과 일치해야 하며, 정확히(엄격함) 또는 조직 도메인 수준(완화됨, 기본값)에서 일치할 수 있습니다.

우리가 추적에서 가장 자주 보는 실패는 다음과 같습니다. 팀이 타사 제공자를 통해 보내면, 제공자가 자신의 도메인(d=provider-mail.net)으로 서명하고 자신의 바운스 도메인을 사용합니다. SPF가 통과하고 DKIM이 통과하며 DMARC가 실패합니다. 두 도메인 모두 example.com과 일치하지 않기 때문입니다.

해결책은 맞춤 발신 도메인입니다: 도메인 아래에 게시된 DKIM 키, 가능하면 서브도메인의 맞춤 반환 경로. 모든 주요 제공자가 지원합니다. 거의 모두 기본적으로 활성화하지 않습니다.

세 가지 정책: none, quarantine, reject

p 태그에는 세 가지 값이 있으며, 이들은 일정에 따라 올라가는 사다리가 아닙니다.

• p=none: 받는 측이 정상적으로 배달하고 보고서를 보냅니다. 발신자를 나열하는 동안 처음 2~4주 동안 사용합니다.

• p=quarantine: 받는 측이 실패를 스팸 또는 정크로 라우팅합니다. 보고서에 모든 합법적인 소스가 정렬되어 있음을 보이면 사용합니다.

• p=reject: 받는 측이 SMTP 단계에서 실패를 거부합니다. 격리가 전체 발송 주기에 대해 정상이 되면 사용합니다.

p=none은 모니터링이지, 보호가 아닙니다. 2년 동안 none에 앉아 있는 도메인은 컴플라이언스 체크박스를 가지고 있지만 스푸핑 방어가 없습니다. 「아무것도 깨지지 않았으므로」라는 이유로 거기에 두려는 유혹을 피하십시오.

p=reject는 관리하는 메일만 보내는 도메인을 위한 목적지입니다. 많은 메일링 리스트 트래픽 또는 레거시 포워더가 있는 도메인은 더 많은 주의가 필요합니다. 포워딩은 종종 SPF를 깨뜨리고 중개자가 본문을 편집하면 DKIM을 깨뜰 수 있기 때문입니다.

Gmail과 Yahoo 규칙이 이를 긴급하게 만든 이유

2024년 2월 이후, Google의 발신자 지침에서는 Gmail 계정에 하루 5,000개 이상의 메시지를 보내는 모든 사람이 SPF와 DKIM이 있는 DMARC 레코드를 게시해야 합니다. 정책은 none일 수 있습니다. Google은 또한 대량 발신자에게 Postmaster Tools에서 사용자가 보고한 스팸 비율을 0.30% 미만으로 유지하도록 요청하고 0.10% 미만으로 유지할 것을 권장합니다.

Yahoo의 Sender Hub는 동일한 핵심 요구사항을 명시합니다: 최소 p=none의 유효한 DMARC 정책과 SPF 또는 DKIM 도메인에 정렬된 From 도메인. 완화된 정렬이 허용됩니다.

이 규칙에 있고 없는 것을 주목합니다. 요구사항은 게시된 레코드와 통과 정렬이지, 시행이 아닙니다. 이것은 기준선입니다. 이것은 끝이 아닙니다.

집계 보고서가 상품이고 정책이 스위치

rua 주소는 DMARC를 준수하는 모든 받는 측으로부터 매일 XML 보고서를 받습니다. 각 보고서에는 소스 IP, 메시지 개수, SPF 및 DKIM 결과, 정렬 유지 여부가 나열됩니다. 이것이 잊혀진 발신자를 찾는 방법입니다: 오래된 CRM 내보내기, 2022년에 계약자가 연결한 청구 도구, 아무도 소유하지 않은 서브도메인의 마케팅 양식.

원본 XML은 대량으로 읽을 수 없습니다. rua를 파서가 수집할 수 있는 사서함으로 라우팅하거나 호스팅된 DMARC 보고 서비스로 라우팅하고 소스별로 그룹화된 데이터를 봅니다. 보고 싶은 것은 100% 정렬된 모든 합법적인 소스이고 다른 모든 것은 명확하게 알려지지 않은 것입니다.

실제 전개는 이 순서로 진행됩니다:

1. p=none과 rua 주소를 사용하여 게시합니다.

2. 2~4주의 보고서를 수집합니다. 발신자 목록을 작성합니다.

3. 맞춤 DKIM 도메인 또는 반환 경로로 정렬되지 않은 각 합법적인 소스를 수정합니다.

4. p=quarantine으로 이동합니다. 누락된 메일에 대한 지원 티켓을 확인하십시오.

5. 격리가 합법적인 실패를 나타내지 않을 때 p=reject로 이동합니다.

각 단계를 별도로 배송합니다. 정책을 변경하고 같은 주에 새로운 발신 제공자를 추가하면 회귀를 속성하기가 불가능합니다.

DMARCbis는 태그를 변경하고 레코드는 변경하지 않습니다

2026년 IETF는 RFC 7489를 폐기하는 RFC 9989, RFC 9990, RFC 9991을 게시했습니다. RFC 9989는 핵심 DMARC 사양입니다. 집계 보고 및 실패 보고는 자신의 문서로 이동했습니다.

레코드 소유자에게 실제 변경사항은 작습니다:

• pct, rf, ri는 제거됩니다.

• t (테스트 모드)는 pct를 전부 또는 전무 스위치로 대체합니다: t=y는 시행 없이 보고합니다.

• np는 존재하지 않는 서브도메인에 대한 정책을 설정하며, 이는 abc123.example.com과 같은 주소의 스푸핑을 차단합니다.

• psd는 공개 접미사 도메인을 표시하고 DNS 트리 워크는 이전의 공개 접미사 목록 조회를 대체합니다.

기존 v=DMARC1 레코드는 유효한 상태로 유지됩니다. 오늘 아무것도 변경하지 않으면 아무것도 깨지지 않습니다. 새로운 태그에 대한 공급자 지원은 불균일하게 출시되므로, 아무것도 하지 않는 것처럼 보이는 새로운 태그는 일반적으로 받는 측이 아직 구현하지 않았음을 의미합니다.

np 태그가 초기에 채택할 가치가 있습니다. p가 여전히 none인 상태에서 np=reject를 설정하면 나머지 메일을 시행하지 않고도 가짜 서브도메인 남용 경로를 종료합니다.

서브도메인과 기본값이 상속되는 이유

조직 도메인의 DMARC 레코드는 sp로 재정의하지 않는 한 서브도메인에도 적용됩니다. 이 상속은 유용하면서도 함정이기도 합니다.

마케팅이 별도 제공자를 통해 news.example.com에서 보내는 경우 상위 정책을 상속합니다. 해당 제공자가 정렬된 DKIM을 가지기 전에 상위를 p=reject로 이동하면 뉴스레터가 바닥에 떨어집니다. 서브도메인이 자신의 발신자 플릿을 가지고 있고 자신의 전개 속도를 가지고 있을 때 별도의 _dmarc.news.example.com 레코드를 게시합니다.

더 깔끔한 아키텍처는 처음부터 서브도메인별로 스트림을 분리합니다. 하나에 트랜잭션 메일, 다른 하나에 라이프사이클, 루트에 사람 메일. 각각은 자신의 DKIM 키, 자신의 평판, 자신의 DMARC 레코드를 가집니다.

추측하기 전에 인증 결과 헤더를 읽으십시오

메시지가 실패하면 받는 서버가 이유를 기록합니다. Gmail에서 "원본 표시"는 Authentication-Results 헤더를 노출하고, 모든 대시보드보다 더 많은 것을 알려줍니다.

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=bounce.provider-mail.net;
  dkim=pass header.d=provider-mail.net;
  dmarc=fail (p=NONE) header.from=example.com

왼쪽에서 오른쪽으로 읽으세요. SPF는 bounce.provider-mail.net에 대해 통과했습니다. DKIM은 provider-mail.net에 대해 통과했습니다. DMARC는 실패했습니다. From 헤더가 example.com을 말하고 통과 도메인이 일치하지 않기 때문입니다.

(p=NONE) 표기는 받는 측이 본 정책을 표시합니다. none에서 이 메시지는 어쨌든 배달되었습니다. reject에서는 5.7.x 오류로 반송되었고 발신자는 고객으로부터 알아냈을 것입니다.

두 가지 검사로 대부분의 경우를 잡습니다. DKIM 결과의 header.d 값이 도메인임을 확인합니다. 그러면 smtp.mailfrom 도메인이 도메인 또는 도메인의 서브도메인임을 확인합니다.

SPF에는 조회 제한이 있고 DMARC가 노출합니다

SPF는 평가당 10개의 DNS 조회를 허용합니다. 제공자의 모든 include:는 일부를 사용하고 중첩된 포함은 더 사용합니다. 10을 초과하면 SPF는 영구 오류를 반환하고, 이는 실패로 간주합니다.

5~6개의 발송 도구가 있는 팀이 DMARC 보고 없이는 이를 알아차리지 못해도 이를 입력합니다. rua 보고서가 도착하면 패턴이 명확합니다: 누군가 또 다른 include:를 추가한 날에 한 소스가 갑자기 모든 받는 측에서 SPF에 실패합니다.

이것이 DKIM 정렬을 주요 경로로 의존하는 또 다른 이유입니다. DKIM은 대부분의 포워딩을 견딜 수 있으며, 조회 예산이 없으며, 메시지가 아닌 연결에 연결됩니다. SPF를 유효하게 유지하되 DMARC 통과를 고스란히 기반으로 구축하지 마십시오.

DMARC는 무엇을 하지 않습니다

DMARC는 정확한 도메인 스푸핑을 방지합니다. 스푸핑 유사 도메인(examp1e.com)을 중지하지 않으며, 콘텐츠를 판단하지 않으며, 나쁜 발신자 평판을 해결하지 않습니다. 완벽하게 정렬된 도메인이 구매한 목록으로 보내도 여전히 스팸에 표시됩니다.

또한 모니터링을 대체하지 않습니다. 정렬은 자동으로 끊어질 수 있습니다: DNS 변경으로 DKIM 선택기가 제거되거나, 제공자가 키를 회전하거나, 새 도구가 미리 보내기 시작합니다. 보고서는 사용자보다 먼저 알아내는 방법입니다.

DMARC 레코드를 프로덕션 설정의 다른 부분처럼 취급합니다. 버전 관리에 속하고, 변경사항이 검토를 거치며, rua 사서함에 소유자가 있어야 합니다.

게시하기 전에

한 번 이것을 실행합니다. 단일 도메인의 경우 1시간이 걸립니다.

• 도메인으로 메일을 보내는 모든 시스템을 나열합니다: 제품, 청구, 지원 데스크, CRM, 마케팅, 일정 초대.

• 각각이 공급자가 아닌 도메인으로 DKIM에 서명하는지 확인합니다.

• 제공자가 허용하는 경우 맞춤 반환 경로를 설정합니다.

• 누군가 읽을 rua 대상을 선택합니다.

• p=none으로 시작하고 검토할 계획 날짜를 일정에 입력합니다.

• 전개 중에 Google Postmaster Tools에서 주 1회 스팸 비율을 확인합니다.

다음으로 갈 곳

보고서를 본 적이 없는 경우 오늘 p=none과 rua 주소를 사용하여 게시하고 2주 후에 돌아오는 것을 읽으십시오. 첫 번째 보고서는 거의 항상 아무도 기억하지 못하는 발신자를 최소한 하나 이름 지정합니다. 다음 구체적인 단계는 이 중 어느 것을 유지할지 결정하는 것입니다.