DMARC p=none vs p=quarantine vs p=reject: Complete Guide

A DMARC record is one line of DNS, but the p= tag inside it is the single most consequential setting in your entire email authentication setup. It decides what happens to every email that fails SPF and DKIM alignment and most domains are stuck on the setting that does the least.

Here's what each value actually does, why agencies leave domains on the weak one for years, and how to move through them without breaking mail flow.

What the p= tag controls

DMARC doesn't authenticate anything by itself. SPF and DKIM do that work. DMARC's job is to tell receiving mail servers what to do when a message fails both and to give the domain owner visibility into who's sending mail as their domain in the first place.

The p= tag is the instruction receiving servers follow. There are three possible values, and they form an escalating ladder.

p=none: monitor only

p=none tells receiving servers to take no enforcement action on failing mail. Messages that fail SPF and DKIM alignment still get delivered exactly as if DMARC weren't there. The only thing this policy does is turn on reporting you start receiving aggregate reports (RUA) showing who's sending mail using your domain, and whether it's passing or failing.

This is the correct starting point for any new DMARC setup. It lets you see the full picture every legitimate sending source (your ESP, your CRM, your helpdesk, your own mail server) plus anything spoofing your domain without risking real mail getting blocked while you're still mapping out what "legitimate" even includes.

The problem is that p=none provides zero protection. A domain sitting at p=none is no harder to spoof than a domain with no DMARC record at all. Anyone can send email claiming to be you, and the receiving server will deliver it anyway.

If you want to see what spoofing actually looks like against a real domain, read how to detect if someone is spoofing your domain.

p=quarantine: send failing mail to spam

p=quarantine tells receiving servers to treat failing mail as suspicious typically routing it to the spam or junk folder rather than rejecting it outright. The mail isn't blocked, but it's also not landing in the primary inbox.

This is the real transition point. Once you're confident the aggregate reports show every legitimate sending source passing consistently, p=quarantine is where you start actually doing something about the mail that fails. It's also lower-risk than jumping straight to reject if something was missed in the audit, the email degrades to spam instead of disappearing entirely, which is recoverable and visible.

Most agencies that get this far stop here, either because reject feels too risky or because nobody circles back to finish the rollout. That's a reasonable place to pause, but it's not the end state.

p=reject: block failing mail outright

p=reject tells receiving servers to refuse failing mail entirely. No inbox, no spam folder the message is rejected at the server level, the same way a hard-bounce would behave.

This is full DMARC enforcement, and it's what's required for the strongest anti-spoofing protection, including compliance with bulk sender requirements from Google and Yahoo. It's also the policy that actually stops phishing emails impersonating the domain from reaching anyone.

The risk at this stage isn't theoretical: if there's a sending source still misaligned that the reports didn't fully surface, p=reject will silently drop that mail with no notification to the sender. That's why this should be the last step, not the first.

The rollout that avoids breaking mail

The safe path through these three stages looks the same for almost every domain:

1. Start at p=none and let aggregate reports run for at least a few weeks. This surfaces every sending source including ones agencies often forget about, like a CRM, a support desk tool, or an old marketing platform still sending on the domain.
2. Fix alignment issues for each legitimate source found in the reports usually by adding it to the SPF record or setting up DKIM signing for that platform.
3. Move to p=quarantine once reports show consistent passing across all known senders. Watch reports for another stretch to confirm nothing was missed.
4. Move to p=reject once quarantine has run clean for a meaningful period with no surprises in the failure reports.

Skipping straight from p=none to p=reject is the most common mistake, and it's the one that actually breaks deliverability a missed sending source goes from "slightly suspicious, still gets read eventually" to "silently gone" overnight.

For a step-by-step walkthrough of the full journey, see the agency guide to DMARC enforcement.

What pct= does and why it matters

One setting agencies often overlook is pct=, which controls what percentage of failing mail the policy applies to. The default is pct=100, meaning the policy applies to all failing messages.

During the transition from p=quarantine to p=reject, some teams use pct= to roll out gradually for example, starting at pct=10 to apply p=reject to only 10% of failing mail, then increasing over time as they confirm nothing legitimate is breaking. This is optional but useful for large organizations with complex sending infrastructure.

For agencies managing client domains, the risk of missing a sending source is real. A client's domain might be sending transactional email from a platform the agency doesn't manage directly. Starting at a lower pct= gives a softer landing if something was missed.

Subdomain policy and the sp= tag

The sp= tag controls what happens to subdomains. If you set p=reject on the root domain but don't specify sp=, subdomains inherit the root policy. If you explicitly set sp=none, subdomains get no enforcement even if the root domain is at p=reject.

This matters because attackers frequently pivot to subdomains when a root domain is locked down. A spoofing attempt that can't get through mail.domain.com might try support.domain.com or notifications.domain.com if those subdomains have no separate DMARC enforcement.

For any domain at p=reject, confirm the subdomain policy is explicitly set and not accidentally weakened. This is one of the 25 checks Infraova monitors automatically across every client domain.

Why so many domains never leave p=none

Aggregate reports are raw XML. They're not built to be read by a human, and most domain owners who set up DMARC once never look at them again after the initial setup so a domain sits at p=none indefinitely, technically configured, providing essentially no protection.

This is also why p=none age is worth tracking on its own. A domain newly at p=none is mid-rollout, expected. A domain that's been at p=none for two years is a domain where the rollout stalled and nobody's watching to push it forward.

For agencies managing multiple client domains, stalled DMARC rollouts across an entire portfolio are a common pattern. Clients set up DMARC during onboarding, nobody followed up, and now dozens of domains are stuck at p=none with no clear owner for finishing the job. This is the kind of drift that proactive monitoring catches before a client asks why their domain is still spoofable.

The bottom line

p=none is a monitoring tool, not a security setting. p=quarantine is meaningful but partial. p=reject is the only policy that actually stops spoofed mail from reaching an inbox. Most domains stop somewhere in the middle and stay there by accident rather than by decision which means the gap between "has DMARC" and "DMARC is actually doing something" is wider than the DNS record alone suggests.

This is exactly the kind of drift Infraova's DMARC checker watches for automatically flagging a domain that's been sitting at p=none for months, tracking when reports go quiet, and surfacing the next safe step instead of leaving someone to read raw XML reports by hand.

---

Frequently Asked Questions

What does p=none mean in DMARC?

p=none is the weakest DMARC policy. It tells receiving mail servers to take no action on email that fails SPF and DKIM alignment the mail is delivered normally. The only effect of p=none is that it turns on DMARC aggregate reporting, so you can see who is sending email using your domain. It provides no protection against spoofing.

What is the difference between p=quarantine and p=reject?

p=quarantine routes failing email to the recipient's spam or junk folder rather than the inbox. The message is still delivered just downgraded. p=reject goes further: it tells receiving servers to refuse the message entirely, so it never reaches the recipient at all. p=reject provides stronger protection but carries more risk if any legitimate sending source is not yet aligned.

Should I use p=none or p=reject?

Start at p=none to collect aggregate reports and map out every legitimate sending source. Once all sources are passing SPF and DKIM alignment consistently, move to p=quarantine, then to p=reject. Jumping directly from p=none to p=reject without completing that audit risks silently dropping legitimate mail from sending sources you haven't configured yet.

How long should I stay at p=quarantine before moving to p=reject?

Most guidance recommends monitoring at p=quarantine for at least two to four weeks before moving to p=reject. The goal is to confirm that nothing legitimate is being caught by the quarantine policy. If you're seeing legitimate mail in spam folders during this period, there are still sending sources that need to be fixed before escalating to reject.

Does DMARC p=reject stop all phishing?

p=reject stops spoofing that uses your exact domain in the From address. It does not protect against look-alike domains (e.g., infraova-support.com pretending to be infraova.com) or display-name spoofing where the From name matches your brand but the actual email address doesn't. Full protection requires p=reject on your domain plus monitoring of your DMARC aggregate reports for unauthorized senders.

What happens to email that fails DMARC at p=reject?

The receiving mail server rejects the message and returns a non-delivery report to the sending server. From the recipient's perspective, the email never arrives there's no spam folder entry, no notification, nothing. From the sender's perspective, it looks like a bounce. This is why p=reject needs to be the last step in a careful rollout, not the first.

How do I check my current DMARC policy?

You can check your DMARC record by running a DNS TXT lookup on _dmarc.yourdomain.com. The result will include the p= tag showing your current policy. Free tools like MxToolbox's DMARC lookup will parse the record for you. If you manage multiple client domains, Infraova monitors the DMARC policy across all of them automatically and alerts when a domain has been stuck at p=none for too long.