When and why should I switch from DMARC p=none to p=quarantine or p=reject?
Updated on 14 Aug 2026: We clarified when to enforce DMARC and added current RFC 9989 guidance for testing and subdomain policy.
Switch from DMARC p=none to p=quarantine or p=reject when DMARC reports show that every authorized sending source is known, normal mail passes DMARC through aligned SPF or DKIM, and the remaining failures are abuse or accepted edge cases. The reason to switch is simple: p=none asks for no DMARC enforcement. It does not ask receivers to quarantine or reject mail that fails.
Use p=none to discover and fix sending sources. Use p=quarantine when the organization is ready to treat failures as suspicious but still wants a softer handling request. Use p=reject when the domain is clean enough that requesting refusal of unauthorized use has less business risk than leaving the domain in monitoring mode.
Suped fits this workflow because Suped's product turns aggregate reports into source-level decisions, flags broken authentication, and provides steps for fixing each issue before policy enforcement. The hard part is not editing one TXT record. It is knowing whether the edit will affect legitimate mail.
The direct decision rule
Move a domain out of p=none only after the reports answer four questions. If any answer is missing, keep the domain in monitoring and make that gap the next fix.
- Identify every sender using the domain, including marketing platforms, billing systems, CRMs, support desks, website mail, and internal infrastructure.
- Confirm that each authorized sender passes DMARC through SPF or DKIM with the domain relationship required for the visible From address.
- Explain every recurring failure, including spoofing, forwarding, mailing lists, filtering appliances, and sources that must be retired.
- Get business owners to accept the remaining indirect-mail risk in exchange for stronger protection of the domain.
Enforcement is a handling request to receivers, not a reward for publishing a DMARC record. If a legitimate system still fails DMARC, p=quarantine can push its mail to spam, and p=reject can cause refusal. Final handling remains subject to the receiver's local policy.
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 reports across normal billing, campaign, and support cycles before changing policy.
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 provides reporting without requesting DMARC enforcement. It is the safest starting point for DMARC monitoring, but receivers remain free to deliver mail that fails DMARC or act on it under their own filters. Treat p=none as a discovery phase, not the final configuration for an active domain.
|
|
|
|
|---|---|---|---|
p=none | No DMARC action requested | Discovery | No requested enforcement |
p=quarantine | Treat failures as suspicious | Staged control | Legitimate mail can reach spam |
p=reject | Refuse unauthorized use | Full enforcement | Legitimate failures can be refused |
DMARC policy behavior at a glance
The security reason is domain abuse. A domain left at p=none has not asked receivers to enforce DMARC against unauthorized use of its visible From domain. That does not mean every monitored domain is being abused, and receivers can still filter spoofed mail independently. It means the domain owner has not published an enforcing DMARC preference.
A stricter DMARC policy does not improve the inbox placement of authenticated campaigns by itself. Its direct purpose is to reduce unauthorized use of the visible From domain at receivers that apply the published preference.
Staying at p=none
- Avoid breaking mail while discovering senders and interpreting report data.
- Give receivers no DMARC instruction to quarantine or reject failures.
- Use it for early setup, audits, migrations, or domains with unknown senders.
Moving to enforcement
- Reduce successful impersonation of the visible From domain where receivers honor the policy.
- Accept that legitimate mail can be affected if it still fails DMARC.
- Use it for domains with stable sending sources and corrected authentication.
How to know you are ready
The cleanest readiness signal is repeated, source-level evidence. Normal sending volume should contain no surprise vendors, and each important mail stream should have a stable DMARC pass pattern. The team should also understand which recipients or routes still fail because of forwarding, mailing lists, or intermediary filtering.
DMARC enforcement readiness
These volume bands are investigation signals, not approval gates. Every business-critical failure still needs review.
Low unexplained volume
98-100%
Review the remaining failures by source and business impact.
Material review needed
90-97%
Assign owners and correct legitimate sources before enforcement.
Hold
<90%
Too much legitimate or unexplained mail still fails DMARC.
No percentage proves readiness. A 99.5% pass rate looks strong until the failing 0.5% contains password reset mail, invoices, legal notifications, or executive mail sent through a regional system. Read failures by source and business importance, not only by total count.
Check the published record before any policy change. Suped's DMARC checker confirms 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
Check domain scope as well. The organizational-domain policy normally flows to subdomains when no applicable override exists. A common mistake is publishing sp=none for a migration and forgetting to remove that exception after subdomain senders are fixed.
Suped's product combines source discovery, authentication issue review, alerts, and hosted policy staging in one workflow. That supports the practical work behind enforcement: finding an unknown sender, assigning the failure, fixing it, and confirming the result in later aggregate reports.
How to move safely
Use a staged, reversible rollout. A controlled path through p=quarantine usually makes sense before p=reject, especially for domains with a broad sending history. A simple domain can move faster, but it still needs monitoring after publication. Set a rollback owner and record the previous TXT value before each change.
- Run p=none long enough to observe normal business cycles and campaign patterns.
- Correct SPF, DKIM, sender domains, and vendor settings for every legitimate source.
- Publish p=quarantine; t=y to request testing one level below quarantine, then remove t=y when the domain is ready for quarantine handling.
- Review aggregate reports, support tickets, spam placement, bounce logs, and business-critical workflows after each change.
- Publish p=reject; t=y to request quarantine-level handling while testing reject, then remove t=y when the remaining failures are understood and accepted.
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; t=y; 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. The t=y tag requests policy testing one level below the published enforcement policy. For p=quarantine, that means none; for p=reject, it means quarantine. Reports still continue during testing.
For teams that want fewer manual DNS handoffs, Hosted DMARC in Suped lets authorized users manage policy staging through a CNAME-based setup instead of repeatedly editing TXT records. Suped also gives MSPs and agencies a multi-tenant dashboard for applying the process while retaining per-domain context.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
Set policy scope for subdomains
Policy scope must be decided before enforcement. Under RFC 9989, p applies to the author domain. When policy is discovered at the organizational domain, sp can override it for existing subdomains and np can override it for non-existent subdomains. If an applicable override is absent, the p value is inherited.
|
|
|
|---|---|---|
p | The author domain | Choose its monitoring or enforcement policy |
sp | Existing subdomains | Use an override only when subdomain senders need different handling |
np | Non-existent subdomains | Request enforcement against unauthorized names that do not resolve |
Policy scope under RFC 9989
Examples of uniform and split policy scopeDNS
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; v=DMARC1; p=quarantine; sp=none; np=reject; rua=mailto:dmarc-reports@example.com;
The first example inherits p=reject for subdomains when no override applies. The second keeps existing subdomains at none during cleanup while asking receivers to reject failures using non-existent subdomains. Keep an sp=none exception only as long as the migration requires it.
Quarantine or reject
Use p=quarantine when enforcement needs a softer failure mode. The published preference says that failing mail is suspicious. Receivers often route it to spam or apply extra scrutiny, which gives the team a chance to catch missed legitimate sources through user reports, seed testing, and report changes.
Use p=reject when unauthorized use of the domain should be refused and the remaining legitimate failure risk is accepted. This is the target policy for many active domains once authentication is clean. It is also appropriate for parked and non-sending domains after confirming that no legitimate system uses them for mail.
Choose quarantine when
- A large or complex domain is moving out of monitoring.
- Forwarding and mailing lists are common among important recipients.
- The team needs a short observation window before requesting hard refusal.
Choose reject when
- All authorized sources pass DMARC across normal business cycles.
- Stopping unauthorized use outweighs preserving known failing edge cases.
- The domain is parked, unused, or sends only through tightly managed systems.
Receivers retain local discretion. A receiver can accept mail that fails under p=reject or filter mail that passes DMARC. RFC 9989 also warns receivers to consider legitimate indirect mail and mailing-list behavior rather than reject solely because the published policy says reject. Senders should still plan for real rejection because many receivers apply the requested policy without preserving every indirect flow.
A deeper operational walkthrough helps when a domain has many senders. The safe policy transition guide covers a slower rollout path, and the DMARC reject policy explainer covers how receivers can handle failing mail.
What to read in DMARC reports
Reports provide the evidence for a policy change. Read them by source, not only by domain total. For each source, check who sent the mail, which receiver reported it, whether SPF passed, whether DKIM passed, and whether at least one passing mechanism used a domain that DMARC considers aligned with the visible From domain.
- Map each source IP or provider to a business owner, or retire the source.
- Separate one-off noise from recurring business mail by reviewing volume over time.
- Require at least one passing DMARC path, aligned SPF or aligned DKIM, for every authorized sender.
- Investigate 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 difficult part. Forwarding can break SPF. Mailing lists can change content and break DKIM. Filtering appliances can alter the path before final delivery. Reduce breakage by making direct mail technically clean and applying aligned DKIM to normal mail, but plan for routes that cannot preserve both authentication paths.
When a clean starting record is needed, Suped's DMARC record generator creates the TXT value and keeps its tags readable before publication. After that, use aggregate reports to decide whether 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 producing unexplained legitimate senders. Move to p=quarantine when known mail passes and a controlled enforcement stage is appropriate. 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 the risk to legitimate mail. Reduce that risk with evidence for every source and keep monitoring after enforcement. Suped's product supports that loop by identifying sources, detecting issues, guiding authentication fixes, staging policy, and tracking later report changes.
