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

Change your DMARC policy from p=none to quarantine when your aligned failure rate drops below 1%. Change from quarantine to reject when it drops below 0.1%. Everything else is commentary.

Those two thresholds are the practical answer to the question most admins never get a straight answer to. The rest of this guide explains where those numbers come from, how to read your aggregate reports to get them, and what to do when your senders are not cooperating.

The three policy levels, briefly

p=none: accept all mail, no enforcement. This is your starting point.
p=quarantine: accept mail that fails DMARC but route it to spam or junk.
p=reject: refuse delivery of mail that fails DMARC alignment entirely.

p=reject is the target. It is the only policy level that actually stops spoofing. But you cannot skip to it without data.

Why most domains stay at p=none

The main reason is fear. Admins look at their first aggregate report and see hundreds or thousands of failures. They assume something is broken. In practice, most failures are caused by a small number of recurring problems:

• Third-party senders that are not aligned (marketing platforms, CRM systems, legacy relays)
• Email forwarding that breaks SPF (the forwarded message appears to come from the forwarder's server, not yours)
• Mixed parent-domain and subdomain sending (sending from both example.com and mail.example.com)
• Internal mail systems that rewrite the From header

None of these mean your DMARC configuration is wrong. They mean you have third-party senders to sort out.

The migration sequence

The standard path is p=none to p=quarantine to p=reject. Most domains should spend at least 30 to 60 days at p=none before moving to quarantine, and another 30 to 60 days at quarantine before moving to reject. Some domains with complex sending histories may need longer.

The time at each stage is not arbitrary. It gives you enough aggregate report data to know whether your failure rate is stable and low enough to tolerate at the next level.

How to read your DMARC aggregate report

Your RUA (Reporting URI Aggregate) receives XML reports from participating receivers. You want two numbers from each report:

• Source volume: how many messages that receiver saw from your domain
• Aligned failure count: how many of those failed DMARC alignment (both SPF and DKIM failed the From alignment check)

Failure rate = aligned failures / source volume.

A failure rate above 5% at p=none is a sign that something is misconfigured or that you have a large unaligned sender you have not accounted for.

This is where most teams get stuck. Parsing XML aggregate reports is tedious, inconsistent across reporters, and easy to do wrong. DMARCFlow automates the parsing and gives you the failure rate trend, top failing sources, and aligned-vs-unaligned breakdown in a dashboard. You still interpret the data; you just do not have to fight with XML to get it.

What failure rate to tolerate before advancing

The practical thresholds most practitioners use:

At p=none, tolerate up to 5% failure rate from sources that are legitimate but not yet aligned. Fix the high-volume ones first.

Before moving to p=quarantine: get failure rate below 1%. This means 99% of your legitimate mail is passing DMARC alignment. If a receiver applies your quarantine policy to the remaining 1%, that is an acceptable tradeoff.

Before moving to p=reject: get failure rate below 0.1%. At p=reject, even 0.1% of mail being refused is a problem if that mail is important. If your sending patterns are clean and your third-party senders are all aligned, 0.1% is achievable.

These are guidelines, not standards. Your thresholds may be different if your mail volumes are very low (a 0.1% rate on 100 messages per day is still one refused message every 10 days, which matters) or very high.

How to handle third-party senders

Before advancing to quarantine, audit every source that appears in your aggregate reports. For each source:

1. Identify it. Most reports include the sending IP and rough geographic data. Cross-reference against your known senders.
2. Classify it. Is it a legitimate sender (marketing platform, CRM, internal relay) or a mystery?
3. Fix it or isolate it. If it is a legitimate sender, get it aligned: either configure it to send using your domain with proper DKIM signing, or add its IP range to your SPF record.
4. If it cannot be aligned, consider moving it to a subdomain with its own DMARC record so it does not block your main domain policy.

If you move to quarantine before unaligned senders are handled, the quarantine policy will affect those senders' mail. Some will end up in spam. That may be acceptable for low-priority mail; it is not acceptable for transactional or security-critical mail.

A real example

A SaaS company with 10,000 daily outgoing messages noticed their aggregate report showed 800 aligned failures per day (8% failure rate). The source: their CRM system, which sent from a shared IP range and used its own DKIM key, not theirs.

They added the CRM's sending domain as an authorized sender in their SPF record. Within 48 hours, their failure rate dropped to under 0.5%. After 30 days of stable sub-1% failures, they moved to p=quarantine. After another 45 days of data confirming the rate held, they moved to p=reject.

That is the right sequence. Data first, policy second.

Decision checklist before moving to quarantine

Run through this before advancing:

• [ ] I have reviewed at least 30 days of aggregate reports
• [ ] My failure rate is below 1% for the sources I consider legitimate
• [ ] I have identified every source contributing more than 0.1% of my failure volume
• [ ] All high-volume legitimate senders are either aligned or explicitly excluded
• [ ] I have tested quarantine behavior on a subdomain or a small percentage of traffic if possible
• [ ] My team knows what to do if a legitimate sender suddenly starts failing

Decision checklist before moving to reject

• [ ] I have stayed at p=quarantine for at least 30 days with a stable failure rate
• [ ] My aligned failure rate is below 0.1%
• [ ] All my transactional and security-critical mail sources are aligned
• [ ] I have a process to monitor aggregate reports weekly, not just monthly
• [ ] I have a rollback plan if something goes wrong (changing p=reject to p=quarantine is fast; changing it to p=none is faster)

What to do if something breaks after moving to reject

If legitimate mail starts bouncing after you move to p=reject:

1. Check your aggregate report immediately. Find the IPs or domains that are now failing.
2. Roll back to p=quarantine if the failure volume is significant. p=quarantine will not bounce mail; it will just mark it.
3. Identify the sender, get it aligned, and add it to your allowed list.
4. Move back to p=reject once the issue is resolved.

This is not embarrassing. It is the right response. Even large organizations with well-managed sending infrastructure have had to roll back temporarily. The aggregate report data you collected during the p=none and p=quarantine phases is what makes rollback fast.