When to Move from DMARC p=none to Quarantine or Reject

Most domains set up DMARC with p=none. Very few of those domains ever actually read the reports that p=none generates. So when someone asks "should we change our DMARC policy?", the real answer is usually "your reports will tell you, and you have not looked at them yet."

This guide gives you the checklist for reading those reports correctly and making the upgrade decision with data instead of guesswork.

Why Your DMARC Policy Starts at p=none

When you first add a DMARC record, p=none is the standard starting point. It tells receiving mail servers to take no action on messages that fail DMARC, while still sending you aggregate reports about what is happening.

In other words: p=none is monitoring mode. It is not a security setting. It is a visibility tool.

That visibility is the whole point. Before you can responsibly tighten your policy, you need to know who is sending email on your behalf, which sources are legitimate, and what your baseline failure rate looks like. The aggregate reports you receive at p=none are what make the upgrade decision possible at all.

If you have never looked at a DMARC aggregate report, you are not ready to change your policy. That is not a criticism - it is the most common reason the upgrade goes wrong.

What Each DMARC Policy Level Actually Does

DMARC has three policy options:

p=none - Receiving servers take no action on failing messages. You get reports, nothing else changes.

p=quarantine - Failing messages are marked as suspicious and sent to spam or junk. The receiving server handles this, not yours.

p=reject - Failing messages are not delivered at all. The receiving server blocks them outright.

One point that trips people up: these policies are enforced by the receiving mail server, not by your DNS. Publishing p=reject does not block mail from your own server - it instructs other servers to reject mail that fails your authentication checks.

The Key Question Before You Upgrade

Are your authentication records stable?

"Stable" means:

The same legitimate sending sources appear in your reports, day after day

Your failure rate is low and has been low for at least 30 to 60 days

You have not seen unexpected spikes when you rolled out new tools or services

If your reports still show new sources appearing regularly, or your failure rate fluctuates, you do not have a stable baseline. Upgrading now means you will probably break something.

The baseline is what tells you whether the upgrade is safe. Without a stable baseline, you are guessing - and guessing wrong means legitimate email does not get delivered.

How to Read Your Reports to Make This Decision

Your DMARC aggregate reports arrive at the address specified by your rua tag. They contain counts of messages sent from your domain, broken down by the result of DMARC checks and the source IP.

The numbers you care about most:

Fail count: how many messages failed DMARC, and from which source IPs
Source IPs: which servers sent the mail - you want to recognize every one of them
Disposition breakdown: how many were none, quarantine, or reject - this only matters once your policy is stricter than p=none

A report with 1000 messages sent and 0 failures from known sources means your authentication is solid. A report with 1000 messages sent and 200 failures from unknown IPs means you have work to do before touching your policy.

DMARCFlow parses these reports and surfaces the failure rate, source IP breakdown, and trend over time in a dashboard. That makes it easier to spot the 30-to-60-day stability window rather than scrolling through raw XML. The stability window is the key input to the upgrade decision - everything else in this guide depends on you having that data first.

DMARCFlow is purpose-built for exactly this: turning aggregate report data into the kind of visibility that lets you make the p=none to quarantine transition with confidence instead of hope.

Signs You Are Ready to Tighten Your Policy

You have a stable baseline when:

Your primary sending sources show zero DMARC failures for 30 or more consecutive days
You have documented every legitimate email source for your domain
Third-party services that send on your behalf are all properly authenticated with SPF or DKIM
Forwarded email volume is low, or you have ARC configured to handle it

If all four of those are true, your reports are telling you something useful: your authentication is working consistently, and failures in your aggregate data are likely to be real problems worth investigating rather than normal noise.

The Safe Progression Path

Most guides tell you to move to p=reject. This guide tells you to move gradually and watch your reports at every step.

Step 1: Confirm stability at p=none
Stay at p=none until your aggregate reports show a consistent, low failure rate over at least 30 to 60 days. Do not rush this phase.

Step 2: Move to p=quarantine with pct=10
The pct tag controls what percentage of messages the policy applies to. Setting pct=10 means only 1 in 10 failing messages is quarantined during the transition - the other 9 still pass through normally.

Your DNS record looks like this:


v=DMARC1; p=quarantine; pct=10; rua=mailto:your-reports@example.com;

Step 3: Monitor for 2 to 4 weeks
Watch your aggregate reports closely. Any new failure sources at this stage need to be identified and resolved before you go further.

Step 4: Raise pct gradually
If reports stay clean at pct=10, move to pct=25, then pct=50, then pct=75. Give each step 1 to 2 weeks.

Step 5: Move to p=reject when pct=100 is clean
Only when your reports show zero failures at full percentage deployment should you switch to p=reject.

Step 6: Keep rua reporting active forever
Your aggregate reports are what make the whole system work. Never remove the rua tag, even after you reach p=reject.

Red Flags That Mean Wait

These are signs you are not ready to upgrade, regardless of how long you have been at p=none:

Unknown sending sources keep appearing in your reports - you do not know who they are or whether they are legitimate
Failure spikes after you changed internal tools, updated your email infrastructure, or onboarded a new vendor
Third-party services are not yet set up with SPF or DKIM
Users report email delivery problems you cannot explain
Your forwarded email volume is high and you have not configured ARC

Any of those means your baseline is not stable. Rushing the policy upgrade will cause legitimate email to be quarantined or rejected.

Common Mistakes When Moving to Stricter Policies

Moving too fast. Jumping from p=none directly to p=reject because it sounds like the right thing to do is the number one mistake. The quarantine transition phase exists for a reason.

Ignoring failures at p=none. If your reports show 15% failure rate at p=none, that 15% will be rejected once you tighten the policy. Fix the failures first.

Forgetting to set pct during transition. Without pct, your policy applies to 100% of messages immediately. If something goes wrong, you have no safety valve.

Removing rua when you reach p=reject. Your reports are still useful after reject - they tell you whether your legitimate mail is passing and whether anyone is still trying to spoof your domain.

Not documenting sending sources. Every time you add a new tool, vendor, or internal system that sends email, update your authentication records before you change your DMARC policy.

FAQ

How long should I stay at p=none?
At least 30 to 60 days of stable, low-failure reports. Some organizations with complex email setups stay at p=none for 6 months or longer. There is no fixed deadline - the reports tell you when you are ready.

Can I go straight to p=reject?
You can, but it is risky. If any legitimate email fails authentication, it will not be delivered with no recourse. The p=none to p=quarantine to p=reject path exists because rushing this kills legitimate email delivery.

What is the pct tag and do I need it?
pct controls the percentage of messages the policy applies to. When first moving from p=none, use pct=10 or pct=20 as a safety switch. It is not required, but it is good practice.

Who applies the policy - me or the receiver?
The receiving mail server applies your DMARC policy. Your job is to publish the policy and monitor the reports.

Does p=reject mean rejected for everyone?
No. Only receivers that honour DMARC will reject your mail. Some receivers ignore DMARC entirely or apply their own heuristics. p=reject maximizes protection from compliant receivers but is not a universal off switch.

Summary Checklist

Before you change your DMARC policy:

[ ] You have reviewed at least 30 days of aggregate reports
[ ] Your failure rate from known sources is consistently near zero
[ ] Every legitimate sending source is documented and authenticated
[ ] Third-party senders use SPF or DKIM with your domain
[ ] You plan to use pct during the quarantine transition
[ ] Your rua reports are going to an address you actually check

If you can tick all six boxes, your reports are telling you something specific: your authentication is stable, and tightening your policy is now a reasonable next step. If you cannot, the right answer is to stay at p=none and keep working through your failure sources.

The goal is not the strictest policy - it is the strictest policy that does not break legitimate email.