p=none vs p=quarantine vs p=reject: when to move (and when not to)

DMARC has exactly one knob that matters: the policy tag. p=none, p=quarantine or p=reject — monitor, spam-folder, or block. Three words that decide what the world’s mailbox providers do with email that claims to be you and can’t prove it.

Here’s the uncomfortable industry statistic: of the roughly half of major domains that publish DMARC at all, more than half are parked at p=none — the setting that observes spoofing and does nothing about it. Only around one domain in ten reaches full p=reject. Everyone starts the ladder; most never climb it.

What each policy actually does

• p=none — “tell me what’s happening, take no action.” Failing mail is delivered normally. You get aggregate reports (if you asked for them — more below). Zero protection, full visibility.
• p=quarantine — “if it fails, put it in spam.” Real damage to spoofers, recoverable damage to you if you misconfigure something.
• p=reject — “if it fails, refuse it at the door.” The destination. Spoofed mail using your exact domain stops being deliverable, full stop.

One nuance worth knowing: since Microsoft’s 2025 sender rules, bulk senders need at least p=none just to get into Outlook inboxes — and Google and Yahoo require the same. So p=none is no longer optional; the question is only how fast you climb from it.

Why p=none first is non-negotiable

Because the thing DMARC blocks is unaligned mail — and on day one, some of your own legitimate mail is unaligned. The CRM that sends as you. The billing tool. The newsletter platform someone connected in 2023. Jump straight to p=reject and you don’t stop attackers first, you stop yourself.

So you start at none with reporting on:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

The rua tag is the whole point of this phase. Without it, p=none is a policy that observes nothing for nobody. Build the record properly — every tag explained, policy ladder included — with our free DMARC Record Generator.

The honest climbing checklist

Move up a rung when, and only when:

1. You can name every source in your reports. Open a few weeks of aggregate reports (our DMARC Report Viewer turns the raw XML into a readable table) and identify every IP sending as your domain. Each one is either a tool you use, or a problem.
2. Your legitimate sources pass at ~98% or better. The common benchmark before tightening. The stragglers are usually a provider missing custom-domain DKIM or an SPF include you never added.
3. You’ve watched long enough to catch rare senders. Quarterly invoicing tools only appear in reports quarterly. Most guidance says sit on each rung for 60–90 days; the full none→reject journey commonly takes 9–18 months in larger orgs. A small, clean domain can move much faster.

Use pct= to descend gently into each policy — p=quarantine; pct=25 applies the policy to a quarter of failing mail, so a mistake stings instead of burning.

A worked climb, week by week

Here’s what a realistic ramp looks like for a small, reasonably clean domain — larger orgs with more sending tools stretch every stage out further:

Weeks	Policy	What’s actually happening
1–3	p=none; pct=100	Reports arriving, every legitimate source getting identified and fixed.
4–5	p=quarantine; pct=10	A small slice of failing mail spam-foldered; watching for any legitimate sender caught in it.
6–8	p=quarantine; pct=50 → pct=100	Ramping up as reports confirm no legitimate source is failing.
9–12	p=reject; pct=10 → pct=100	Final step — failing mail refused outright, same gradual ramp for safety.

Twelve weeks is optimistic but realistic for a domain with a handful of sending tools and someone actually reading the weekly reports. Add a month or two for every additional sending tool discovered mid-climb, and expect the timeline to stretch well past a year for a large org with dozens of business units each running their own marketing and billing tools independently.

The mistake that resets the clock

The single most common way a climb goes wrong isn’t moving too fast — it’s moving on stale information. A source that was silent for six weeks because it only sends quarterly invoices looks, from three weeks of reports, exactly like a source that stopped existing. Tighten the policy on that assumption, and the invoicing tool’s very next send gets quarantined or rejected, customers stop getting invoices, and someone spends a week debugging “email is broken” before tracing it back to a DMARC change made a month earlier. The fix is boring but effective: don’t just watch report volume, actively note which known sources have gone quiet, and treat any gap in your source inventory as unresolved rather than assuming silence means the source is gone.

When not to move

• You see legitimate sources in reports you haven’t fixed yet.
• You can’t tell which sources are legitimate (that’s a reason to look harder, not to wait forever).
• You don’t read the reports at all — then tightening is gambling, and the house is your own invoice email.

The part nobody tells you: this never ends

Reaching p=reject isn’t graduation. Next quarter someone connects a new tool, its mail silently fails, and you find out from a customer asking why invoices stopped arriving. The reports keep coming precisely because the monitoring problem is permanent.

Reading gzipped XML by hand forever is nobody’s plan — that’s the job Norbelys DMARC monitoring does continuously: every report parsed, every new source surfaced, drift flagged before it costs you deliveries. Start the climb with the free tools; bring the monitoring when the domain starts paying your bills.

Quick answers

Can I skip straight to p=reject on a brand-new domain with no other senders? Yes, and it’s actually the easiest case — a domain that only ever sends through one tool has nothing to break by rejecting everything else, so there’s little reason to sit at p=none for months. The slow climb exists for domains with an unknown or messy sender history, not as a universal rule.

Does p=quarantine guarantee failing mail lands in spam, not the inbox? No — it’s a strong signal to the receiving mailbox provider, not a hard rule they’re obligated to follow. Most major providers honor it closely, but DMARC policy is ultimately advisory; the receiver’s own spam filtering has the final say on where a message lands.

What happens to reports once a domain reaches p=reject? They keep arriving, and they’re still worth reading. A p=reject policy stops current spoofing attempts; it doesn’t stop someone standing up a new tool next quarter that fails alignment for entirely legitimate reasons. The reports are how that gets caught before it becomes a “why did our invoices stop arriving” support ticket.