The Three DMARC Policies
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 | Full |
| Impact on legitimate email | None | Low risk | High if misconfigured |
| DMARC reports sent | Yes | Yes | Yes |
| Phishing blocked | No | Sometimes | Yes |
| Best for | Initial setup | Transition phase | Production domains |
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've 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 haven't finished auditing them all.
- You manage a legacy domain with many historical third-party senders that are difficult to track down.
- You're 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 actually 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 isn't covered by your SPF record or doesn't 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.