DMARC record checker
Enter a domain. We read the policy at its _dmarc hostname and tell you what receivers are being asked to do with mail that fails.
Why the policy alone is the wrong thing to look at
Most guidance treats DMARC as a ladder to climb: none, then quarantine, then reject. That is the right sequence, and it hides the part that actually costs people money. The policy is only half of a DMARC record. The other half is the reporting address, and a record with p=none and no rua does nothing whatsoever.
It satisfies the Google and Yahoo requirement for bulk senders, which is why so many domains have one. It also produces no reports, tells you nothing about who is sending as you, and gives you no basis for moving to enforcement. A year later the domain is exactly where it started.
The order that works is boring. Publish p=none with a real rua address. Read the reports for a month, and find the systems you forgot about: the invoicing tool, the recruitment platform, the monitoring alerts from a server someone set up in 2019. Fix their SPF and DKIM so they align. Then move to quarantine on a percentage, and only then to reject.
| Tag | What it does | Common mistake |
|---|---|---|
| p | The policy for the domain itself | Set to reject before the reports were read |
| sp | The policy for subdomains | Left out, so subdomains inherit and nobody notices |
| rua | Where daily aggregate reports go | Missing, which makes p=none pointless |
| pct | How much failing mail the policy applies to | Left at 25 during a rollout that was never finished |
| adkim / aspf | Strict or relaxed alignment | Set to strict, which breaks most ESPs |
What the reports actually contain
Aggregate reports arrive daily as compressed XML, one per receiving provider. Each one lists the IP addresses that sent mail claiming your domain, how many messages came from each, and whether SPF and DKIM aligned.
They do not contain message content, subject lines or recipient addresses. That is worth knowing before you worry about the privacy of pointing rua at a shared mailbox, and it is also why the reports cannot tell you which specific message failed.
Raw XML is unpleasant to read at volume. Plenty of services parse it for you, and a small domain can get by reading a few by hand for the first two weeks. Either way, the reports are the evidence, and enforcing a policy without them is guessing with your own mail as the stake.
Questions people ask
Will p=reject stop people spoofing my brand?
It stops them using your exact domain in the From: address, which is the most convincing version of the attack. It does nothing about a similar-looking domain registered yesterday, and that is the more common approach now.
My mail passes SPF but fails DMARC. How?
SPF passed for the envelope sender, which belongs to your ESP rather than to you. DMARC needs the authenticated domain to match the From: domain, so you need either a custom Return-Path or a DKIM signature from your own domain.
Should sp be set explicitly?
On a domain with subdomains you never send from, yes: sp=reject closes a route that attackers do use. If your subdomains send real mail, leave it inheriting until their own authentication is in order.
How long should I stay on p=none?
Long enough to see a full business cycle in the reports, which for most companies is four to six weeks. Monthly invoicing and quarterly mailings surface senders that two weeks misses.
Authenticated mail to a dead address still bounces
DMARC is about who may send. Verification is about whether anyone is there to receive. We report both halves of that, including the addresses nobody can settle.