p=reject vs p=none in DMARC - Which One to Choose?

What DMARC Policies Actually Do

A DMARC policy instructs email receivers on how to treat mail that fails domain alignment. Simply put, it answers the question: if SPF and DKIM don’t align with your domain, what should the recipient’s mail server do? This policy is published in DNS and applies to your domain by default, and its subdomains unless otherwise specified.

If you need a quick overview of the essentials, check out this clear guide to SPF, DKIM, and DMARC, it covers the basics without unnecessary jargon.

Quick rule: Either DKIM or SPF must both pass and align with your visible From domain for a message to succeed DMARC.

With this in mind, choosing p=none versus p=reject revolves around timing, risk, and your sender coverage.

p=none: Monitor Everything, Block Nothing

What it does: The p=none policy tells receivers to deliver emails as usual, but also to send aggregate reports to you. These reports reveal who is sending mail on your behalf, which sending methods align properly, and where misalignments or failures occur.

The p=none approach is particularly beneficial when:

You’ve recently added DKIM to some tools and want to confirm they’re set up correctly.
You have several third-party vendors sending on your behalf and need to map them all.
You suspect your domain is being spoofed and need data before taking enforcement action.
Your team requires more time to safely address alignment issues.

What it does not do: It does not prevent users from receiving spoofed or malicious emails. Attackers can still bypass protection if recipients’ servers honor your p=none policy.

Useful tags with p=none: Use rua= for aggregate XML reports, ruf= for forensic message samples (if supported), fo=1 for forensic detail, and ri= to control report intervals.

p=reject: Block Misaligned Mail at the Door

What it does: The p=reject policy instructs receivers to discard emails that fail DMARC checks. These messages will never reach the recipient’s Inbox or Spam folder, making it the strongest measure against domain spoofing.

When it fits:

All legitimate email traffic from your domain passes SPF or DKIM with proper alignment.
You fully understand how email forwarding and mailing lists behave for your recipient base.
Security and brand protection are high priorities for your organization.
You intend to implement BIMI, which requires an enforced DMARC policy.

What to watch for: Email forwarding can break SPF, and mailing lists may break DKIM signatures. If both fail and lack alignment, p=reject will result in delivery failure for those messages.

But What About p=quarantine?

Think of p=quarantine as a softer enforcement step. Messages that fail DMARC will likely land in the spam folder rather than being silently discarded. It’s a useful intermediate phase as you transition from p=none toward p=reject.

Use the pct= tag with quarantine to apply the policy to a sample of your email traffic. Start with a low percentage, review the impact through reports, and increase the threshold as your DMARC alignment improves.

How to Decide Between p=none and p=reject

To determine which policy fits your organization, consider these questions:

Do all legitimate senders for your domain currently authenticate and align messages properly?
Do you have full visibility and points of contact for every sender using your domain?
Can my support team handle a false-positive incident (where legitimate emails are misinterpreted as failing DMARC) quickly?

If the answer to all three is “yes,” it’s safe to enforce DMARC. If any answer is “no,” start with monitoring (p=none), address the issues you discover, and then move to enforcement once you’ve resolved gaps.

For most organizations, a gradual rollout is ideal: start with p=none for discovery, move to p=quarantine with sampling, and enforce p=reject only once you’re confident all legitimate mail passes alignment checks.

A Practical Rollout Plan You Can Follow

Follow this proven path to strengthen your DMARC stance:

Inventory all senders. Include departments like marketing, CRM, HR, billing, product, and your application stack.
Authenticate each sender using SPF and DKIM, ensuring the visible From domain is aligned.
Publish p=none with the rua reporting address. Collect and review reports for two to four weeks.
Resolve failures. For shared IPs, implement DKIM alignment. Address issues with forwarding, prioritize DKIM for resilience.
Move to p=quarantine using pct=25 to sample enforcement. Monitor the effects, then increase to 50%, then 100%.
Switch to p=reject only after you see zero false positives in your reports.

For subdomains that haven’t been fully reviewed yet, set sp=none to avoid accidental disruption. This stops spoofing on the primary domain while you complete audits of your subdomains.

Sample DMARC Records for Each Stage

Monitor Stage (p=none)

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1; adkim=r; aspf=r; ri=86400

Relaxed alignment (r) minimizes disruptions during the monitoring phase.

Soft Enforcement (p=quarantine) with Sampling

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com; fo=1; adkim=s; aspf=s

Strict alignment (s) moves you toward a clean enforcement state while limiting risk using pct.

Full Enforcement (p=reject) with Subdomain Exception

v=DMARC1; p=reject; sp=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1; adkim=s; aspf=s

This configuration prevents unauthorized mail on your main domain while you finalize subdomain audits.

Note: Many providers limit or redact ruf forensic reports. Don’t rely on them for comprehensive insight.

Edge Cases That Can Affect Your DMARC Decision

Forwarding and alumni addresses. SPF often fails when email is forwarded. Ensure DKIM survives across hops.
Mailing lists. Lists that modify headers or content may break DKIM. Prepare for some DMARC failures under these circumstances.
Third-party CRMs. Some services send from shared domains. Wherever possible, use your own domain with DKIM keys you manage.
Transactional vendors. Always align the From domain, even if the Return-Path differs.
BIMI plans. BIMI requires a p=quarantine or p=reject policy. A p=none record will not qualify.

If any of these scenarios apply to you, allow extra time using p=none and p=quarantine. Fix misalignments before fully enforcing with p=reject.

Reading DMARC Reports Without Overwhelm

Aggregate XML reports can be overwhelming at first glance. Group results by source IP, sending domain, and pass rate. Assign each sender an owner within your organization. If a vendor fails consistently, escalate the issue to their deliverability contact.

Leverage tools like mailX’s diagnostics to identify patterns and highlight alignment gaps. For new domains, begin with a gradual ramp-up to preserve engagement while fine-tuning authentication. Services such as mailwarm can aid in this process.

Common Myths About DMARC Policies

“p=none is enough protection.” It isn’t, p=none only requests reports and doesn’t stop threats.
“SPF covers me.” SPF alone is insufficient unless it aligns with your From domain.
“Reject will nuke my real mail.” If DKIM is correctly set up and tested, legitimate mail won’t be lost.
“We can skip quarantine without any potential issues.” While possible, quarantine provides a safer transition to full enforcement.

When you’re uncertain, rely on the reports. Only enforce once the data confirms it’s safe to do so.

Which Should You Choose Today?

If you are still discovering all your senders, start with p=none. Gather reports and resolve any alignment issues. Once you’re confident that your map is complete and the data is clean, move to p=reject to prevent domain spoofing. Many organizations use quarantine as a step in between, which is a perfectly valid approach.

One key point: don’t confuse delivery with deliverability. An email passing SMTP delivery doesn’t guarantee it lands in the Inbox. If these concepts are unclear, this primer on deliverability versus delivery is a great place to start.

Wrap-Up

No setup is perfect at the start. Publish p=none, study the results, fix any issues, and move to enforcement when ready. The p=reject policy is useful for mature programs because it provides effective protection for users and the brand. However, it’s crucial to collect and analyze relevant data first before moving to enforcement.

If you want expert feedback on your rollout plan, reach out to professionals who handle this routinely. A review from experts can potentially save a significant amount of time and avoid unnecessary hurdles. You can consult the team at mailadept if you want to transition from monitoring to enforcement efficiently.

FAQ

What happens if I choose p=none for my DMARC policy?

Choosing p=none means you’re not taking any direct action against unauthenticated emails. It’s a monitoring phase where you collect data, but bear in mind that it offers no protection against spoofing or attacks.

Is it safe to skip the p=quarantine phase and directly enforce p=reject?

Jumping straight to p=reject is risky. Without the interim p=quarantine phase, you might disrupt genuine email flows and face backlash due to unforeseen authenticity issues.

Why isn’t p=none sufficient for email security?

p=none merely requests reporting, doing nothing to stop misaligned or malicious emails. Relying only on this phase exposes your domain to spoofing and potentially harms your organization’s reputation.

Can relying on SPF alone suffice for DMARC compliance?

SPF isn’t enough; it must align with your From domain. Without DKIM’s assurance, even aligned SPF records might misguide you, and skipping DKIM could hinder proper enforcement.

What are the risks of setting p=reject without thorough testing?

Imposing p=reject without complete validation might result in legitimate emails failing delivery, frustrating stakeholders and causing operational chaos if misalignments go unnoticed.

Are forensic reports reliable for detecting email issues?

Many providers limit forensic reports, so relying solely on them is unwise. They offer limited visibility, making aggregate reports and proper diagnosis crucial for effective oversight.

What misperceptions exist about SPF’s role in email security?

Many mistakenly believe SPF alone secures email transactions, but without DKIM alignment, you’re left vulnerable. Misguided reliance on SPF can perpetuate vulnerabilities if misconfigurations are prevalent.