DMARC checker

DMARC is a TXT record published at _dmarc.yourdomain.com. It tells receiving mail servers two things: what to do with mail that claims to be from your domain but fails authentication, and where to send the aggregate reports that show you who is sending as you. The policy is the p tag: none means deliver anyway, quarantine means send it to spam, reject means refuse it.

DMARC only works on top of SPF and DKIM. A message passes DMARC when at least one of them passes with a domain that aligns with the visible From address. Without DMARC, SPF and DKIM still authenticate mail, but nothing connects them to the From address a person actually sees, and that From address is the thing forgers forge.

This is the warning wording several audit tools use for a record whose policy is p=none, and it reads scarier than it is. p=none is not broken DMARC: it is monitoring mode, the stage where receivers check every message, tell you the results in reports, and take no action. Every serious rollout starts there, because turning enforcement on before the reports are clean is how you lose your own legitimate mail.

It becomes a real problem when a domain sits at p=none forever, or runs p=none without any rua reporting address. That second case is the one this checker calls out by name: with no policy and no reports, the record monitors nothing and enforces nothing. It exists to satisfy a checklist, and it does no work at all.

If no record answers at _dmarc.yourdomain.com, receivers apply no policy to mail forged as your domain, and there is no reporting address, so you never learn it is happening. Publishing a first record is deliberately low-risk: v=DMARC1; p=none; rua=mailto:[email protected] changes nothing about delivery and starts the reports flowing.

Mailbox providers have also made a record table stakes for volume senders: Google and Yahoo require bulk senders to publish at least a p=none DMARC record for mail to their users. A missing record is no longer just a security gap, it is a deliverability gap.

A message fails DMARC when neither SPF nor DKIM produces an aligned pass: SPF passed but for a different domain than the From address, DKIM was missing or broken, or both. Forgery is one cause. The other is your own mail sent through a service you never authenticated, which is exactly what the aggregate reports exist to reveal.

Forwarding is the classic false alarm: a forwarded message usually breaks SPF alignment because the forwarder becomes the sender, and survives on DKIM alone if the signature is intact. That is one reason a domain should not depend on a single authentication path, and the deliverability test on this site checks for exactly that.

A domain that sends no mail at all still benefits from DMARC, just in the opposite direction: v=DMARC1; p=reject plus an SPF record of v=spf1 -all tells receivers that any mail claiming to be that domain is forged. If you hold unused domains, that is a five-minute job worth doing. The honest version of "you do not need to care" is narrow: a throwaway domain nobody would gain anything by forging.