Kiểm Tra DMARC

Kiểm tra bản ghi DMARC của mọi tên miền giống cách một máy chủ thư nhận đọc nó: chính sách được tìm thấy ở đâu, thư không qua được sẽ bị xử lý ra sao, báo cáo có đến tay ai không, và SPF cùng DKIM cần gì trước khi bạn thực thi.

Cập nhật: 25 tháng 10, 2026

Nguồn: các bản ghi TXT _dmarc của tên miền và của các tên miền cha, qua Google Public DNS (phía sau là Cloudflare 1.1.1.1) · duyệt cây DNS theo RFC 9989 · ủy quyền báo cáo theo RFC 9990 · SPF và DKIM từ các công cụ kiểm tra của chính chúng tôi · không lưu gì về bạn

Cách kiểm tra bản ghi DMARC?

Hãy nhập một tên miền ở trên: công cụ hỏi DNS bản ghi TXT tại _dmarc. cộng với tên miền, đi ngược lên tên miền tổ chức khi không có (RFC 9989 §4.10), và cho thấy máy chủ nhận làm gì với thư không qua được.

Làm thủ công thì hỏi đúng tên đó: dig +short TXT _dmarc.paypal.com, hoặc nslookup -type=TXT _dmarc.paypal.com trên Windows. Một câu trả lời bắt đầu bằng v=DMARC1 là bản ghi; hai câu trả lời nghĩa là máy chủ nhận không dùng cái nào (RFC 9989 §4.10).

dig dừng ở đó. Nó không đi ngược lên từ một tên miền con, không kiểm tra xem các địa chỉ báo cáo có chịu nhận báo cáo không, cũng không cho biết máy chủ nhận theo RFC nào. Đó là phần công cụ này bổ sung.

% dig +short TXT _dmarc.example.com

Mọi câu trả lời tại tên đó. Câu bắt đầu bằng v=DMARC1 là bản ghi.

Điều dig cho thấy, và điều nó không cho thấy

dòng lệnh

$ 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

1Tên là _dmarc. cộng với tên miềnKhông phải chính tên miền: TXT tại paypal.com là chỗ của SPF.
2Một bản ghi, v=DMARC1 đứng đầuHai bản ghi tại một tên: máy chủ nhận bỏ cả hai (RFC 9989 §4.10).
3Các tag, ngăn cách bằng ;p là chính sách; rua và ruf cho biết báo cáo gửi đi đâu.
4Không có gì ở đây? Đi ngược lên_dmarc.mail.google.com là NXDOMAIN: bản ghi của google.com áp dụng.

Bản ghi của paypal.com như Google Public DNS trả về ngày 24 tháng 10, 2026; mail.google.com không có bản ghi riêng.

Đọc kết quả: góc nhìn của máy chủ nhận

Câu trả lời đến trước, dưới dạng một câu. Bên dưới là bằng chứng: bản ghi như máy chủ nhận phân tích, mỗi tag được tô màu đúng trên các ký tự của nó, và trên nền xanh navy là đường đi mà một máy chủ nhận theo cho tên miền này, kết thúc ở điều nó làm với thư không qua được.

Không chấm điểm: chính sách ở none là một giai đoạn, không phải một thất bại, và chặng đường bên dưới đường đi cho biết bước tiếp theo cần gì.

Kiểm tra DMARC cho paypal.com: từ chối thư không qua được DMARC, kèm góc nhìn của máy chủ nhận và chặng đường thực thi — Kết quả kiểm tra DMARC của paypal.com: kết luận, bản ghi tách thành từng tag, góc nhìn của máy chủ nhận với mọi câu hỏi DNS và điều xảy ra với thư không qua được, và chặng đường thực thi. Chọn một số để xem từng phần thể hiện điều gì.

DMARC là gì và dùng để làm gì?

DMARC cho các máy chủ thư nhận biết phải làm gì với thư dùng tên miền của bạn ở dòng From: nhưng không chứng minh được nó đến từ bạn, và gửi báo cáo về chúng đi đâu (RFC 9989 §4.7).

Bằng chứng là SPF hoặc DKIM, căn chỉnh (aligned) với tên miền From:: SPF pass cho một tên miền bounce trong cùng tổ chức, hoặc một chữ ký DKIM có d= là tên miền của bạn. Một kết quả pass đã căn chỉnh là đủ (RFC 9989 §5.3.5); mọi trường hợp khác đều không qua được DMARC, và chính sách trong bản ghi quyết định: chuyển đi, đưa vào thư rác hoặc từ chối.

Báo cáo là nửa còn lại. Các máy chủ nhận tôn trọng rua gửi bản tóm tắt hằng ngày về mọi máy chủ đã gửi thư dưới danh nghĩa tên miền của bạn, nhờ đó bạn tìm ra các bên gửi hợp lệ mình đã quên trước khi thực thi.

Hai thư, một dòng From:

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

Hóa đơn của bạn, gửi qua một dịch vụ emailqua một dịch vụ được thiết lập DKIM tùy chỉnh, nên nó ký bằng d=example.com

SPFpass · bounces.esp.example (không căn chỉnh)
DKIMpass · d=example.com (căn chỉnh)
DMARCpass: một kết quả căn chỉnh là đủ

Đã chuyển đi

Một hóa đơn giả từ 203.0.113.9một máy chủ mà example.com chưa bao giờ cho phép

SPFfail · 203.0.113.9 không có trong danh sách
DKIMkhông có · không có chữ ký
DMARCfail → p=reject

Bị từ chối

550 5.7.1 Email rejected per DMARC policy for example.com

Báo cáo tổng hợp ngày mai gửi tới dmarc@example.com: 1 thư từ 203.0.113.9, SPF fail, không có DKIM, xử lý reject.

Pass không đảm bảo thư được chuyển (bộ lọc của máy chủ nhận vẫn quyết định), và fail ở p=reject là một yêu cầu, không phải mệnh lệnh (RFC 9989 §5.4, §7.4). Các địa chỉ lấy từ RFC 5737; nội dung phản hồi là ví dụ của chính RFC 9989.

Giải thích các tag trong bản ghi DMARC

Bản ghi DMARC là một danh sách các cặp tag=value trong một bản ghi TXT tại _dmarc. cộng với tên miền: v=DMARC1 đứng đầu, rồi đến các tag chính sách, căn chỉnh và báo cáo theo thứ tự bất kỳ (RFC 9989 §4.7).

RFC 9989 (tháng 5 năm 2026) đã thay thế RFC 7489. Nó thêm np, psd và t, và bỏ pct, rf và ri: các máy chủ nhận hiện hành bỏ qua những tag đó, còn máy chủ nhận vẫn theo RFC 7489 thì đọc chúng, nên một bản ghi có pct=25 mang nghĩa khác nhau với các máy chủ nhận khác nhau.

Các tag bạn không công bố sẽ nhận giá trị mặc định, và công cụ cũng hiển thị chúng: thiếu sp nghĩa là các tên miền con nhận p.

Mọi tag, theo điều nó làm

v=DMARC1; p=reject; sp=quarantine; np=reject; adkim=r; aspf=r; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; fo=1

Phiên bảnChính sáchThử nghiệm và suffixCăn chỉnhBáo cáoĐã bỏ

Tag	Nó đặt gì	Mặc định	Trạng thái	Gặp trong
v	Phiên bảnDMARC1	bắt buộc, đứng đầu	RFC 9989	192
p	Chính sách cho tên miềnnone · quarantine · reject	none nếu thiếu và rua hợp lệ	RFC 9989	192
sp	Chính sách cho các tên miền con đang tồn tạinone · quarantine · reject	p	RFC 9989	39
np	Chính sách cho các tên không tồn tạinone · quarantine · reject	sp, rồi p	mới trong RFC 9989	2
t	Chế độ thử nghiệm: thấp hơn chính sách một bậcy · n	n	mới trong RFC 9989	0
psd	Public suffix (y) hoặc tên miền tổ chức (n)y · n · u	u	mới trong RFC 9989	1
adkim	Căn chỉnh DKIMr · s	r	RFC 9989	20
aspf	Căn chỉnh SPFr · s	r	RFC 9989	24
rua	Nơi báo cáo tổng hợp được gửimailto:…	không có báo cáo	RFC 9989	186
ruf	Nơi báo cáo lỗi được gửimailto:…	không có báo cáo	RFC 9989	120
fo	Khi nào gửi báo cáo lỗi0 · 1 · d · s	0	RFC 9989	96
pct	Tỷ lệ thư không qua được mà chính sách áp dụng0–100	–	đã bỏ	70
rf	Định dạng báo cáo lỗiafrf	–	đã bỏ	9
ri	Chu kỳ báo cáo, tính bằng giây86400	–	đã bỏ	14

Gặp trong: có bao nhiêu trong 192 bản ghi DMARC do 196 tên miền nổi tiếng công bố mang tag này (đọc ngày 24 tháng 10, 2026; 69 trong 70 tag pct ghi pct=100). Giá trị mặc định và trạng thái theo RFC 9989 §4.7 và Phụ lục C.

Chính sách DMARC: p=none, quarantine hay reject

p=none yêu cầu máy chủ nhận chuyển thư không qua được như bình thường và chỉ báo cáo; quarantine yêu cầu coi nó là đáng ngờ, thường là cho vào thư rác; reject yêu cầu từ chối nó ngay trong phiên SMTP.

None là một giai đoạn, không phải một thất bại: RFC 9989 §7.4 gợi ý ở đó ít nhất một tháng với báo cáo đều đặn, và thêm ngần ấy thời gian ở quarantine, rồi mới lên reject. Các tên miền có người đăng bài lên danh sách thư nên dừng ở quarantine.

Các nhà cung cấp hộp thư lớn cũng chia khác nhau: gmail.com và outlook.com công bố p=none cho chính tên miền và sp=quarantine cho các tên miền con, trong khi google.com, yahoo.com và microsoft.com công bố reject.

Một thư giả mạo kết thúc ở đâu

Chuyển đip=none

apache.orggmail.comsamsung.com

23 trên 192

Thư rácp=quarantine

github.comapple.comamazon.com

30 trên 192

Bị từ chốip=reject

google.compaypal.commicrosoft.com

139 trên 192

Rốt cuộc máy chủ nhận quyết định: họ có thể chuyển thư không qua được ở p=reject, và không được từ chối chỉ dựa vào chính sách (RFC 9989 §5.4, §7.4). Một nghiên cứu của nhà cung cấp cho thấy phần còn lại của web tụt lại phía sau đến mức nào: trong 1,8 triệu tên miền hàng đầu vào đầu năm 2026, EasyDMARC thấy 29,2% ở p=none và 22,9% ở quarantine hoặc reject.

DMARC có thực sự cần thiết không?

Có, nếu bạn gửi hàng loạt tới Gmail, Yahoo hoặc Outlook.com: cả ba đều yêu cầu bản ghi DMARC, và p=none là đủ để đạt quy tắc. Thực thi (quarantine hoặc reject) mới là thứ ngăn người khác gửi thư dưới danh nghĩa tên miền của bạn, và logo BIMI cũng cần nó.

Gmail yêu cầu từ 1 tháng 2, 2024 với bên gửi hơn 5.000 thư mỗi ngày tới các tài khoản Gmail; Yahoo từ tháng 2 năm 2024, không nêu khối lượng; Outlook.com từ 5 tháng 5, 2025, với hơn 5.000 thư mỗi ngày. Khi không có bản ghi, Gmail trả lời 4.7.31 (và 4.7.32 khi From: không căn chỉnh), còn Outlook.com từ chối với 550 5.7.515.

Với một tên miền không gửi gì, DMARC là cách bảo vệ rẻ nhất: p=reject, một null MX và v=spf1 -all, như example.com công bố (M3AAWG).

Mỗi nhà cung cấp hộp thư yêu cầu gì ở bên gửi hàng loạt

Gmail1 thg 2, 2024hơn 5.000 thư mỗi ngày tới tài khoản Gmail4.7.31 · 4.7.32

Yahoothg 2 2024không công bố ngưỡngDMARC phải pass

Outlook.com5 thg 5, 2025hơn 5.000 thư mỗi ngày550 5.7.515

Chuyển đip=noneđạt quy tắc của cả ba nhà cung cấp

Thư rácquarantinechặn phần lớn giả mạo · có thể dùng logo BIMI

Bị từ chốirejectchặn giả mạo ngay cửa · BIMI

✓Bắt buộc: một bản ghi, p=none hoặc chặt hơniBảo vệ: quarantine hoặc reject

Từ các trang dành cho bên gửi của chính mỗi nhà cung cấp, đọc ngày 24 tháng 10, 2026. Tỷ lệ spam dưới 0,3% và hủy đăng ký một chạm cũng là quy tắc, nhưng DNS không cho thấy được; chế độ xem Yêu cầu của công cụ cho biết những phần nào nó chứng minh được.

Cách sửa lỗi DMARC fail: chuyển tiếp, danh sách thư, tên miền riêng của nhà cung cấp

Hãy tìm nguồn gửi bị lỗi trong các báo cáo tổng hợp, rồi sửa ở phía bên gửi: ký nó bằng DKIM cho tên miền của chính bạn, hoặc chuyển nó sang một tên miền bounce trong tổ chức của bạn. Ba nguyên nhân bao phủ phần lớn các lỗi.

Chuyển tiếp giữ nguyên chữ ký DKIM nhưng làm hỏng SPF, nên DKIM gánh việc pass. Danh sách thư chỉnh sửa nội dung làm hỏng cả hai. Còn một dịch vụ email ký bằng tên miền riêng của nó thì pass DKIM cho chính nó, không phải cho bạn: hãy bật DKIM tùy chỉnh của dịch vụ (thường là các CNAME như s1._domainkey) và một return path tùy chỉnh.

Ba lỗi, điều báo cáo cho thấy, và cách sửa

Chuyển tiếp

SPF192.0.2.80 không có trong SPF của example.com
DKIMchữ ký còn nguyên

Báo cáo cho thấyspf=fail dkim=pass → pass

Ký DKIM mọi thư; DKIM sống sót qua chuyển tiếp. ARC (RFC 8617) giúp bên chuyển tiếp bảo chứng.

Danh sách thư

SPFmáy chủ của danh sách gửi
DKIMnội dung đã đổi: hash lỗi

Báo cáo cho thấyspf=fail dkim=fail → fail

Các danh sách viết lại From: tự khắc phục; các tên miền có người đăng lên danh sách thì dừng ở quarantine (RFC 9989 §7.4).

Tên miền riêng của nhà cung cấp

SPFpass cho bounces.esp.example: không căn chỉnh
DKIMpass cho esp.example: không căn chỉnh

Báo cáo cho thấydkim=pass(esp.example) → fail

Bật DKIM tùy chỉnh của nhà cung cấp: s1 và s2 của paypal.com là các CNAME trỏ tới SendGrid, nơi ký với tư cách paypal.com.

Các địa chỉ lấy từ RFC 5737; esp.example là tên giả. Các CNAME SendGrid là selector thật của paypal.com (24 tháng 10, 2026).

DMARC cho tên miền con: sp và np

Một tên miền con không có bản ghi riêng nhận chính sách của tên miền tổ chức: sp cho các tên miền con đang tồn tại, np cho các tên không tồn tại, mỗi cái lùi về p (RFC 9989 §4.7).

Một tên miền con công bố bản ghi riêng thì dùng nó cho chính mình. Nhưng một bản ghi nằm giữa một tên và tên miền tổ chức của nó không bao giờ được dùng cho tên đó: cây của berkeley.edu cho thấy điều này, khi sp=none của eecs.berkeley.edu không tới được www.eecs.berkeley.edu (RFC 9989 §4.10.1).

np là chiến thắng rẻ: các tên không tồn tại không gửi thư thật, nên np=reject chặn thư giả mạo từ chúng ngay cả khi p vẫn ở none. Máy chủ nhận theo RFC 7489 không biết np và dùng sp.

Cây của berkeley.edu, như một máy chủ nhận đọc

berkeley.edup=reject; np=reject; psd=n; rua=…bản ghi riêng · psd=n: tên miền tổ chứcBị từ chối

www.berkeley.edukhông có bản ghitồn tại → sp, không có → pBị từ chối

eecs.berkeley.edup=reject; sp=none; rua=…bản ghi riêng → pBị từ chối

www.eecs.berkeley.edukhông có bản ghiđi ngược: bản ghi của eecs.berkeley.edu bị bỏ qua (không phải tên miền tổ chức) → p của berkeley.eduBị từ chối

nosuch-x7.berkeley.eduNXDOMAINkhông tồn tại → npBị từ chối

sp=none của eecs.berkeley.edu không bao giờ được áp dụng: một bản ghi nằm giữa một tên và tên miền tổ chức của nó không được dùng cho tên đó (RFC 9989 §4.10.1). Công cụ đánh dấu nó là một bản ghi không được dùng.

Đọc ngày 24 tháng 10, 2026 qua Google Public DNS. nosuch-x7.berkeley.edu là một tên bịa; NXDOMAIN của nó là thật.

Đọc báo cáo DMARC (rua)

Báo cáo tổng hợp là một tệp XML hằng ngày từ mỗi máy chủ nhận, liệt kê mọi máy chủ đã gửi thư dưới danh nghĩa tên miền của bạn, bao nhiêu thư, và SPF, DKIM, DMARC có pass không (RFC 9990).

Hãy đọc theo từng nguồn: máy chủ và dịch vụ của chính bạn nên cho thấy pass đã căn chỉnh; một dịch vụ quen thuộc bị fail cần DKIM tùy chỉnh của nó; một địa chỉ lạ bị fail ở p=reject là giả mạo, đã bị chặn. Một dịch vụ báo cáo (dmarcian, Valimail, EasyDMARC, Postmark và những dịch vụ khác) biến hàng nghìn tệp thành danh sách đó.

Báo cáo gửi tới địa chỉ ở tên miền khác chỉ đến nơi nếu tên miền đó đồng ý: nó công bố yourdomain._report._dmarc.its-host với v=DMARC1 (RFC 9990 §4). Công cụ hỏi giúp bạn, và đưa đúng bản ghi cần có khi nó thiếu.

Một báo cáo, đọc từng dòng

<org_name>google.com</org_name>1

<date_range>00:00 UTC 23 thg 10 – 00:00 UTC 24 thg 10</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

1Ai báo cáoMột tệp cho mỗi máy chủ nhận mỗi ngày (RFC 9990: ít nhất mỗi 24 giờ).
2Chính sách nó thấyĐiều nó đọc được tại _dmarc.example.com.
3Thư được chuyển tiếp, DKIM cứuSPF fail ở bên chuyển tiếp; chữ ký đã căn chỉnh pass DMARC.
4Giả mạo, đã bị chặnMột máy chủ lạ, không có gì căn chỉnh, bị từ chối.

paypal.comrua=mailto:d@rua.agari.comrua.agari.compaypal.com._report._dmarc.rua.agari.com TXT "v=DMARC1;"✓ đã ủy quyền: báo cáo được gửi

Các dịch vụ báo cáo mà công cụ nhận radmarcianValimailEasyDMARCPostmarkCloudflareMimecastProofpointAgariRed SiftPowerDMARC+6 nữa

XML đã được rút gọn và bịa ra (địa chỉ dành cho tài liệu, RFC 5737); bản ghi ủy quyền là bản thật của paypal.com, đọc ngày 24 tháng 10, 2026.

Kiểm tra DMARC: câu hỏi thường gặp

DMARC là gì?

DMARC là một bản ghi DNS cho các máy chủ thư nhận biết phải làm gì với thư dùng tên miền của bạn ở dòng From: nhưng không qua được căn chỉnh SPF và DKIM: chuyển đi, cách ly hoặc từ chối. Nó cũng nêu nơi máy chủ nhận gửi báo cáo về thư đó. Nó được công bố dưới dạng bản ghi TXT tại _dmarc cộng với tên miền của bạn, và được định nghĩa trong RFC 9989, thay thế RFC 7489 vào tháng 5 năm 2026.

Công cụ kiểm tra bản ghi DMARC cho thấy gì?

Nó đọc bản ghi TXT tại _dmarc cộng với tên miền, và của các tên miền cha khi không có, giống cách một máy chủ nhận làm. Công cụ này cho thấy bản ghi theo từng tag kèm giá trị mặc định, chính sách cho tên miền, các tên miền con và các tên không tồn tại, các địa chỉ báo cáo có chịu nhận báo cáo không, cùng bản ghi SPF và các khóa DKIM của tên miền, không chấm điểm.

Làm sao để kiểm tra DMARC?

Hãy kiểm tra tên miền ở trên để xem chính sách đã công bố: đó là phần kiểm tra DMARC mà DNS trả lời được. Để biết một thư thật có pass không, hãy gửi một thư tới hộp thư bạn kiểm soát và đọc header Authentication-Results của nó, hoặc dán các header vào Phân Tích Header Email. Một công cụ xác thực DMARC kiểm tra cú pháp bản ghi; chỉ một thư mới cho thấy SPF hay DKIM có căn chỉnh không.

Nên bắt đầu với chính sách DMARC nào?

Hãy bắt đầu với p=none và một địa chỉ rua, để máy chủ nhận gửi báo cáo hằng ngày mà không đổi việc chuyển thư. Sửa mọi bên gửi hợp lệ bị fail, thường bằng cách bật DKIM tùy chỉnh của họ, rồi lên quarantine và cuối cùng là reject. RFC 9989 gợi ý ít nhất một tháng ở p=none và thêm ngần ấy thời gian ở quarantine. Một tên miền không gửi thư có thể lên thẳng p=reject.

p=none có bảo vệ tên miền của tôi không?

Không. p=none yêu cầu máy chủ nhận xử lý thư không qua được như bình thường, nên một thư giả mạo chỉ bị bộ lọc spam của chính họ đánh giá. Điều nó mang lại là báo cáo, và nó đạt quy tắc dành cho bên gửi hàng loạt của Gmail, Yahoo và Outlook.com. Hãy coi nó là giai đoạn giám sát: bảo vệ bắt đầu từ quarantine, và reject chặn thư giả mạo trước khi nó tới bất kỳ ai.

t=y nghĩa là gì trong bản ghi DMARC?

t=y là chế độ thử nghiệm của RFC 9989: máy chủ nhận áp dụng thấp hơn chính sách đã công bố một bậc, nên p=reject hoạt động như quarantine và p=quarantine như none. Nó không có tác dụng với p=none và không đổi báo cáo. Máy chủ nhận vẫn theo RFC 7489 không biết tag này và áp dụng chính sách đúng như đã viết. Hãy bỏ t=y khi báo cáo cho thấy mọi bên gửi hợp lệ đều căn chỉnh.

Tag pct còn được dùng không?

RFC 9989 đã bỏ pct, cùng rf và ri, vì các giá trị khác 0 và 100 bị áp dụng không nhất quán. Máy chủ nhận hiện hành bỏ qua nó và áp dụng chính sách cho mọi thư không qua được. Máy chủ nhận vẫn theo RFC 7489 thì lấy mẫu: pct=25 ở quarantine đưa một phần tư số thư không qua được vào thư rác và chuyển phần còn lại. pct=100 vô hại; cho giai đoạn thử nghiệm, hãy dùng t=y.

Vì sao địa chỉ rua của tôi "chưa được ủy quyền"?

Khi báo cáo gửi tới một hộp thư ở tên miền tổ chức khác, tên miền đó phải đồng ý bằng cách công bố bản ghi TXT tên yourdomain._report._dmarc.its-host với giá trị v=DMARC1 (RFC 9990 §4). Thiếu nó, các máy chủ nhận có kiểm tra sẽ bỏ qua địa chỉ. Bản ghi nằm trong DNS của bên nhận, không phải của bạn: các dịch vụ báo cáo công bố một wildcard cho mọi khách hàng, nên thường đây là lỗi gõ hoặc hộp thư của một đối tác.

Tên miền con có cần bản ghi DMARC riêng không?

Thường là không. Một tên miền con không có bản ghi nhận chính sách của tên miền tổ chức: sp cho các tên miền con đang tồn tại, np cho các tên không tồn tại, cả hai đều lùi về p. Chỉ công bố một bản ghi trên tên miền con khi nó cần chính sách khác. Một bản ghi ở tên trung gian, như team.example.com cho www.team.example.com, không được dùng cho tên sâu hơn.

Điều gì xảy ra nếu một tên miền công bố hai bản ghi DMARC?

Máy chủ nhận bỏ cả hai, nên không có chính sách DMARC nào áp dụng và không báo cáo nào được gửi, kể cả khi một trong hai ghi reject (RFC 9989 §4.10). Thường điều này xảy ra khi thêm bản ghi mới mà không xóa bản cũ, hoặc khi một nhà cung cấp DNS thêm bản ghi mặc định. Hãy giữ một bản ghi tại _dmarc và xóa bản còn lại; công cụ cho biết bản nào có vẻ là bản được dự định.

Vì sao DMARC fail khi SPF pass?

DMARC cần SPF pass cho một tên miền căn chỉnh với địa chỉ From:. Hầu hết dịch vụ email gửi bằng tên miền bounce riêng của họ, nên SPF pass cho họ, không phải cho bạn, và nó không được tính. DKIM ký bằng tên miền của dịch vụ cũng vậy. Hãy thiết lập DKIM tùy chỉnh hoặc return path tùy chỉnh của dịch vụ để tên miền pass là của bạn.

Công cụ không thấy bản ghi, nhưng tôi vừa thêm rồi. Vì sao?

Trước hết hãy kiểm tra ô host: hầu hết bảng quản lý DNS chỉ muốn _dmarc, và gõ _dmarc.example.com vào đó sẽ tạo ra _dmarc.example.com.example.com. Sau đó chờ câu trả lời cũ hết hạn: nếu tên đã được tra trước đó, các resolver giữ NXDOMAIN của nó trong TTL âm của zone, thường từ 5 phút đến một giờ. SERVFAIL hoặc hết thời gian được hiển thị là "không kiểm tra được", không bao giờ là không có bản ghi.