DMARC p=none Explained: What It Means and How Long to Stay There

What DMARC p=none actually does

A DMARC record is a TXT record at _dmarc.yourdomain.com. The p= tag is the policy you are asking receiving servers to apply when a message claims to be from your domain but fails DMARC. With p=none, the answer is: apply nothing. Deliver the message as you normally would, based on your other spam signals, and, this is the important part, send the domain owner an aggregate report about what happened.

For a message to pass DMARC it needs at least one of SPF or DKIM to both authenticate and align. Alignment means the domain that passed SPF or signed with DKIM matches the domain in the visible From header. A message can pass SPF for its bounce address and still fail DMARC if that address is a different organizational domain, alignment is what DMARC adds on top of the older checks.

So p=none changes nothing about delivery. A spoofed email that fails DMARC under p=none still lands wherever the receiver decides. The value is entirely in the reports you begin collecting the moment the record goes live.

Why you start at p=none

Almost no organization has a complete, accurate list of everything that sends email in its name. Marketing automation, invoicing systems, help desks, payroll, the CRM, a booking widget, that one vendor set up three years ago, each is a potential sender, and each needs SPF or DKIM configured and aligned before enforcement is safe.

If you jump straight to p=reject before that inventory is complete, you don't spoof-proof your domain, you delete your own legitimate mail. A payroll notification or a customer receipt that was never set up for DKIM will simply vanish. p=none is the policy that lets you discover the full list without breaking anything, because the reports name every source sending as you, aligned or not.

• Publish a record with rua= pointing at a mailbox or a report processor: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
• Leave delivery untouched while reports accumulate, you are gathering evidence, not enforcing yet
• Use the data to bring every legitimate sender into SPF and DKIM alignment

Reading the reports p=none gives you

Aggregate reports (the rua stream) arrive as gzipped XML, usually once a day from each major provider. Each report groups messages by sending IP and tells you the volume, the SPF result, the DKIM result, and whether each aligned with your From domain. Raw XML is unpleasant to read by hand, so most teams pipe it into a parser or a dashboard.

What you are hunting for is a clean picture: every IP that sends legitimate mail should show SPF or DKIM passing and aligned. Anything passing but unaligned is a sender you still need to fix. Anything you don't recognize sending real volume is worth investigating, it may be a forgotten service, or it may be abuse. You can sanity-check your published record at any point with the DMARC checker to confirm the syntax and policy the world actually sees.

The forensic (ruf) stream, which sends per-message failure samples, is barely supported today for privacy reasons, don't build your rollout around it. Aggregate reports carry the information you need.

How long should you stay at p=none?

There is no fixed number, but there is a clear finish line: you leave p=none when every legitimate sender in your reports authenticates and aligns, and you have watched enough days to trust that the picture is stable. For a simple domain with one or two senders, that can be two to three weeks. For an enterprise with a long tail of vendors, monthly-billing systems, and quarterly campaigns, six to eight weeks is realistic, you want to capture senders that only fire occasionally.

The failure mode is treating p=none as a destination. A record parked at p=none for a year is publishing a public statement that you are watching but will do nothing, and spoofers reading your policy know it. If your reports have been clean for several weeks and you still haven't moved, that is the signal to advance, not more waiting.

Moving from p=none to quarantine and reject

Enforcement is a ramp, not a switch. Move to p=quarantine first, and use the pct tag to phase it in: p=quarantine; pct=25 applies the policy to a quarter of failing mail, letting you catch any surprise before it affects everyone. Raise the percentage as the reports stay clean, then go to pct=100, then finally to p=reject, which tells receivers to refuse failing mail outright.

Keep the rua reports flowing the whole way through, they are how you confirm each step is safe before taking the next. The step-by-step reject rollout walks through the percentages and timing in detail, and if a sender is still failing, the SPF, DKIM and DMARC fix guide covers the record changes that bring it into alignment.

The whole point of p=none is that it ends. It is the phase where you learn; quarantine and reject are where that learning finally protects your domain.