Every tag checked against the spec, the corrected record for the policy you are on, and the exact record for each step from monitoring to p=reject — with what to look for before taking the next one.
DMARC is eleven tags and a great deal of consequence. Here is what each part decides, and which mistakes quietly delete the whole policy.
The policy receivers apply when a message fails authentication.
p=none asks receivers to report and change nothing. p=quarantine sends failing mail to the spam folder. p=reject refuses it at the SMTP transaction. Only the last one stops someone sending as your domain — and getting there without breaking your own mail is what the staged plan on this page is for.
DMARC does not ask whether SPF passed. It asks whether it passed for your domain.
A message passes DMARC when SPF passes for an envelope domain that aligns with the From address, or DKIM verifies for a signing domain that does. That is why mail can show SPF: pass in its headers and still fail DMARC — the ESP’s bounce domain passed, and your From domain was never checked. adkim= and aspf= decide how strictly "aligns" is read.
rua= is what makes every later step safe.
Aggregate reports are a daily summary from each receiver of everything claiming to be from you, with whether it passed. They are how you find the systems sending as your domain that nobody remembered. DMARC with no rua= is enforcement with the lights off, and we grade it accordingly.
The check almost no tool runs.
If your reports go to a different organisational domain — a reporting service, an agency — RFC 7489 requires THAT domain to publish a record saying it accepts them. Until it does, receivers that honour the rule send nothing. This is the usual reason a perfect-looking record produces no reports, and we look for it.
A rollout dial, not a permanent setting.
pct=25 applies your policy to a quarter of failing mail, so a mistake costs a quarter of the blast radius. It is the right tool while you move from monitoring to enforcement, and a gap if it is still there a year later — which the report will say. pct=0 disables the policy entirely.
Some mistakes weaken a policy. These delete it.
Two DMARC records at _dmarc means receivers must treat the domain as having none. v= not first, or missing, does the same. So does p= with an unrecognised value. Each of these leaves a domain that looks protected in a DNS panel and is not protected anywhere else.
No agent to install, no zone file to upload, no account to create.
Type a domain and we read what is published. Paste a record your provider handed you and we validate that instead — no DNS involved, which is the right moment to catch a typo.
Not just p=. Order, duplicates, misspelled tag names, invalid values, report addresses missing their mailto:, a pct that quietly disables the policy — each one with what it actually costs you.
Your current policy with every fault corrected, plus the exact record for each stage from monitoring to reject — and what to look for in your reports before taking the next one.
Get the policy right, then find out whether the mail it governs actually authenticates. Read the rest of your DNS, or send one real message and see what a receiver sees.
New to this? The guides cover authentication from the ground up.