Should You Change DMARC from p=none to Quarantine or Reject?

The Short Answer: Not Yet, and Here is Why

If your DMARC policy is set to p=none and you are wondering whether to move it to p=quarantine or p=reject, the answer is: not yet. Not until you have read your DMARC aggregate reports and confirmed that every legitimate sending source in your domain is passing authentication.

The most common mistake administrators make is treating DMARC policy as a dial for email quality. Turning it up does not make your email more likely to land in the inbox. It makes receivers more aggressive about email that fails authentication. Those are different problems, and solving one does not automatically solve the other.

This article explains the correct sequence: from p=none monitoring, through alignment checks, to safe enforcement.

Why DMARC Policy and Inbox Placement Are Separate Problems

When your legitimate email lands in spam, the instinct is to tighten everything. But inbox placement is driven by sending reputation, engagement rates, and content signals. DMARC policy controls what receivers do with email that fails authentication - it says nothing about the quality of your authenticated mail.

If your email is authenticating correctly (SPF aligned, DKIM signing) and still landing in spam, DMARC enforcement will not fix it. Changing your policy from p=none to p=reject only affects mail that fails DMARC. Mail that passes DMARC is handled the same way regardless of your policy setting.

This distinction matters. The poster in a typical r/DMARC thread has two separate problems: (1) email deliverability issues and (2) an unprotected domain that could be spoofed. Moving to enforcement addresses problem two, not problem one.

What DMARC Policy Actually Controls

Here is what each policy level does:

p=none: Monitoring only. Receivers send you aggregate reports about what they see, but take no action on any mail, passing or failing.

p=quarantine: Receivers treat mail that fails DMARC as suspicious. In most cases this means routing it to the spam or junk folder. Failing mail is delivered, just not to the inbox.

p=reject: Receivers block mail that fails DMARC entirely. The message is rejected at the SMTP level and never reaches the recipient's mailbox.

p=none does nothing to protect your domain. p=quarantine and p=reject are enforcement modes. The transition between them is not a switch you flip - it is a sequence you work through.

The Correct Sequence: From p=none to Enforcement

The standard progression looks like this:

Step 1: Read your aggregate reports first. Before you change anything, you need to know every source that sends email on behalf of your domain, and whether each one passes SPF, DKIM, both, or neither. Your aggregate reports show you exactly what receivers see.

Step 2: Fix alignment issues before you enforce. SPF or DKIM passing is not enough. For DMARC to pass, the authenticated domain (the MAILFROM domain for SPF, or the DKIM signing domain) must align with the From header domain. A sending service that passes SPF but uses its own domain in the MAILFROM will fail DMARC alignment.

Step 3: Test on a subdomain before the root domain. Pick a non-production subdomain, publish a p=quarantine record for it, and watch what happens over a week. If nothing breaks, that subdomain is ready for p=reject. Only then do you move to the root domain.

Step 4: Move to p=quarantine on the root domain, then to p=reject. Even on the root domain, quarantine first. Give it two weeks of data before going to reject.

Skipping steps is how legitimate email breaks. The most common breakages come from internal systems, legacy vendor integrations, and marketing automation tools that use the wrong sending domain.

What to Look for in Your DMARC Reports Before Each Step

Before you move to quarantine, your aggregate reports should show:

All of your known sending sources passing SPF alignment or DKIM alignment (or both)
No unexpected sources appearing in the reports
A consistent picture over at least two weeks of data

Before you move to reject, you need all of the above plus:

No softfail entries (mail that partially failed but was still accepted under p=quarantine)
All third-party senders using their own aligned domains or properly configured custom-domain sending
Confidence that you have mapped every legitimate sending path

This is the step where most administrators stall. Aggregate reports arrive as raw XML from each receiving mail server - Google, Microsoft, Fastmail, and others all format their reports differently. Before you can answer the basic question "what is actually sending through my domain?", you have to parse and normalize weeks worth of data. DMARCFlow handles this normalization automatically, giving you a unified view of passing and failing sources across all receivers. That unified view is what tells you when you are genuinely ready to move to quarantine, and later to reject.

Without that visibility, administrators either move to enforcement prematurely and break legitimate sending paths, or they stay at p=none indefinitely because they cannot confidently answer the readiness question. DMARCFlow is not a bonus step in this workflow - it is the reason the workflow becomes tractable.

Common Traps That Delay Enforcement

The unknown source trap. Your reports show a sending source you do not recognize. Before enforcing, you need to identify whether it is a legitimate internal system you forgot about (a printer, an application server) or something else. Going to reject while an unknown source is still failing will break that path silently.

The third-party vendor trap. Your marketing platform, billing system, or support desk sends email on behalf of your domain. If they have not set up DKIM signing with your domain, their mail will fail DMARC alignment once you enforce. Find this before you enforce, not after.

The forwarding trap. If you forward mail automatically (for example, from a legacy address to a new one), the forwarding service may rewrite the From header. The forwarded message authenticates correctly at the first hop but fails DMARC at the forwardee's receiver. This is a known edge case, but it can surprise you if you have not looked for it.

The subdomain gap. Your root domain is clean. But a subdomain used for a specific service is not aligned. Some receivers evaluate subdomains independently. If that subdomain sends unauthenticated mail, it can still be spoofed.

When You Know You are Ready

You are ready for p=quarantine when:

You can name every source in your DMARC reports

All known sources are passing alignment

You have two weeks of clean data with no unexpected entries

You are ready for p=reject when:

p=quarantine has been in place for at least two weeks with no legitimate mail affected

All your known sources are passing at quarantine level

You have investigated and resolved every source that appeared unexpectedly

If you are unsure whether a source is legitimate, that source is not ready for enforcement. Keep it at p=none until you know.

How DMARCFlow Fits Into This Workflow

DMARCFlow is designed for exactly the readiness question: are you actually ready to enforce, or are you guessing? The aggregate report parsing that DMARCFlow provides is not a nice-to-have - it is the foundation of the decision. Without a clear picture of which sources are passing and which are failing, moving to p=quarantine or p=reject is an informed guess at best.

Once you are enforcing, DMARCFlow continues to surface problems quickly. If a new sending path appears and starts failing, you want to know before it becomes a user complaint. DMARCFlow monitors your reports continuously so regressions do not go unnoticed.

FAQ

Will p=reject block my legitimate email?
Only email that fails authentication. If your legitimate email passes SPF or DKIM alignment, it will be delivered normally. The risk is email from legitimate sources that you did not know about and that are not correctly configured.

How long should I stay at p=none?
At minimum two weeks, and until you have identified every source in your reports. Some domains need months of monitoring before enforcement is safe.

What if I have dozens of sending sources?
Start with the highest-volume ones. You do not need every source perfect before you enforce - you need every source that represents significant volume or business risk to be clean. But unknown sources at any volume are a problem.

Can I enforce on just one subdomain first?
Yes. Subdomain enforcement is the safest test path. If something breaks, it breaks on a subdomain you can isolate. Many organizations enforce subdomains for years before touching the root domain.

What happens if I go to p=reject and something breaks?
You change the record back to p=none immediately and investigate the reports. This is why quarantine first, on a subdomain, is the recommended sequence. You want to find out what breaks before the root domain is at stake.