DMARC p=none vs p=quarantine vs p=reject explained

A DMARC record is one line of DNS, but the p= tag inside it is the single most consequential setting in your entire email authentication setup. It decides what happens to every email that fails SPF and DKIM alignment and most domains are stuck on the setting that does the least.

Here's what each value actually does, why agencies leave domains on the weak one for years, and how to move through them without breaking mail flow.

What the p= tag controls

DMARC doesn't authenticate anything by itself. SPF and DKIM do that work. DMARC's job is to tell receiving mail servers what to do when a message fails both and to give the domain owner visibility into who's sending mail as their domain in the first place.

The p= tag is the instruction receiving servers follow. There are three possible values, and they form an escalating ladder.

p=none: monitor only

p=none tells receiving servers to take no enforcement action on failing mail. Messages that fail SPF and DKIM alignment still get delivered exactly as if DMARC weren't there. The only thing this policy does is turn on reporting you start receiving aggregate reports (RUA) showing who's sending mail using your domain, and whether it's passing or failing.

This is the correct starting point for any new DMARC setup. It lets you see the full picture every legitimate sending source (your ESP, your CRM, your helpdesk, your own mail server) plus anything spoofing your domain without risking real mail getting blocked while you're still mapping out what "legitimate" even includes.

The problem is that p=none provides zero protection. A domain sitting at p=none is no harder to spoof than a domain with no DMARC record at all. Anyone can send email claiming to be you, and the receiving server will deliver it anyway.

p=quarantine: send failing mail to spam

p=quarantine tells receiving servers to treat failing mail as suspicious typically routing it to the spam or junk folder rather than rejecting it outright. The mail isn't blocked, but it's also not landing in the primary inbox.

This is the real transition point. Once you're confident the aggregate reports show every legitimate sending source passing consistently, p=quarantine is where you start actually doing something about the mail that fails. It's also lower-risk than jumping straight to reject if something was missed in the audit, the email degrades to spam instead of disappearing entirely, which is recoverable and visible.

Most agencies that get this far stop here, either because reject feels too risky or because nobody circles back to finish the rollout. That's a reasonable place to pause, but it's not the end state.

p=reject: block failing mail outright

p=reject tells receiving servers to refuse failing mail entirely. No inbox, no spam folder the message is rejected at the server level, the same way a hard-bounce would behave.

This is full DMARC enforcement, and it's what's required for the strongest anti-spoofing protection, including compliance with bulk sender requirements from Google and Yahoo. It's also the policy that actually stops phishing emails impersonating the domain from reaching anyone.

The risk at this stage isn't theoretical: if there's a sending source still misaligned that the reports didn't fully surface, p=reject will silently drop that mail with no notification to the sender. That's why this should be the last step, not the first.

The rollout that avoids breaking mail

The safe path through these three stages looks the same for almost every domain:

1. Start at p=none and let aggregate reports run for at least a few weeks. This surfaces every sending source including ones agencies often forget about, like a CRM, a support desk tool, or an old marketing platform still sending on the domain.
2. Fix alignment issues for each legitimate source found in the reports usually by adding it to the SPF record or setting up DKIM signing for that platform.
3. Move to p=quarantine once reports show consistent passing across all known senders. Watch reports for another stretch to confirm nothing was missed.
4. Move to p=reject once quarantine has run clean for a meaningful period with no surprises in the failure reports.

Skipping straight from p=none to p=reject is the most common mistake, and it's the one that actually breaks deliverability a missed sending source goes from "slightly suspicious, still gets read eventually" to "silently gone" overnight.

Why so many domains never leave p=none

Aggregate reports are raw XML. They're not built to be read by a human, and most domain owners who set up DMARC once never look at them again after the initial setup so a domain sits at p=none indefinitely, technically configured, providing essentially no protection.

This is also why p=none age is worth tracking on its own. A domain newly at p=none is mid-rollout, expected. A domain that's been at p=none for two years is a domain where the rollout stalled and nobody's watching to push it forward.

The bottom line

p=none is a monitoring tool, not a security setting. p=quarantine is meaningful but partial. p=reject is the only policy that actually stops spoofed mail from reaching an inbox. Most domains stop somewhere in the middle and stay there by accident rather than by decision which means the gap between "has DMARC" and "DMARC is actually doing something" is wider than the DNS record alone suggests.

This is exactly the kind of drift Infraova's DMARC checker watches for automatically flagging a domain that's been sitting at p=none for months, tracking when reports go quiet, and surfacing the next safe step instead of leaving someone to read raw XML reports by hand.