DMARC policy modes explained: p=none vs p=quarantine vs p=reject

The p= tag is where DMARC stops being just a reporting mechanism and starts becoming a delivery policy.

It tells participating receivers what the domain owner wants done with messages that fail DMARC. That last part matters more than many guides make clear: p=none, p=quarantine, and p=reject do not change how receivers treat mail that already passes DMARC. They only apply when both SPF alignment and DKIM alignment fail.

The other part that matters is less comforting: receivers are asked to apply your policy on a best-effort basis. Per RFC 7489, a receiver should try to follow the published policy, but it can still use local judgment and override it.

So the practical question is not just "what does the tag mean?" It is "what does a large mailbox provider usually do with it in the real world?"

The quick mental model

Think of the three modes like this:

• p=none: monitor failures, but do not request a specific delivery action
• p=quarantine: treat failures as suspicious
• p=reject: refuse failures at SMTP time when possible

That is the intended progression for most live domains.

Google's DMARC setup guide explicitly recommends starting at p=none, then moving to p=quarantine or p=reject as authentication coverage improves. Microsoft documents the same gradual rollout pattern, and Yahoo requires bulk senders to publish at least p=none with DMARC passing for the mail they send.

What p=none really means

Example:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

This says: "send aggregate reports, but do not take a policy action just because the message failed DMARC."

That does not mean the message goes to the inbox.

It only means the domain owner is not asking for quarantine or rejection. The receiver can still filter, bulk-folder, spam-folder, throttle, or reject the message based on its own anti-abuse systems, content analysis, reputation, user complaints, or local policy.

That is why p=none is best understood as a monitoring mode, not a delivery guarantee.

In practice, receivers usually do something like this for DMARC-failing mail under p=none:

• accept it if other signals look harmless
• place it in spam or junk if the message also looks suspicious
• still block it in some cases if other anti-spam controls are strong enough
• include the failure in aggregate reports when rua is configured

Google's admin guidance describes none as taking no DMARC-specific action while still logging the mail in reports. RFC 7489 says the domain owner requests no specific action regarding delivery. Those two ideas line up closely.

What p=quarantine really means

Example:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@example.com

This says: "if a message fails DMARC, treat it as suspicious."

Per RFC 7489, quarantine can mean things like:

• place into spam folder
• scrutinize with additional intensity
• flag as suspicious

That is deliberately broad. DMARC does not standardize one exact mailbox action.

So what happens at receivers?

• many providers will send the message to spam or junk
• some will still accept the message but add internal suspicion signals to downstream filtering
• some enterprise gateways will quarantine outside the user's inbox entirely
• some receivers may still reject certain messages if the message looks clearly abusive

This is why p=quarantine is often the safest first enforcement step. It raises the cost of spoofing, but it usually leaves a recovery path for legitimate mail that was accidentally left unauthenticated.

If a domain is still discovering senders, p=quarantine is usually much less painful than going straight from p=none to p=reject. For the rollout details, keep DMARC pct rollout done right nearby.

What p=reject really means

Example:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com

This says: "if a message fails DMARC, do not accept it."

RFC 7489 says rejection should occur during the SMTP transaction. That is the cleanest outcome because the receiving side refuses the message before it is fully accepted, and the sending side can get an SMTP error immediately.

In practice, receivers often do one of these things:

• reject the message during SMTP with a 5xx response
• block the message before inbox placement in a provider-specific way
• accept and silently discard in some edge cases driven by local policy
• override the requested reject action if the receiver believes some other signal justifies different handling

That last bullet is important. DMARC policy is powerful, but it is still advisory to the receiver. Even at p=reject, the receiver is not a robot that must ignore its own filtering stack.

Still, p=reject is the strongest public statement a domain can publish for exact-domain spoofing. It is the mode that best supports anti-spoofing goals and is typically the end state for actively used domains once legitimate senders are aligned.

It is also the policy level required for some adjacent controls. For example, providers such as Google document that BIMI requires enforcement at p=quarantine or p=reject, not p=none.

What receivers are actually deciding

The p= tag is only consulted after the receiver has already decided the message failed DMARC.

That means:

1. SPF is evaluated.
2. DKIM is evaluated.
3. Alignment with the visible From: domain is checked.
4. If neither SPF nor DKIM produces an aligned pass, DMARC fails.
5. Only then does the receiver look at p=none, p=quarantine, or p=reject.

If this decision path is fuzzy, DMARC troubleshooting with real headers is the best companion read.

Why outcomes differ between providers

Admins sometimes expect one failed message to be treated identically everywhere. That is not how DMARC works in production.

Two receivers can both honor DMARC and still produce different user-visible outcomes because they differ on:

• local spam filtering and reputation systems
• whether they reject during SMTP or later in the pipeline
• how aggressively they use quarantine versus junk-folder placement
• whether they trust ARC in forwarding scenarios
• whether a local allowlist, impersonation policy, or enterprise security rule overrides the requested action

RFC 7489 explicitly allows receiver override and reporting of those overrides. So different behavior across providers is normal, not necessarily evidence that one provider is "ignoring DMARC."

The most common misunderstanding: p=none does not mean safe delivery

This trips up teams during testing.

They publish p=none, send a spoofed or misaligned message, watch it land in spam, and conclude DMARC is broken. Usually it is not broken at all. The receiver is simply saying, "the domain owner did not ask for a DMARC enforcement action, but this message still looks bad for other reasons."

The reverse misunderstanding also happens. Teams move to p=reject, see one failing message show up somewhere, and conclude the receiver ignored policy. That can happen, but it can also be an override case, a forwarding path, a local enterprise quarantine workflow, or a mail stream that did not actually fail DMARC the way it first appeared.

A practical rollout path for most domains

For active domains, the conservative sequence is still the right one:

1. Start with p=none and collect aggregate reports.
2. Inventory every legitimate sender using your domain in From:.
3. Fix SPF and DKIM alignment for all important sources.
4. Move to p=quarantine and observe for at least one real business cycle.
5. Move to p=reject only when reports stay boring.

If forwarding and mailing lists are part of your environment, do not skip that validation step. DMARC and forwarding/mailing lists explains why apparently healthy mail can still fail after transit changes.

Side-by-side summary

Bottom line

p=none, p=quarantine, and p=reject are not three guaranteed mailbox outcomes. They are three receiver-policy requests that apply only to DMARC-failing mail.

p=none means visibility.

p=quarantine means suspicion.

p=reject means refusal.

What any individual receiver actually does still depends on that receiver's own filtering pipeline, override logic, and operational choices. That is why the safest DMARC deployment pattern is still simple: monitor first, enforce second, and treat aggregate reports as the evidence for every step.