p=none
Receivers are asked to report and do nothing else. Useful — the reports are how you find your own senders — but the domain remains spoofable while it is set.
It is the most common DMARC configuration and it enforces nothing at all: mail failing SPF and DKIM is delivered exactly as it would be with no DMARC record. It is the right place to start and the wrong place to stay, and this checker says so rather than showing a tick for having a record.
Receivers are asked to report and do nothing else. Useful — the reports are how you find your own senders — but the domain remains spoofable while it is set.
Failing mail is treated as suspicious, usually junk. Better, and still delivered: a spoofed message reaches the mailbox, marked.
Failing mail is refused. The enforcing position, and the only one where the honest answer to "can someone send mail as us?" is no.
Where the daily aggregate reports go. Without it nobody sees who is sending as the domain, which makes tightening the policy a guess. It is the part that does the work.
The reason most domains sit at p=none for years is a reasonable fear: tightening the policy will reject legitimate mail from a system nobody remembers setting up. Invoicing, ticketing, a scanner that emails PDFs, a marketing platform from two jobs ago. The fear is justified — what is not justified is leaving it there, because p=none protects nothing while looking like it does.
The path is: publish p=none with an rua address, read the reports for two to four weeks, and authorise every legitimate sender you find in them. Then move to p=quarantine, watch for a couple of weeks, and then p=reject. The reports are what turn each step from a gamble into a check.
pct= is the other useful lever: it applies the policy to a share of failing mail so a mistake is survivable. It also means the policy is not fully in force, which this checker reports rather than treating a pct=10 reject as a reject.
One thing worth knowing about subdomains. DMARC falls back to the organisational domain when a subdomain has no record of its own, and working out which domain that is requires the public suffix list — which this check does not use. So it reports what is published at exactly the name you entered and tells you when inheritance may apply, rather than guessing.
Only if the policy is quarantine or reject. p=none instructs receivers to take no action, so failing mail is delivered exactly as it would be without any DMARC record. Roughly speaking, having the record means you can see the problem; having a policy means you have done something about it.
In a TXT record at _dmarc.yourdomain.com — not at the domain itself. A DMARC record published at the apex is ignored completely, which is a common and invisible mistake: everything looks configured and no policy is in force.
Compressed XML, sent daily by each receiver, listing the IP addresses that sent mail claiming to be your domain and whether each passed. They are not meant to be read by hand in volume — several services parse them, and for a small domain a few weeks of eyeballing is genuinely workable.
Usually not. Relaxed alignment is the default and allows a subdomain to pass for the parent, which is what makes mail through providers that use their own subdomains work. Strict requires an exact match and breaks that. Use strict only when you know every sender matches exactly.
It needs at least one to pass and to be aligned with the visible From domain. In practice publish both: SPF breaks when mail is forwarded, because the forwarder becomes the sending host, while DKIM survives forwarding since the signature travels with the message. Together they cover each other's gaps.
Getting to an enforced DMARC policy means finding every system that sends as you — the CRM, the invoicing platform, the scanner in the corner — and authorising them before you tell the world to reject the rest. We do that migration, and then the inbound side that display-name spoofing walks straight past.