DMARC record checker

What p= actually does

The policy tag is the instruction a receiver follows when a message claiming to be from the domain fails both SPF and DKIM alignment. There are three values and they are not degrees of the same thing.

p=none asks receivers to change nothing and send reports. It is the correct way to start, because it shows you who is sending as your domain before you risk blocking any of them — and it stops no spoofing at all while it is in place. A domain that has sat at p=none for a year is publishing a record that does nothing except generate reports.

p=quarantine asks receivers to treat failing mail as suspicious, which in practice means the spam folder. p=reject asks them to refuse it at the door, so it never reaches a mailbox and the sender gets a bounce. Only the last one actually prevents a forged message from being read.

sp= is the one people forget

Without sp=, subdomains inherit the domain’s policy. With it, they get their own — and an sp= weaker than p= leaves every subdomain spoofable while the apex looks protected. That matters more than it sounds, because a forger does not need your exact domain: a message from billing.yourdomain.com is just as convincing to the person reading it, and nothing stops them inventing a subdomain that has never existed.

pct= applies the policy to a fraction

pct=20 means receivers apply the policy to roughly a fifth of failing messages and fall back to the next weaker treatment for the rest. It exists so a rollout can be taken in steps rather than in one move. Left at anything below 100, it means most forged mail is still getting the old treatment, which is usually not what the person who set it expects when they read their own record back.

Two DMARC records mean the domain has none

RFC 7489 §6.6.3 is unusually blunt about this: if more than one DMARC record is published at _dmarc, receivers must treat the domain as having no policy at all. It is an easy mistake to make and an invisible one to live with — two teams each add the record they were asked for, both are syntactically perfect, and the domain quietly loses the protection both of them were trying to add.

Why reports stop arriving without anything breaking

If rua= points at a mailbox on a domain you do not control — a reporting vendor, or simply a different domain of your own — that domain has to say it is willing to receive them. It does that by publishing a TXT record at yourdomain.com._report._dmarc.theirdomain.com containing v=DMARC1. RFC 7489 §7.1 requires it, and conforming receivers check it before sending anything.

When it is missing, nothing looks wrong. Your record is valid, the vendor’s dashboard is empty, and there is no bounce and no error to search for. That is the check this page runs for each external address, and it is the part most tools leave out.

One limit worth stating: deciding that two names belong to the same organisation needs the public suffix list, which this tool deliberately does not carry. So a destination is only treated as external when it is neither the domain itself nor a subdomain of it. Reports going to a sibling domain you own may be reported as needing authorisation when the receiver would not require it.

What this cannot tell you

It cannot tell you whether your own mail passes. DMARC is evaluated per message, at delivery time, against the connecting server and the signatures on that specific message — none of which exists here. The record says what receivers have been asked to do; it says nothing about how much of your real mail would survive it.

Finding that out is what the reports are for. If you have some, the DMARC report reader turns one into a table in your browser, without uploading it. If you are writing a record rather than reading one, the DMARC record generator builds one from answers.

Why any of this matters to you

DMARC protects the people who receive mail claiming to be from a domain. It does nothing for the address you hand over when you sign up for something — that address is still yours, still permanent, and still readable by whoever the company sells their list to.

Giving each sender a different address is the thing Maski does, and it means that when one of them leaks, you switch off that one address instead of changing your mail provider.