인기 도구

테마

DMARC 레코드 확인

수신 메일 서버가 읽는 방식 그대로 도메인의 DMARC 레코드를 확인합니다. 정책이 어디에 있는지, 인증에 실패한 메일은 어떻게 처리되는지, 보고서가 누군가에게 도달하는지, 정책을 적용하기 전에 SPF와 DKIM에 무엇이 필요한지 알려 드립니다.

출처: 도메인과 상위 도메인의 _dmarc TXT 레코드(Google Public DNS 경유, 뒤에 Cloudflare 1.1.1.1) · RFC 9989 트리 탐색 · RFC 9990에 따른 보고서 승인 · SPF와 DKIM은 자체 검사 도구 결과 · 사용자에 관한 정보는 저장하지 않음

DMARC 레코드는 어떻게 확인하나요?

위 입력란에 도메인을 입력하세요. 이 도구는 DNS에 _dmarc.에 도메인을 붙인 이름의 TXT 레코드를 조회하고, 없으면 조직 도메인까지 거슬러 올라가며(RFC 9989 §4.10), 인증에 실패한 메일을 수신 서버가 어떻게 처리하는지 보여 줍니다.

직접 확인하려면 같은 이름을 조회하세요. dig +short TXT _dmarc.paypal.com, Windows에서는 nslookup -type=TXT _dmarc.paypal.com(DMARC nslookup)입니다. v=DMARC1로 시작하는 응답이 하나면 그것이 레코드이고, 둘이면 수신 서버는 어느 쪽도 사용하지 않습니다(RFC 9989 §4.10).

dig는 거기까지입니다. 서브도메인에서 상위로 올라가지 않고, 보고서 주소가 보고서를 받아 주는지도 확인하지 않으며, 수신 서버가 어느 RFC를 따르는지도 알려 주지 않습니다. 이 도구가 그 부분을 채웁니다.

dig +short TXT _dmarc.example.com

이 이름의 모든 응답을 보여 줍니다. v=DMARC1로 시작하는 하나가 레코드입니다.

dig가 보여 주는 것과 보여 주지 않는 것

터미널

$ dig +short TXT _dmarc.paypal.com 1

"v=DMARC12; p=reject; rua=mailto:d@rua.agari.com,mailto:dmarc_agg@vali.email; ruf=mailto:d@ruf.agari.com,mailto:MTc4Mzcw@ruf.vali.email3"

$ dig TXT _dmarc.mail.google.com | grep status 4

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

  1. 1이름은 _dmarc.에 도메인을 붙인 것도메인 자체가 아닙니다. paypal.com의 TXT는 SPF의 자리입니다.
  2. 2레코드는 하나, v=DMARC1이 맨 앞한 이름에 레코드가 둘이면 수신 서버는 둘 다 폐기합니다(RFC 9989 §4.10).
  3. 3;로 구분된 태그p는 정책이고, rua와 ruf는 보고서가 가는 곳입니다.
  4. 4여기에 없나요? 위로 올라갑니다_dmarc.mail.google.com은 NXDOMAIN입니다. google.com의 레코드가 적용됩니다.
Google Public DNS가 2026년 10월 24일에 반환한 paypal.com의 레코드. mail.google.com에는 자체 레코드가 없습니다.

결과 읽는 법: 수신 서버의 시점

먼저 한 문장으로 답이 나옵니다. 그 아래에 근거가 이어집니다. 수신 서버가 해석한 레코드(각 태그를 실제 문자 위치에 색으로 표시), 그리고 남색 영역에는 이 도메인에 대해 수신 서버가 거치는 경로와 실패한 메일의 최종 처리가 나옵니다.

점수는 없습니다. none 정책은 실패가 아니라 하나의 단계이며, 경로 아래의 적용 단계표가 다음 단계에 무엇이 필요한지 알려 줍니다.

paypal.com의 DMARC 레코드 확인: DMARC에 실패한 메일을 거부, 수신 서버의 시점과 적용 단계표paypal.com의 DMARC 레코드 확인: DMARC에 실패한 메일을 거부, 수신 서버의 시점과 적용 단계표판정실패한 메일을 수신 서버가 어떻게 처리하는지 한 문장으로 보여 주며, 정책, SPF, DKIM을 한눈에 확인할 수 있습니다.레코드각 태그를 문자 위치에 색으로 표시합니다. 마우스를 올리거나 탭하면 역할을 알 수 있고, 아래에 기본값이 나옵니다.수신 서버의 시점도메인에 대해 수신 서버가 보내는 모든 DNS 질의를 순서대로 응답과 함께 보여 줍니다.DMARC에 실패한 메일도메인 자체, 존재하는 서브도메인, 존재하지 않는 이름에서 수신 서버가 하는 처리입니다.적용 단계표도메인이 none과 reject 사이 어디에 있는지, 다음 단계에 무엇이 필요한지 보여 줍니다.
paypal.com의 DMARC 확인: 판정, 태그별로 나눈 레코드, 모든 DNS 질의와 실패한 메일의 처리를 보여 주는 수신 서버의 시점, 그리고 적용 단계표. 번호를 선택하면 각 부분이 무엇을 보여 주는지 확인할 수 있습니다.

DMARC란 무엇이며 어디에 쓰나요?

DMARC는 From: 줄에 내 도메인을 쓰지만 내가 보냈다는 것을 증명하지 못하는 메일을 수신 메일 서버가 어떻게 처리할지 알려 주고, 그 메일에 관한 보고서를 어디로 보낼지도 알려 줍니다(RFC 9989 §4.7).

증명 수단은 From: 도메인과 정렬된 SPF 또는 DKIM입니다. 같은 조직 안의 반송 도메인에 대한 SPF 통과, 또는 d=가 내 도메인인 DKIM 서명입니다. 정렬된 통과가 하나만 있으면 충분합니다(RFC 9989 §5.3.5). 나머지는 모두 DMARC에 실패하며, 레코드의 정책에 따라 전달, 스팸함, 거부 중 하나가 됩니다.

보고서는 나머지 절반입니다. rua를 따르는 수신 서버는 내 도메인으로 메일을 보낸 모든 서버의 일일 요약을 보내 줍니다. 정책을 적용하기 전에 잊고 있던 정상 발신원을 찾는 방법입니다.

메일 두 통, 같은 From: 줄

From: billing@example.comp=reject · rua=mailto:dmarc@example.com

메일 서비스를 통해 보낸 실제 청구서커스텀 DKIM을 설정한 서비스 경유라서 d=example.com으로 서명

  1. SPFpass · bounces.esp.example(정렬되지 않음)
  2. DKIMpass · d=example.com(정렬됨)
  3. DMARCpass: 정렬된 결과 하나면 충분
전달됨

203.0.113.9에서 온 위조 청구서example.com이 허용한 적 없는 서버

  1. SPFfail · 203.0.113.9는 목록에 없음
  2. DKIM없음 · 서명 없음
  3. DMARCfail → p=reject
거부됨

550 5.7.1 Email rejected per DMARC policy for example.com

내일의 집계 보고서가 dmarc@example.com으로 전달됩니다: 203.0.113.9에서 온 메일 1통, SPF fail, DKIM 없음, 처리 reject.

통과해도 전달이 보장되는 것은 아니며(최종적으로는 수신 서버의 필터가 결정합니다), p=reject에서의 실패는 명령이 아니라 요청입니다(RFC 9989 §5.4, §7.4). 주소는 RFC 5737의 것이고, 응답 문구는 RFC 9989의 예시입니다.

DMARC 레코드 태그 설명: DMARC 설정 가이드

DMARC 레코드는 _dmarc.에 도메인을 붙인 이름의 TXT 레코드에 적는 태그=값 쌍의 목록입니다. 맨 앞에 v=DMARC1을 두고, 정책, 정렬, 보고서 태그를 순서에 상관없이 이어 씁니다(RFC 9989 §4.7).

RFC 9989(2026년 5월)는 RFC 7489를 대체했습니다. np, psd, t가 추가되고 pct, rf, ri가 삭제되었습니다. 현재 수신 서버는 이들을 무시하지만 아직 RFC 7489를 따르는 수신 서버는 읽으므로, pct=25가 들어 있는 레코드는 수신 서버에 따라 의미가 달라집니다.

게시하지 않은 태그는 기본값이 적용되며, 이 도구는 그것도 보여 줍니다. sp가 없으면 서브도메인에는 p가 적용됩니다.

모든 태그를 역할별로

v=DMARC1; p=reject; sp=quarantine; np=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1
버전정책테스트와 서픽스정렬보고서삭제됨
태그설정 내용기본값상태확인 수
v버전DMARC1필수, 맨 앞RFC 9989192
p도메인의 정책none · quarantine · reject없으면 none(rua가 유효할 때)RFC 9989192
sp존재하는 서브도메인의 정책none · quarantine · rejectpRFC 998939
np존재하지 않는 이름의 정책none · quarantine · rejectsp, 그다음 pRFC 9989에서 추가2
t테스트 모드: 정책보다 한 단계 아래y · nnRFC 9989에서 추가0
psd퍼블릭 서픽스(y) 또는 조직 도메인(n)y · n · uuRFC 9989에서 추가1
adkimDKIM 정렬r · srRFC 998920
aspfSPF 정렬r · srRFC 998924
rua집계 보고서가 가는 곳mailto:…보고서 없음RFC 9989186
ruf실패 보고서가 가는 곳mailto:…보고서 없음RFC 9989120
fo실패 보고서를 보내는 시점0 · 1 · d · s0RFC 998996
pct실패한 메일 중 정책을 적용하는 비율0–100–삭제됨70
rf실패 보고서 형식afrf–삭제됨9
ri보고 간격(초)86400–삭제됨14
확인 수: 잘 알려진 196개 도메인이 게시한 DMARC 레코드 192개 중 해당 태그가 들어 있는 수(2026년 10월 24일 조회, pct 태그 70개 중 69개가 pct=100). 기본값과 상태는 RFC 9989 §4.7과 부록 C를 따릅니다.

DMARC 정책: p=none, quarantine, reject 비교

p=none은 실패한 메일을 평소처럼 전달하고 보고만 하도록 요청하고, quarantine은 의심스러운 메일로 취급해 보통 스팸함으로 보내도록 요청하며, reject는 SMTP 대화 중에 수신을 거부하도록 요청합니다.

none은 실패가 아니라 하나의 단계입니다. RFC 9989 §7.4는 보고서를 받으면서 none에서 최소 한 달, reject로 가기 전에 quarantine에서도 다시 같은 기간을 보내라고 권장합니다. 사용자가 메일링 리스트에 글을 올리는 도메인은 quarantine에서 멈추는 편이 좋습니다.

대형 메일 제공업체도 정책을 나눠 씁니다. gmail.com과 outlook.com은 도메인 자체에는 p=none, 서브도메인에는 sp=quarantine을 게시하고, google.com, yahoo.com, microsoft.com은 reject를 게시합니다.

위조 메일이 도착하는 곳

전달p=none

apache.orggmail.comsamsung.com

192개 중 23개

스팸함p=quarantine

github.comapple.comamazon.com

192개 중 30개

거부p=reject

google.compaypal.commicrosoft.com

192개 중 139개

none 23quarantine 30reject 139레코드 192개, 잘 알려진 도메인 196개, 2026년 10월 24일

최종 결정은 수신 서버가 합니다. p=reject에서 실패한 메일을 전달할 수도 있으며, 정책만을 이유로 거부해서는 안 됩니다(RFC 9989 §5.4, §7.4). 벤더 조사는 웹 전체가 얼마나 뒤처져 있는지 보여 줍니다. 2026년 초 상위 180만개 도메인을 대상으로 한 EasyDMARC의 조사에서 p=none은 29.2%, quarantine 또는 reject는 22.9% 수준이었습니다.

DMARC는 정말 필요한가요?

네. Gmail, Yahoo, Outlook.com으로 대량 발송한다면 필요합니다. 세 곳 모두 DMARC 레코드를 요구하며 p=none이면 규칙을 충족합니다. 다른 사람이 내 도메인으로 메일을 보내는 것을 막는 것은 적용 단계(quarantine 또는 reject)이고, BIMI 로고에도 필요합니다.

Gmail은 2024년 2월 1일부터 Gmail 계정으로 하루 5,000통을 넘게 보내는 발송자에게 요구합니다. Yahoo는 2024년 2월부터 요구하며 발송량 기준은 밝히지 않습니다. Outlook.com은 2025년 5월 5일부터 하루 5,000통을 넘게 보내는 발송자에게 요구합니다. 레코드가 없으면 Gmail은 4.7.31(From: 주소가 정렬되지 않으면 4.7.32)로 응답하고, Outlook.com은 550 5.7.515로 거부합니다.

메일을 보내지 않는 도메인에서는 DMARC가 가장 저렴한 보호책입니다. example.com이 게시한 것처럼 p=reject, Null MX, v=spf1 -all을 설정하세요(M3AAWG).

각 메일 제공업체가 대량 발송자에게 요구하는 것

Gmail2024. 2. 1.Gmail 계정으로 하루 5,000통 초과4.7.31 · 4.7.32
Yahoo2024년 2월기준 미공개DMARC를 통과해야 함
Outlook.com2025. 5. 5.하루 5,000통 초과550 5.7.515
전달p=none세 제공업체의 규칙을 모두 충족
스팸함quarantine대부분의 사칭을 차단 · BIMI 로고 가능
거부reject입구에서 사칭을 차단 · BIMI

✓필수: 레코드, p=none 이상i보호: quarantine 또는 reject

각 제공업체의 발송자 안내 페이지에서 2026년 10월 24일에 확인했습니다. 스팸 비율 0.3% 미만과 원클릭 수신 거부도 규칙이지만 DNS로는 확인할 수 없습니다. 이 도구의 요건 탭에서 어느 부분까지 증명할 수 있는지 알려 줍니다.

DMARC 실패 해결법: 전달, 메일링 리스트, 업체 자체 도메인

집계 보고서에서 실패하는 발신원을 찾아 발신 측에서 고치세요. 내 도메인으로 DKIM 서명을 하거나, 조직 안의 반송 도메인으로 옮기면 됩니다. 실패의 대부분은 세 가지 원인으로 설명됩니다.

전달(포워딩)은 DKIM 서명은 유지하지만 SPF를 깨뜨리므로 DKIM이 통과를 책임집니다. 메시지를 수정하는 메일링 리스트는 둘 다 깨뜨립니다. 그리고 자기 도메인으로 서명하는 메일 서비스는 나의 도메인이 아니라 서비스 자신의 DKIM만 통과합니다. 해당 서비스의 커스텀 DKIM(보통 s1._domainkey 같은 CNAME)과 커스텀 반송 경로를 켜세요.

세 가지 실패, 보고서에 나오는 내용, 해결법

전달(포워딩)

  • SPF192.0.2.80은 example.com의 SPF에 없음
  • DKIM서명 온전함

보고서 표시spf=fail dkim=pass → pass

모든 메일에 DKIM 서명: DKIM은 전달 후에도 유지됩니다. ARC(RFC 8617)는 전달자가 메일을 보증하는 데 도움이 됩니다.

메일링 리스트

  • SPF리스트 서버가 발송
  • DKIM본문이 바뀌어 해시 불일치

보고서 표시spf=fail dkim=fail → fail

From:을 다시 쓰는 리스트는 해결됩니다. 사용자가 리스트에 글을 올리는 도메인은 quarantine에서 멈춥니다(RFC 9989 §7.4).

업체 자체 도메인

  • SPFbounces.esp.example에서 pass: 정렬되지 않음
  • DKIMesp.example에서 pass: 정렬되지 않음

보고서 표시dkim=pass(esp.example) → fail

업체의 커스텀 DKIM을 켜세요. paypal.com의 s1과 s2는 SendGrid로 연결된 CNAME이며, SendGrid가 paypal.com으로 서명합니다.

주소는 RFC 5737의 것이고, esp.example은 예시용입니다. SendGrid CNAME은 paypal.com의 실제 셀렉터입니다(2026년 10월 24일).

서브도메인의 DMARC: sp와 np

자체 레코드가 없는 서브도메인은 조직 도메인의 정책을 따릅니다. 존재하는 서브도메인에는 sp, 존재하지 않는 이름에는 np가 적용되며, 둘 다 없으면 p가 적용됩니다(RFC 9989 §4.7).

자체 레코드를 게시한 서브도메인은 그것을 자기 자신에게 사용합니다. 하지만 어떤 이름과 그 조직 도메인 사이에 있는 레코드는 그 이름에 사용되지 않습니다. berkeley.edu의 트리가 그 예로, eecs.berkeley.edu의 sp=none은 www.eecs.berkeley.edu에 닿지 않습니다(RFC 9989 §4.10.1).

np는 가장 손쉬운 개선입니다. 존재하지 않는 이름에서는 정상 메일이 나가지 않으므로 p가 아직 none이어도 np=reject로 그곳에서의 위조를 차단할 수 있습니다. RFC 7489 수신 서버는 np를 모르고 sp를 사용합니다.

수신 서버가 읽는 berkeley.edu의 트리

berkeley.edup=reject; np=reject; psd=n; rua=…자체 레코드 · psd=n: 조직 도메인거부
www.berkeley.edu레코드 없음존재하면 sp, 없으면 p거부
eecs.berkeley.edup=reject; sp=none; rua=…자체 레코드 → p거부
www.eecs.berkeley.edu레코드 없음트리 탐색: eecs.berkeley.edu의 레코드는 건너뜀(조직 도메인이 아님) → berkeley.edu의 p거부
nosuch-x7.berkeley.eduNXDOMAIN존재하지 않음 → np거부

eecs.berkeley.edu의 sp=none은 적용되지 않습니다. 어떤 이름과 그 조직 도메인 사이에 있는 레코드는 그 이름에 사용되지 않기 때문입니다(RFC 9989 §4.10.1). 이 도구는 이를 사용되지 않는 레코드로 표시합니다.

2026년 10월 24일에 Google Public DNS로 조회. nosuch-x7.berkeley.edu는 임의로 만든 이름이며, 그 NXDOMAIN은 실제 응답입니다.

DMARC 보고서(rua) 읽는 법

집계 보고서는 각 수신 서버가 매일 보내는 XML 파일로, 내 도메인으로 메일을 보낸 모든 서버, 메일 수, SPF, DKIM, DMARC 통과 여부가 들어 있습니다(RFC 9990).

발신원별로 읽으세요. 내 서버와 서비스는 정렬된 통과를 보여야 하고, 알려진 서비스가 실패하면 커스텀 DKIM이 필요하며, p=reject에서 실패하는 모르는 주소는 차단된 사칭입니다. 보고서 서비스(dmarcian, Valimail, EasyDMARC, Postmark 등)는 수천 개의 파일을 이런 목록으로 정리해 줍니다.

다른 도메인의 주소로 가는 보고서는 그 도메인이 동의해야만 도착합니다. 그 도메인이 값이 v=DMARC1인 yourdomain._report._dmarc.its-host를 게시해야 합니다(RFC 9990 §4). 이 도구가 대신 확인하고, 없으면 정확한 레코드를 알려 줍니다.

보고서 한 건을 한 줄씩 읽기

<org_name>google.com</org_name>1

<date_range>10월 23일 00:00 UTC ~ 10월 24일 00:00 UTC</date_range>

<policy_published>example.com · p=reject</policy_published>2

<source_ip>198.51.100.24</source_ip> <count>412</count> dkim=pass spf=fail → none3

<source_ip>203.0.113.9</source_ip> <count>37</count> dkim=fail spf=fail → reject4

  1. 1보고한 곳수신 서버마다 하루에 파일 하나(RFC 9990: 최소 24시간마다).
  2. 2찾은 정책_dmarc.example.com에서 읽은 내용입니다.
  3. 3전달된 메일, DKIM이 구함전달 서버에서 SPF는 실패했지만 정렬된 서명이 DMARC를 통과했습니다.
  4. 4사칭, 차단됨모르는 서버, 정렬된 것이 없어 거부되었습니다.
paypal.comrua=mailto:d@rua.agari.comrua.agari.compaypal.com._report._dmarc.rua.agari.com TXT "v=DMARC1;"✓ 승인됨: 보고서가 도착합니다

이 도구가 인식하는 보고서 서비스dmarcianValimailEasyDMARCPostmarkCloudflareMimecastProofpointAgariRed SiftPowerDMARC외 6개

XML은 줄이고 임의로 만든 것입니다(문서용 주소, RFC 5737). 승인 레코드는 paypal.com의 실제 레코드로 2026년 10월 24일에 조회했습니다.

DMARC 레코드 확인: 자주 묻는 질문

DMARC란 무엇인가요?

DMARC는 From: 줄에 내 도메인을 쓰지만 SPF와 DKIM 정렬에 실패한 메일을 수신 메일 서버가 전달할지, 격리할지, 거부할지 알려 주는 DNS 레코드입니다. 그런 메일에 관한 보고서를 어디로 보낼지도 지정합니다. _dmarc에 도메인을 붙인 이름의 TXT 레코드로 게시하며, 2026년 5월에 RFC 7489를 대체한 RFC 9989에 정의되어 있습니다.

DMARC 레코드 확인 도구는 무엇을 보여 주나요?

수신 서버처럼 _dmarc에 도메인을 붙인 이름의 TXT 레코드를 읽고, 없으면 상위 도메인의 레코드를 읽습니다. 이 도구는 태그별 레코드와 기본값, 도메인 자체와 서브도메인과 존재하지 않는 이름의 정책, 보고서 주소가 보고서를 받아 주는지, 도메인의 SPF 레코드와 DKIM 키를 점수 없이 보여 줍니다.

DMARC는 어떻게 테스트하나요?

위에서 도메인을 확인하면 게시된 정책을 볼 수 있으며, DNS로 답할 수 있는 DMARC 테스트는 거기까지입니다. 실제 메일이 통과하는지 보려면 내가 관리하는 메일함으로 메일을 보내 Authentication-Results 헤더를 읽거나 헤더를 이메일 헤더 분석에 붙여 넣으세요. DMARC 검증기는 레코드의 구문을 확인하고, SPF나 DKIM이 정렬되었는지는 메일로만 알 수 있습니다.

처음에는 어떤 DMARC 정책으로 시작해야 하나요?

p=none과 rua 주소로 시작하면 전달에는 변화 없이 매일 보고서를 받을 수 있습니다. 실패하는 정상 발신원은 보통 해당 서비스의 커스텀 DKIM을 켜서 고친 뒤 quarantine, 마지막으로 reject로 올리세요. RFC 9989는 p=none에서 최소 한 달, 이어서 quarantine에서도 같은 기간을 권장합니다. 메일을 보내지 않는 도메인은 곧바로 p=reject로 갈 수 있습니다.

p=none으로도 도메인이 보호되나요?

아니요. p=none은 실패한 메일을 평소처럼 처리하도록 요청하므로, 위조 메일은 수신 서버 자체의 스팸 필터로만 판단됩니다. 얻는 것은 보고서이며, Gmail, Yahoo, Outlook.com의 대량 발송자 규칙은 충족합니다. 모니터링 단계로 보세요. 보호는 quarantine부터 시작되고, reject는 위조 메일이 누구에게든 닿기 전에 막습니다.

DMARC 레코드의 t=y는 무슨 뜻인가요?

t=y는 RFC 9989의 테스트 모드로, 수신 서버가 게시된 정책보다 한 단계 아래를 적용합니다. 그래서 p=reject는 quarantine처럼, p=quarantine은 none처럼 동작합니다. p=none에는 효과가 없고 보고서도 바뀌지 않습니다. 아직 RFC 7489를 따르는 수신 서버는 이 태그를 모르고 정책을 적힌 그대로 적용합니다. 보고서에서 모든 정상 발신원의 정렬을 확인하면 t=y를 제거하세요.

pct 태그는 아직 사용되나요?

RFC 9989는 0과 100이 아닌 값이 일관되지 않게 적용되었기 때문에 rf, ri와 함께 pct를 삭제했습니다. 현재 수신 서버는 pct를 무시하고 실패한 메일 전체에 정책을 적용합니다. 아직 RFC 7489를 따르는 수신 서버는 비율로 적용하여, quarantine에서 pct=25이면 실패한 메일의 4분의 1만 스팸으로 보내고 나머지는 전달합니다. pct=100은 무해하며, 테스트 단계에는 t=y를 사용하세요.

rua 주소가 왜 "승인되지 않음"으로 나오나요?

보고서가 다른 조직 도메인의 메일함으로 갈 때는 그 도메인이 이름이 yourdomain._report._dmarc.its-host이고 값이 v=DMARC1인 TXT 레코드를 게시해 동의해야 합니다(RFC 9990 §4). 없으면 이를 확인하는 수신 서버는 해당 주소를 건너뜁니다. 이 레코드는 내 DNS가 아니라 보고서를 받는 쪽의 DNS에 둡니다. 보고서 서비스는 모든 고객을 위한 와일드카드를 게시하므로, 보통은 오타이거나 제휴사의 메일함인 경우입니다.

서브도메인마다 DMARC 레코드가 필요한가요?

보통은 필요 없습니다. 레코드가 없는 서브도메인은 조직 도메인의 정책을 따라, 존재하는 서브도메인에는 sp, 존재하지 않는 이름에는 np가 적용되고 둘 다 없으면 p가 적용됩니다. 서브도메인에 다른 정책이 필요할 때만 그곳에 레코드를 게시하세요. www.team.example.com에 대한 team.example.com처럼 중간 이름에 있는 레코드는 더 깊은 이름에 사용되지 않습니다.

도메인이 DMARC 레코드를 두 개 게시하면 어떻게 되나요?

수신 서버는 둘 다 폐기하므로, 하나가 reject여도 DMARC 정책이 적용되지 않고 보고서도 전송되지 않습니다(RFC 9989 §4.10). 보통 옛 레코드를 지우지 않고 새 레코드를 추가했거나 DNS 호스트가 기본 레코드를 추가했을 때 생깁니다. _dmarc에는 레코드를 하나만 두고 나머지를 삭제하세요. 이 도구는 둘 중 의도한 것으로 보이는 쪽을 알려 줍니다.

SPF는 통과하는데 DMARC가 실패하는 이유는 무엇인가요?

DMARC는 From: 주소와 정렬되는 도메인에서 SPF가 통과해야 합니다. 대부분의 메일 서비스는 자체 반송 도메인으로 발송하므로, SPF는 서비스 쪽에서 통과하고 내 도메인에서는 통과하지 않아 인정되지 않습니다. 서비스의 도메인으로 서명한 DKIM도 마찬가지입니다. 서비스의 커스텀 DKIM이나 커스텀 반송 경로를 설정해서 통과하는 도메인이 내 도메인이 되게 하세요.

방금 레코드를 추가했는데 도구에는 레코드가 없다고 나옵니다. 왜 그런가요?

먼저 호스트 입력란을 확인하세요. 대부분의 DNS 관리 화면에는 _dmarc만 입력해야 하며, _dmarc.example.com을 입력하면 _dmarc.example.com.example.com이 만들어집니다. 그다음 이전 응답이 만료되기를 기다리세요. 그 이름이 이전에 조회되었다면 리졸버는 영역의 네거티브 TTL(보통 5분에서 1시간) 동안 NXDOMAIN을 보관합니다. SERVFAIL이나 시간 초과는 "확인하지 못함"으로 표시되며, 레코드 없음으로 표시되지 않습니다.

부족한 점이 있습니까?기능 또는 새 도구 제안하기

관련 이메일 및 DNS 도구