DMARC p=none vs p=reject: Which to Use
p=none only reports, p=quarantine sends failing mail to spam, and p=reject blocks it. What each policy does and the path from monitoring to enforcement.
The three DMARC policies
Use p=none to monitor and p=reject to enforce. DMARC defines three policy levels that tell receiving mail servers what to do when an email fails authentication. The policy is set in your DNS TXT record using the p= tag.
- p=none — Monitor only. Emails are delivered normally regardless of authentication result. Reports are still sent to your RUA address.
- p=quarantine — Soft enforcement. Failing emails are sent to the spam/junk folder instead of the inbox.
- p=reject — Full enforcement. Failing emails are rejected outright by the receiving server and never delivered.
Policy comparison
| Feature | p=none | p=quarantine | p=reject |
|---|---|---|---|
| Spoofing protection | None | Partial (failing mail goes to spam) | Strong for exact-domain spoofing |
| Impact on legitimate email | None | Low risk | High if misconfigured |
| DMARC reports sent | Yes | Yes | Yes |
| Mail forging your exact domain | Delivered | Sent to spam | Rejected |
| Best for | Initial setup | Transition phase | Production domains |
No policy stops lookalike domains or display-name spoofing. Those need separate controls.
Recommended migration path
p=none to monitor, move to p=quarantine, then p=reject for full protection — advancing only as you confirm real senders pass.Jumping straight to p=reject without verifying your sending sources is risky — legitimate email from third-party services (CRMs, marketing platforms, ticketing systems) can be silently rejected. Follow this three-stage approach:
- Start with p=none. Publish your DMARC record with a monitoring-only policy. Collect aggregate reports for 2–4 weeks to identify all sources sending email as your domain.
- Move to p=quarantine. Once you have added SPF includes and DKIM keys for all legitimate senders, switch to quarantine. Monitor reports for any new failures before proceeding.
- Enforce p=reject. After confirming all legitimate traffic is authenticated, switch to reject. Continue monitoring aggregate reports for regressions caused by new sending services.
When to stay on p=none
There are legitimate reasons to remain on p=none long-term:
- You operate a large, complex email environment with dozens of sending services and have not finished auditing them all.
- You manage a legacy domain with many historical third-party senders that are difficult to track down.
- You are a parent organization with many subsidiaries using the same domain for sending.
However, p=none provides zero protection against spoofing. If your domain is being used for phishing campaigns, staying on none means attackers face no consequences. Treat it as a temporary state, not a destination.
Recommendation
For any domain actively used for email, the goal should be p=reject. It is the only policy that stops spoofed email from reaching recipients. Use p=none as a diagnostic starting point, p=quarantine as a safety net during transition, and move to p=reject as quickly as your environment allows.
Domains that never send email (parked domains, internal-only domains) should also be set to p=reject immediately — there are no legitimate senders to break.
Frequently asked questions
Can I use p=quarantine indefinitely?
Yes, but it provides weaker protection than reject. Spam filters can still surface quarantined emails to users, meaning phishing attempts may still reach inboxes in some clients. Use quarantine as a stepping stone, not a permanent policy.
Will p=reject break my email if my SPF or DKIM is wrong?
Yes — if a legitimate sending service is not covered by your SPF record or does not sign with DKIM, its email will fail DMARC and be rejected. This is why the monitoring phase with p=none is critical before enforcing reject.
Does p=none still send DMARC reports?
Yes. As long as you include a rua= tag in your DMARC record, aggregate reports are sent regardless of the policy level. This is what makes p=none useful — you get visibility without risk. Check your domain's current DMARC policy to confirm your record is configured correctly.
Sources
Applied guides on this topic
See what your own domain is publishing.
Everything in this article is externally observable. The free checker reads your records and tells you which of them are missing, weak, or already doing their job.