DMARC Record Checker

Enter a domain to fetch its DMARC record from _dmarc.yourdomain, validate every tag, and see in plain terms what the policy does — and, just as importantly, what it does not.

The most common finding is a record set to p=none. That collects reports but blocks nothing, and a great many domains have sat there for years believing they were protected.

How it works

DMARC ties SPF and DKIM to the From: address a recipient actually sees, and tells receiving servers what to do when authentication fails. Without it, SPF and DKIM validate parts of a message that the recipient never looks at, which is precisely the gap spoofing exploits.

The policy tag p= is the part that matters:

• p=none — monitor only. You receive reports; nothing is blocked. A correct starting point, not a destination.
• p=quarantine — failing mail goes to spam. Real protection, with a safety net.
• p=reject — failing mail is refused outright. The goal, and the only setting that actually stops your domain being spoofed.

Two things must be true before p=reject is safe. First, every legitimate sender must pass SPF or DKIM — including invoicing systems, CRMs and application servers people forget about. Second, authentication must align: the domain that passes SPF or DKIM has to match the From: domain. A message can pass SPF for the sending platform's own domain and still fail DMARC, which surprises people constantly.

The practical path is: publish p=none with a rua= address, read the aggregate reports for a few weeks until you recognise every sender, move to p=quarantine, then to p=reject. Use pct= to ramp gradually if the domain sends significant volume.

One subtlety worth knowing: sp= sets the policy for subdomains. If it is absent, subdomains inherit p=. If you publish p=reject but sp=none, attackers can still spoof anything.yourdomain.com freely.

Frequently asked questions