When and why should I switch from DMARC p=none to p=quarantine or p=reject?
Updated on 22 Oct 2026: We clarified DMARC rollout checks, test-mode limits, and how to recover when legitimate mail fails.
Switch from DMARC p=none to p=quarantine or p=reject when your sender inventory and DMARC reports account for every authorized sending source, 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's DMARC reporting platform groups aggregate reports by sending source, flags authentication failures, and provides steps for fixing each issue before enforcement. The hard part is knowing whether a policy change will affect legitimate mail.
When to leave p=none
Move a domain out of p=none only after the reports and sender inventory support these four checks. If a check is incomplete, 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. 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. Include monthly billing and seasonal campaigns in the observation window, and ask business owners about systems that have not sent mail during monitoring.
DMARC rollout steps: monitor reports, identify senders, fix failures, then consider quarantine and reject.
Why move beyond p=none
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. Use p=none reports to assess whether enforcement is safe for the domain's actual mail flows.
|
|
|
|
|---|---|---|---|
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 mail that fails DMARC | 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. It does not stop messages using lookalike domains or display-name impersonation, or misuse of an authenticated account.
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
Use evidence about legitimate mail streams to decide whether to advance. There is no universal DMARC pass-rate threshold.
Ready to stage
Sources verified
Authorized senders pass consistently; remaining failures have documented explanations and accepted risks.
Investigate first
Evidence incomplete
Unknown sources or incomplete sending cycles still need review.
Hold enforcement
Critical mail fails
An unresolved failure affects legitimate business-critical mail.
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. Calculate pass rates for legitimate sources separately from spoofing traffic, then review failures by source and business importance. A spoofing spike can lower the domain-wide pass rate without changing the readiness of legitimate senders.
Check the published record before and after each policy change. Suped's DMARC checker looks up live DNS to check syntax, duplicate DMARC records, policy values, and reporting destinations. It does not prove that every legitimate sender is ready for enforcement.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
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. Configure aligned DKIM before p=reject rather than relying on SPF alone.
- Publish p=quarantine when legitimate senders are ready for quarantine handling. Treat t=y as optional testing for receivers that support it, not a guarantee of reduced enforcement.
- Review aggregate reports, support tickets, spam placement, bounce logs, and business-critical workflows after each change.
- Publish p=reject once remaining failures are understood and accepted. If you use t=y, assume some receivers will still apply reject handling; remove it when testing is complete.
Receivers that do not recognize t=y ignore the tag and can apply the full p policy. Do not publish p=reject; t=y until the domain can tolerate rejection. This follows the unknown-tag behavior in RFC 7489.
Replace the existing DMARC TXT value at _dmarc.example.com for the domain example.com. Publish only one DMARC policy record at that name, keep the real rua reporting destination, and use your DNS provider's required host-name format. The records below are successive examples, not records to publish together.
Successive TXT values for _dmarc.example.com (publish one at a time)DNS
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. See RFC 9989 test mode.
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
Decide policy scope before enforcement. A subdomain's own applicable DMARC record takes precedence over an inherited policy. When the organizational-domain record is used, sp sets subdomain handling and np sets handling for non-existent subdomains. Without np, non-existent subdomains inherit sp if present, otherwise p, as specified in RFC 9989 policy tags.
|
|
|
|---|---|---|
p | The policy domain and subdomains without an applicable override | Choose its monitoring or enforcement policy |
sp | Subdomains; also non-existent subdomains when np is absent | Use an override only when subdomain senders need different handling |
np | Non-existent subdomains | Set handling for DMARC failures using names that return NXDOMAIN |
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 that support np to reject failures using non-existent subdomains. Keep an sp=none exception only as long as the migration requires it.
A non-existent subdomain returns NXDOMAIN; a subdomain without MX records is not necessarily non-existent. Receivers that ignore np fall back to sp or p.
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 and report changes. Quarantine is not guaranteed delivery: recipients can miss mail in spam, and administrator quarantine can restrict access.
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: they can accept DMARC failures under p=reject or filter mail that passes. RFC 9989 section 7.4 advises domains whose users post to mailing lists against p=reject. Such domains choosing reject should first monitor p=none for at least a month, then p=quarantine for at least another month, and compare dispositions. A clean direct-mail stream does not remove mailing-list risk.
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.
For SPF, compare the MAIL FROM (usually shown as Return-Path) domain with the visible From domain. For DKIM, compare the signing d= domain. Relaxed alignment accepts the same organizational domain; strict alignment requires an exact match. An unrelated vendor domain can pass authentication while DMARC still fails. See RFC 7489 identifier alignment.
- Classify unfamiliar sources; give each authorized sender a business owner and retire unused systems.
- 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.
Check the reported policy and disposition alongside the authentication results, including any receiver override reason. RFC 9990 distinguishes raw SPF and DKIM results from DMARC evaluation. Aggregate reports do not prove inbox placement. Reports cover participating receivers, so compare them with the sender inventory and delivery logs. If reports stop, check the rua destination and any required external reporting authorization.
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 where neither authentication path survives. A DMARC pass needs only one aligned mechanism; RFC 9989 nevertheless requires senders using p=reject not to rely solely on SPF.
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.
When to pause enforcement or roll back
Record the publication time and DNS TTL before changing policy. Cached records remain in use until their TTL expires, so DNS rollback is not immediate. Review the next complete aggregate reporting periods and test critical mail flows directly; reports commonly arrive daily rather than immediately.
- Pause the rollout if a known legitimate source starts failing. Capture its source IP, receiver error, and Authentication-Results headers when available, then check SPF and DKIM domain matching.
- For a business-critical disruption, restore the last known working policy while fixing the sender. Keep the reporting destination unchanged so the investigation continues.
- Confirm the restored value is published, ask the sending system to resend rejected messages, and test the affected workflow before advancing again. Accepted mail in spam or quarantine requires separate recovery.
A higher count of rejected spoofing attempts alone is not a rollback trigger. Focus on legitimate failures and business impact. Keep monitoring after p=reject because new vendors and authentication changes can introduce failures later.
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 without assessing whether enforcement is safe for legitimate mail.
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 view
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 view
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
Frequently asked questions
Use p=reject when legitimate senders are configured and indirect-mail risks are acceptable. Domains whose users post to mailing lists need particular caution under RFC 9989. Parked and non-sending domains should normally use p=reject after confirming that no legitimate system sends with those domains. Publish an SPF policy that authorizes no senders when the domain sends no mail.
No. It is a practical staging step, not a universal requirement. It is useful for complex domains because it can expose missed senders with a softer requested handling level.
Stay at p=none until normal sending cycles have appeared in reports, every source has an owner, and legitimate failures are fixed or explicitly accepted. That can take weeks for a simple domain and months for a complex one. For domains whose users post to mailing lists, RFC 9989 recommends at least a month at p=none and another month at p=quarantine before choosing reject.
It can affect legitimate mail that still fails DMARC because receivers can refuse that mail. It does not directly improve the inbox placement of mail that already passes. Review every business-critical source before enforcement.
Keep monitoring aggregate reports and important mail flows alongside support tickets. If business-critical legitimate mail fails after the change, pause enforcement or restore the last known working policy, fix the sender, and retest. DNS caches mean a rollback does not take effect everywhere immediately.
