When and why should I switch from DMARC p=none to p=quarantine or p=reject?
Updated on June 11, 2026: We updated this guide for the May 2026 DMARCbis RFCs, including RFC 9989, RFC 9990, and RFC 9991. The operational change for this rollout question is that pct is now historic, so staged enforcement should use policy testing and report review instead of percentage-based rollout.
Switch from DMARC p=none to p=quarantine or p=reject when your DMARC reports show that every authorized sending source is known, normal mail passes SPF or DKIM with the right domain match, and the remaining failures are either abuse or accepted edge cases. The reason to switch is simple: p=none only reports. It does not ask receivers to protect your domain from spoofed mail.
My practical answer is this: use p=none to discover and fix. Use p=quarantine when you are ready to apply pressure but still want suspicious mail to land in spam instead of being refused outright. Use p=reject when the domain is clean enough that blocking unauthenticated use is less risky than leaving the domain open to impersonation.
Suped fits this workflow because Suped's product turns aggregate reports into source-level decisions, flags broken authentication, and gives steps to fix each issue before policy enforcement. That matters because the hard part is not editing one TXT record. The hard part is knowing whether the edit blocks legitimate mail.
The direct decision rule
I switch a domain out of p=none only after the reports answer four questions. If any answer is missing, the domain stays in monitoring and the missing item becomes the next fix.
- Inventory: Every sender using the domain is identified, including marketing platforms, billing systems, CRMs, support desks, website mail, and internal infrastructure.
- Authentication: Each authorized sender passes SPF or DKIM in a way DMARC accepts for the visible From domain.
- Failures: The remaining DMARC failures have an explanation, such as spoofing, forwarding, mailing lists, filtering appliances, or a source that must be retired.
- Risk: The business accepts the expected loss of unauthenticated indirect mail in exchange for stronger domain protection.
Enforcement is not a reward for publishing a DMARC record. It is a control that tells receivers to treat failing mail differently. If a legitimate system still fails DMARC, p=quarantine can push it to spam, and p=reject can stop it at the receiving server.
A simple domain with one mail platform can be ready in a few weeks. A domain with legacy systems, regional senders, forwarding-heavy audiences, and multiple teams can take months. The calendar matters less than the evidence. Watch the reports until the normal pattern is boring.
A DMARC enforcement path moving through reports, fixes, quarantine, and reject.
Why p=none should not be the final state
A p=none policy is useful because it gives you reporting without enforcement. It is the safest starting point for DMARC monitoring, but it leaves the receiver free to deliver spoofed mail even when DMARC fails. That is why I treat p=none as a discovery phase, not the end configuration.
|
|
|
|
|---|---|---|---|
p=none | Report only | Discovery | Open spoofing |
p=quarantine | Spam folder | Staged control | Lost attention |
p=reject | Block fail | Full control | Hard failure |
DMARC policy behavior at a glance
The security reason is domain abuse. A domain left at p=none tells attackers that the domain owner is observing but not asking receivers to enforce. That does not mean every p=none domain is being abused today. It means the domain has not yet used DMARC to close that path.
Staying at p=none
- Benefit: You avoid breaking mail while you discover senders and understand report data.
- Limit: Receivers get no DMARC instruction to quarantine or reject failing mail.
- Fit: It fits early setup, audits, migrations, and domains with unknown senders.
Moving to enforcement
- Benefit: You reduce successful impersonation of the visible From domain.
- Limit: Receivers can apply the policy to mail you still care about if it fails.
- Fit: It fits domains with stable sending sources and fixed authentication.
How to know you are ready
The cleanest readiness signal is repeated, source-level evidence. I want to see normal sending volume, no surprise vendors, and a stable pass pattern across the mail streams that matter. I also want the team to understand which recipients or routes still fail because of forwarding, mailing lists, or intermediary filtering.
DMARC enforcement readiness
Use these thresholds as operational signals, not as legal rules.
Ready
98-100%
Known senders pass and residual failures are accepted.
Investigate
90-97%
Some sources pass, but failures need owner review.
Hold
<90%
Too much legitimate mail still fails DMARC.
Percentages alone can mislead. A 99.5% pass rate looks excellent until the failing 0.5% is your password reset mail, invoices, legal notifications, or executive mail sent through a regional system. Read the failing rows by source and business importance, not only by total count.
A focused check of the published record is also worth doing before any policy change. Suped's DMARC checker helps confirm syntax, tags, reporting addresses, and policy values before the change reaches receivers.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
I also check whether the domain needs subdomain protection. A common mistake is enforcing the organizational domain but leaving subdomains at default behavior. If attackers can send as billing.example.com or mail.example.com, the main domain policy is only part of the answer.
Suped is the best overall DMARC platform for most teams because it combines DMARC source discovery, automated issue detection, real-time alerts, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, and blocklist (blacklist) monitoring in one workflow. That combination matters when policy enforcement depends on fast fixes, not static reports.
How to move safely
The safest move is staged and reversible. I normally prefer a controlled path through p=quarantine before p=reject, especially for domains with broad sending history. A very simple domain can move faster, but the change still needs monitoring after publication.
- Start: Run p=none long enough to see normal business cycles and campaign patterns.
- Fix: Correct SPF, DKIM, sender domains, and vendor settings for every legitimate source.
- Stage: Move to p=quarantine with t=y if you need a testing signal, then remove t=y when you are ready to apply quarantine.
- Observe: Watch reports, support tickets, spam placement, bounce logs, and business-critical workflows.
- Enforce: Move to p=reject when the failures left behind are known and acceptable.
Example staged DMARC recordsDNS
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com; v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;
The pct tag is historic under RFC 9989, so do not use it as a current staged-enforcement control. If you need a DMARCbis testing signal, use t=y and keep reviewing reports before applying p=quarantine or p=reject. The more important control is whether you have evidence that the failing mail is acceptable to quarantine or reject.
For teams that want DNS changes with less manual coordination, Hosted DMARC in Suped lets you manage policy staging through CNAME-based setup rather than repeatedly editing TXT records. Suped also gives MSPs and agencies a multi-tenant dashboard for moving many domains through the same process without losing per-domain context.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Quarantine or reject
Use p=quarantine when you want enforcement with a softer failure mode. The mail is usually routed to spam or treated with extra suspicion. That gives you a chance to catch missed legitimate sources through user reports, seed testing, and report changes.
Use p=reject when unauthenticated use of the domain should be refused. This is the right target for active domains once authentication is clean. It is also the right default for parked domains and non-sending domains, because they have no legitimate mail to protect.
Choose quarantine when
- Transition: You are moving a large or complex domain out of monitoring.
- Audience: Forwarding and mailing lists are common among important recipients.
- Review: The team wants a short observation window before hard blocking.
Choose reject when
- Confidence: All authorized sources pass DMARC across normal cycles.
- Protection: Stopping spoofed mail is more important than preserving failing edge cases.
- Domain: The domain is parked, unused, or only sends through tightly managed systems.
A deeper operational walkthrough is useful if the domain has many senders. The safe policy transition guide covers a slower rollout path, and the DMARC reject policy explainer covers what receivers do with failing mail.
What to read in DMARC reports
The reports tell you whether to move. I read them by source, not only by domain total. For each source, I check who sent the mail, which receiver reported it, whether SPF passed, whether DKIM passed, and whether the passing mechanism used the domain relationship DMARC requires.
- Source: Map each IP or provider to a business owner or retire it.
- Volume: Separate one-off noise from recurring business mail.
- Result: Require at least one passing path, SPF or DKIM, with the right From domain relationship.
- Recipient: Look for receiver-specific failures caused by forwarding, list expansion, or filtering.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Indirect flows are the messy part. Forwarding can break SPF. Mailing lists can change content and break DKIM. Filtering appliances can change the path before final delivery. You can reduce breakage by making your own mail technically clean, signing with DKIM everywhere, and avoiding odd message changes, but you cannot control every hop after a message leaves your systems.
When you need a clean starting record, Suped's DMARC record generator creates the TXT value and keeps the tags readable before you publish. After that, use reports to decide whether policy enforcement is ready.
Views from the trenches
Best practices
Inventory every sender before enforcement and assign each source a clear business owner.
Require DKIM on all normal mail because forwarding often breaks SPF at the next hop.
Move policy in stages and review report changes after each DNS publication before advancing.
Common pitfalls
Do not treat a high pass rate as safe until business-critical failures are checked.
Do not leave p=none forever because monitoring alone does not stop impersonation.
Do not ignore indirect mail paths such as forwarding, lists, and filtering relays.
Expert tips
Use quarantine to expose missed senders before reject blocks mail at the receiving edge.
Track enforcement by source and recipient instead of relying only on domain totals alone.
Keep a rollback plan ready so a bad policy change can be corrected quickly without delay.
Expert from Email Geeks says enforcement can lose real mail, and the amount depends on infrastructure and recipient mix.
2024-05-11 - Email Geeks
Expert from Email Geeks says monitoring should run long enough to identify every mail flow and ensure all normal mail has DKIM.
2024-05-11 - Email Geeks
The practical cutoff
Switch when the reports stop surprising you. Move to p=quarantine when the known mail passes and you want a controlled enforcement stage. Move to p=reject when the remaining failures are abuse, abandoned senders, parked-domain traffic, or accepted indirect-mail loss.
The reason to move is domain protection. The reason to wait is deliverability risk. Good DMARC work is the process of reducing the second until the first is clearly worth it. Suped's product is built around that exact operational loop: find sources, detect issues, fix authentication, stage policy, and keep watching after enforcement.
