DMARC p=none vs p=quarantine vs p=reject: What Each Policy Really Does

At first glance, they seem simple:

• p=none — monitor DMARC failures without requesting enforcement.
• p=quarantine — tell receiving systems that failed messages should be treated as suspicious.
• p=reject — tell receiving systems that failed messages represent invalid use of your domain.

But there is an important distinction that many DMARC guides miss:

These policies do not literally mean “deliver,” “send to spam,” and “block.”

DMARC expresses the domain owner's handling preference. The receiving email provider still controls the final disposition of a message. Under the current DMARC standard, RFC 9989, receivers can apply local filtering and override the published policy when appropriate.

There was also a major change to DMARC in 2026. RFC 9989 replaced the older RFC 7489 specification and removed the widely documented pct tag, introducing a new testing mechanism instead.

So if you're deciding which DMARC policy to use, here's what the three policies actually mean today.

Want to see what your domain is publishing right now?

Check your DMARC record with InspectMyPage →

DMARC p=none vs p=quarantine vs p=reject at a glance

The key word here is typical.

p=quarantine does not guarantee that a failed message goes to the spam folder, and p=reject does not force every receiving system on the Internet to reject the message.

The current DMARC specification explicitly leaves final handling decisions to the receiving system.

How DMARC decides whether an email passes

Before the policy matters, DMARC first determines whether the message passes authentication.

DMARC works with two existing email authentication systems:

SPF verifies whether the sending infrastructure is authorized to send for a domain.

DKIM adds a cryptographic signature to the message that can be validated using a public key published in DNS.

DMARC adds another requirement:

Alignment

The authenticated domain must align with the domain users see in the email's From: address.

For example, imagine someone receives:

From: billing@example.com

The message could technically pass SPF using a completely different domain:

MAIL FROM: bounce@email-provider.net

That does not necessarily produce a DMARC pass for example.com.

Likewise, a DKIM signature could successfully authenticate:

d=email-provider.net

but still fail DMARC alignment with:

From: example.com

For DMARC to pass, at least one authentication mechanism must both pass and align:

SPF passes + SPF domain aligns
              OR
DKIM passes + DKIM domain aligns
              ↓
          DMARC PASS

You do not need both SPF and DKIM to align for a protocol-level DMARC pass. Having both properly configured, however, provides much better resilience.

What p=none really does

A basic monitoring record looks like this:

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

p=none means the domain owner is expressing no DMARC-specific handling preference for messages that fail.

It is commonly called monitoring mode.

If a message fails DMARC under p=none, the receiving system continues using its existing spam filters, reputation systems, security controls, and other signals.

That means p=none does not mean:

DMARC fail → Inbox

A message can still be rejected or sent to spam for completely unrelated reasons.

It also means p=none provides no DMARC enforcement against someone directly spoofing your domain.

Why use p=none then?

Because it gives you an opportunity to understand your email ecosystem before enforcing DMARC.

When you configure an aggregate reporting address with rua, participating receivers can send reports showing which systems are sending email using your domain and whether those messages pass SPF, DKIM, and DMARC.

That can uncover forgotten sources such as:

Google Workspace
Microsoft 365
Mailchimp
SendGrid
CRM systems
support platforms
billing systems
website forms
HR platforms
transactional email providers

You can then authenticate legitimate sources before enforcing a stricter policy.

One important clarification:

p=none itself does not turn reporting on.

Reporting is requested separately with rua=.

What p=quarantine really does

A quarantine policy could look like:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com

p=quarantine tells receiving systems that the domain owner considers messages failing DMARC to be suspicious.

This is the first major enforcement step.

A common explanation is:

DMARC fail → Spam

That's useful shorthand, but it isn't technically guaranteed.

Depending on the receiver, a failed message could be:

sent to Spam
sent to Junk
placed in quarantine
tagged as suspicious
subjected to additional filtering
or handled differently by local policy

For example, Microsoft documents Junk Email or quarantine behavior for DMARC failures under applicable p=quarantine configurations.

So a better mental model is:

DMARC FAIL
     ↓
p=quarantine
     ↓
"Treat this message with lower trust."
     ↓
Receiver decides final disposition

This makes quarantine useful as an intermediate enforcement stage.

You begin protecting the domain from spoofing while retaining more tolerance than p=reject.

What p=reject really does

A reject policy could look like:

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

This is DMARC's strongest enforcement policy.

The domain owner is effectively saying:

A DMARC failure is a clear indication that this use of my domain is invalid.

Receiving systems commonly reject those messages during SMTP.

For example:

Attacker
   ↓
spoofs billing@example.com
   ↓
SPF does not align
DKIM does not align
   ↓
DMARC FAIL
   ↓
example.com publishes p=reject
   ↓
Receiving server rejects message

This is the end state most organizations ultimately want because it provides the strongest DMARC protection against direct-domain spoofing.

But there's an important caveat.

p=reject does not guarantee universal rejection

The current DMARC standard allows receivers to override the domain owner's requested policy.

A receiver may have additional information indicating that a message is legitimate despite failing DMARC.

Forwarding and mailing lists are classic examples.

Microsoft and Yahoo document scenarios in which they honor p=reject by rejecting failed messages, but that does not mean every receiving mail system behaves identically.

So think of p=reject as:

the strongest DMARC enforcement request — not a universal Internet-wide command.

Which DMARC policy should you use?

For most domains implementing DMARC for the first time, the progression is:

p=none
   ↓
Observe legitimate mail
   ↓
Fix SPF/DKIM alignment
   ↓
p=quarantine
   ↓
Watch for legitimate delivery problems
   ↓
p=reject

The mistake is moving to enforcement before understanding who legitimately sends email for the domain.

Imagine a company sends email through:

Microsoft 365
HubSpot
Salesforce
Zendesk
Mailchimp
Stripe
a WordPress website
an HR platform

Microsoft 365 might authenticate perfectly while a forgotten website form or SaaS application doesn't.

Switching directly to p=reject could cause legitimate business email to be rejected.

That's why DMARC deployment is less about changing one DNS value and more about identifying and authenticating every legitimate sending stream.

Important 2026 change: pct is no longer part of the current DMARC standard

This is one of the biggest changes to DMARC in years — and many guides still haven't caught up.

For more than a decade, administrators were commonly told to roll out DMARC like this:

v=DMARC1; p=quarantine; pct=10

then:

pct=25

then:

pct=50

and eventually:

pct=100

That guidance came from the previous DMARC specification, RFC 7489.

RFC 9989 removed pct

In May 2026, the IETF published a new set of DMARC specifications:

RFC 9989 → Core DMARC protocol
RFC 9990 → Aggregate reporting
RFC 9991 → Failure reporting

Together they obsolete RFC 7489.

RFC 9989 removed pct after operational experience showed that intermediate percentage values were implemented inconsistently by receiving systems.

That means a record such as:

v=DMARC1; p=quarantine; pct=25

should no longer be presented as the current standards-based way to gradually deploy DMARC.

Some major provider documentation still describes pct, so you may continue seeing it in existing records and setup guides.

But it is now legacy DMARC behavior rather than part of the current DMARC standard.

What replaced pct?

RFC 9989 introduces the t testing tag.

For example:

v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com

When t=y is used, the published policy is expected to be treated one enforcement level lower during testing.

Conceptually:

Published policy       Testing treatment

p=quarantine  + t=y →  none
p=reject      + t=y →  quarantine

Reporting remains unaffected.

There is an important practical consideration in 2026, however:

The new specification is extremely recent.

Major provider documentation is still transitioning from RFC 7489, and transparent support information for t=y is not yet sufficient to assume identical implementation everywhere.

For that reason, don't rely exclusively on t=y as your safety mechanism.

A careful staged rollout with reporting and verification remains essential.

Read the current DMARC specification — RFC 9989

Does a stricter DMARC policy improve email deliverability?

Not automatically.

This is another important misconception.

DMARC authentication and inbox placement are related, but they aren't the same thing.

A message can:

SPF PASS
DKIM PASS
DMARC PASS

and still end up in spam.

Mailbox providers evaluate many other signals, including:

sender reputation
IP reputation
spam complaints
sending patterns
message content
recipient engagement
DNS configuration
bounce behavior
abuse signals

Google explicitly recommends maintaining very low spam complaint rates and avoiding rates of 0.3% or higher.

Yahoo similarly uses reputation and complaint signals in addition to authentication.

DMARC helps establish authenticated identity and prevents unauthorized use of your domain.

It does not guarantee inbox placement.

Common problems to fix before using p=reject

One of the most common DMARC problems is authentication without alignment. Your email provider may successfully authenticate SPF or DKIM using its own domain while your visible From address uses yours. DMARC can still fail because those domains don't align.

Forwarding can cause legitimate DMARC failures

Forwarding is another major issue because it frequently breaks SPF. The final receiving system may see the forwarder's IP address rather than the original sending server, so the SPF check no longer reflects the original delivery.

DKIM can survive forwarding because its signature travels with the message, but an intermediary that modifies signed content can break that signature too. If neither aligned SPF nor aligned DKIM survives, DMARC fails even when the original message was legitimate.

Mailing lists can complicate DMARC too

Mailing lists may redistribute a message from different infrastructure, change the envelope sender, add a subject prefix or footer, or modify the body. Those changes can break SPF, DKIM, or both.

ARC (Authenticated Received Chain) can preserve authentication context across intermediaries, but it does not turn a DMARC failure into a pass. The final receiver decides how much trust to place in that context.

You should also check for SPF permerror conditions. SPF evaluation has a limit on DNS-query-causing mechanisms, and overly complex records can exceed it.

Finally, don't forget subdomains. A parent-domain DMARC policy can affect subdomains that don't publish their own applicable policy. RFC 9989 also introduces np for policy treatment involving non-existent subdomains.

What happens if you publish p=reject too early?

If a company authenticates Microsoft 365 but overlooks legitimate senders such as a marketing platform, support system, storefront, payroll provider, or invoicing service, those systems may send mail without aligned SPF or DKIM. Publishing p=reject at that point can cause the company's own messages to be rejected.

The problem isn't that p=reject is too aggressive. It's that the domain wasn't ready for it.

What DMARC does not stop

DMARC helps prevent unauthorized use of your exact domain in the visible From address. It does not stop lookalike domains, display-name impersonation, compromised accounts, or every other form of email abuse.

DMARC reporting: rua vs ruf

DMARC supports two different kinds of reporting.

For most deployments, aggregate reporting through rua is the important one.

A basic monitoring record is:

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

Aggregate reports can help identify:

sending IPs
email providers
message volume
SPF results
DKIM results
DMARC results
receiver dispositions

RFC 9990 now defines DMARC aggregate reporting separately from the core protocol.

RFC 9990 — DMARC Aggregate Reporting

Failure reports use ruf and may expose considerably more information about individual messages. RFC 9991 specifically raises privacy concerns around these reports, and not every provider sends them.

For example, Microsoft 365 currently documents that it does not send DMARC forensic/failure reports even when ruf is configured.

RFC 9991 — DMARC Failure Reporting

A safer path from p=none to p=reject

There isn't one universal number of days that every organization should spend at each DMARC policy.

A simple domain using one email provider may be straightforward.

A company with dozens of SaaS products, marketing systems, acquired domains, transactional email systems, support platforms, and decentralized IT may need much longer.

A reasonable process is:

1. Inventory legitimate email senders
                ↓
2. Configure SPF and DKIM
                ↓
3. Publish p=none + rua
                ↓
4. Analyze aggregate reports
                ↓
5. Find legitimate DMARC failures
                ↓
6. Fix authentication/alignment
                ↓
7. Move to p=quarantine
                ↓
8. Monitor delivery problems
                ↓
9. Fix remaining legitimate failures
                ↓
10. Move to p=reject
                ↓
11. Continue monitoring

The goal isn't to reach p=reject as quickly as possible.

The goal is to reach p=reject without rejecting legitimate email.

Bottom line

The difference between DMARC's three policies is ultimately about what you want receiving systems to do when mail fails DMARC:

p=none
→ Don't request DMARC-specific enforcement.

p=quarantine
→ Treat the failure as suspicious.

p=reject
→ Treat the failure as an invalid use of the domain.

p=none is valuable for discovery and monitoring.

p=quarantine introduces enforcement while providing a less severe policy than reject.

p=reject provides the strongest DMARC policy against direct unauthorized use of your domain in the visible From address.

But the goal shouldn't be to reach p=reject as fast as possible.

The goal is to reach it without breaking legitimate email.

That means knowing your senders, configuring SPF and DKIM correctly, verifying alignment, reviewing DMARC data and then enforcing with confidence.