DMARC Record Checker

What DMARC adds to SPF and DKIM

SPF and DKIM answer technical questions: is this server allowed, and was the message altered. Neither tells the receiver what to do when a check fails. DMARC is exactly that instruction, and it adds one more requirement — the authenticated domain has to match the address the recipient sees in the From field.

The second reason to deploy it is reporting. Once a day mailbox providers send a summary: how much mail claimed to be from you, from which addresses, and how much passed authentication. Without that data you know nothing about spoofing, or about your own campaigns quietly failing authentication.

Three stages of rollout

1. p=none — monitoring. Delivery is unchanged, reports accumulate. Usually kept for two to four weeks.
2. p=quarantine — failing mail goes to spam. Enable once no legitimate senders show up as failing in the reports.
3. p=reject — failing mail is rejected outright. The end goal, and what Gmail and Yahoo expect from bulk senders.

Example record

v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc@example.com; adkim=r; aspf=r

Published as a TXT record at _dmarc.example.com. The v tag must come first and p second; the rest can be in any order. A record on the organisational domain also covers subdomains that have none of their own.

What usually goes wrong

• The record sits at p=none for years. Nobody reads the reports, nothing is protected, but the compliance box is ticked.
• rua on an external domain without authorisation. Reports never arrive, and nothing indicates why — just silence.
• p=reject with active subdomains. Mail from subdomains starts being rejected if they have no authentication of their own.
• sp=none under a strict p. Subdomains stay wide open to spoofing.