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?

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 is another major issue because it frequently breaks SPF. DKIM can survive forwarding when the message isn't modified, which is one reason robust DKIM deployment is particularly important before using p=reject.

Mailing lists can be even more complicated. They may both forward the message and modify its contents, potentially breaking SPF and DKIM at the same time.

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.

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.

Forwarding can cause legitimate DMARC failures

Forwarding is one of the reasons DMARC can become more complicated than simply checking whether SPF and DKIM are configured.

Imagine:

sender@example.com
    ↓
original recipient
    ↓
forwarding service
    ↓
final recipient

SPF checks whether the server delivering the message is authorized by the domain used for SPF authentication.

When a message is forwarded, the final receiving system may see the forwarder's IP address rather than the original sending server.

That can cause SPF to fail.

DKIM can survive forwarding because the cryptographic signature travels with the message. But if an intermediary modifies signed portions of the message, the DKIM signature may also fail.

If neither an aligned SPF result nor an aligned DKIM result survives, DMARC fails.

This is one reason receiving systems may sometimes override a domain owner's published DMARC policy when they have evidence that a message is legitimate despite the authentication result.

Mailing lists can complicate DMARC too

Mailing lists can create similar problems.

A message might originally be sent as:

From: alice@example.com

and successfully authenticate when it reaches the mailing list.

The list then redistributes the message to its subscribers.

During that process, it may:

• send from different infrastructure,
• change the envelope sender,
• add a subject prefix,
• append a footer,
• modify the message body,
• or otherwise transform the message.

Those changes can break SPF, DKIM, or both.

Modern email systems have developed mechanisms such as ARC (Authenticated Received Chain) to preserve authentication information across intermediaries. ARC can provide useful context to the final receiver, but it does not simply turn a DMARC failure into a DMARC pass.

The receiver ultimately decides how much trust to place in that information.

This is another reason DMARC enforcement should be introduced after understanding your real mail flows rather than treating every authentication failure as proof of malicious activity.

What happens if you publish p=reject too early?

This is the biggest operational risk with DMARC.

Suppose your company uses:

Microsoft 365
HubSpot
Salesforce
Zendesk
Shopify
a payroll platform
an invoicing system

but you only configure authentication for Microsoft 365.

Then you publish:

v=DMARC1; p=reject

Your normal employee email might work perfectly.

Meanwhile, a legitimate system could send:

From: invoices@example.com

without aligned SPF or DKIM.

That message fails DMARC.

You've now told receiving systems that a DMARC failure represents an invalid use of your domain.

Depending on the receiver and circumstances, your own legitimate invoice could be rejected.

The problem isn't that p=reject is too aggressive.

The problem is that the domain wasn't ready for p=reject.

Does p=reject stop all spoofing?

No.

This distinction is important.

DMARC primarily protects against unauthorized use of your domain in the visible From address.

If your domain is:

example.com

an attacker might try:

From: security@example.com

A properly deployed DMARC policy can make that type of direct-domain impersonation much harder to deliver successfully.

But an attacker could instead register:

example-security.com

or:

examp1e.com

and send:

From: security@examp1e.com

Your DMARC record for example.com doesn't control another domain.

DMARC therefore helps protect your domain identity, but it doesn't eliminate phishing, lookalike domains, display-name impersonation, compromised accounts or every other form of email abuse.

p=none isn't necessarily a bad DMARC configuration

DMARC checkers sometimes make p=none look like an outright configuration failure.

That's too simplistic.

Consider a domain that just published:

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

and is actively analyzing its mail ecosystem before enforcement.

That is a perfectly reasonable stage of a DMARC deployment.

Now consider another domain that has been sitting at:

p=none

for five years, never looks at its reports and assumes DMARC is protecting it from spoofing.

That's very different.

So the useful question isn't simply:

Is p=none bad?

It's:

Why is the domain using p=none, and is there a plan to progress toward enforcement?

For a new deployment, p=none can be exactly where you should start.

For a mature deployment where all legitimate senders are known and aligned, remaining permanently at p=none leaves DMARC's enforcement capability unused.

Should you use p=quarantine or go directly from p=none to p=reject?

There isn't one correct answer for every domain.

A very simple domain might have:

• one email provider,
• no marketing platform,
• no CRM,
• no transactional email,
• no mailing lists,
• no unusual forwarding,
• and months of clean DMARC data.

Once the owner is confident that legitimate mail passes DMARC, moving to p=reject may be reasonable.

A complex organization with dozens of sending systems has much more reason to use p=quarantine as an intermediate enforcement stage.

The important part isn't checking a box that says you used all three policies.

It's establishing confidence that legitimate mail will continue authenticating after enforcement.

Which DMARC policy should you use?

For most domains, the progression is straightforward:

The long-term goal for many domains is:

p=reject

But getting to reject safely matters more than getting there quickly.

DMARC policy examples

Monitoring

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

Use this while discovering legitimate senders and analyzing authentication.

Quarantine

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

Use this when you're ready for DMARC failures to receive enforcement treatment but aren't yet comfortable requesting rejection.

Reject

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

Use this when legitimate sending systems are known, properly authenticated and aligned.

Reject with a separate subdomain policy

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

This can be useful when the organizational domain is ready for rejection but applicable existing subdomains need different treatment.

Don't copy a record blindly.

Your record should reflect how your domain actually sends email.

aligned SPF

aligned DKIM

p=none

p=quarantine

p=reject

p=none

p=reject

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.