DMARC p=quarantine vs p=reject: which should you use?

Once your DMARC reports look clean, you have two enforcing policies to choose from. Both tell receivers your domain is protected; they differ in what happens to a message that fails. This guide compares p=quarantine and p=reject: what the standard says, what Gmail, Microsoft 365 and Yahoo document doing with each, the risks, and how to decide when to move. If you're still at p=none, start with moving DMARC from p=none to p=reject.

What do p=quarantine and p=reject mean?

RFC 9989, the current DMARC standard, defines the p tag as the domain owner's "message handling preference" for mail that fails DMARC. Section 4.7 describes the two enforcing values:

• quarantine: "The Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern."
• reject: "The Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid."

RFC 9989 calls either one "Enforcement". Section 3.2.9 explains the practical effect: failing messages "will not reach the inbox at Mail Receivers that participate in DMARC and honor the Domain Owner's expressed handling preference."

The RFC doesn't define a spam folder or a quarantine. It leaves the details to receivers. Section 5.4 says "the final handling of any message is always a matter of local policy". For rejection, section 7.2 describes two methods: a "full rejection" with a 5xx reply during the SMTP session, so the sending server generates a bounce, or a "silent discard" that accepts the message and then drops it.

Receivers may soften reject

RFC 9989 is explicit that receivers shouldn't apply p=reject blindly. Section 5.4 says they "SHOULD NOT reject messages solely because of a published policy of 'reject'" and should apply "other knowledge and analysis". Section 7.4 goes further for indirect mail: receivers "MUST NOT reject incoming messages solely on the basis of a 'p=reject' policy", and without other analysis "MUST treat such failing mail as if the policy were 'p=quarantine'". The same section admits that "few Mail Receivers apply any mitigation techniques" for forwarded and list mail.

So treat p=reject as a strong request. Many receivers reject; some quarantine instead.

What do Gmail, Microsoft 365 and Yahoo do with each policy?

Here's what each provider documents at the time of writing (October 2026). Where a provider doesn't document something, we say so.

Gmail

Google's recommended DMARC rollout says that with quarantine, "Messages that don't pass DMARC go to the recipient's spam folder", and that with reject, messages "are rejected by receiving servers and never delivered." Those descriptions are about receivers in general. For Gmail itself, the sender guidelines FAQ says that for messages failing DMARC, "the enforcement defined in the sending domain's DMARC policy generally applies", and that DMARC is one factor among several.

When Gmail rejects, the bounce is specific. Google's SMTP error reference lists 550 5.7.26 "Unauthenticated email from domain-name is not accepted due to domain's DMARC policy." If Gmail can't complete the DNS lookups, it defers instead with 451 4.7.26, "but temporary DNS failures". See our page on 550 5.7.26.

Microsoft 365

Microsoft 365 tenants decide for themselves, through the anti-phishing policy. The setting is Honor DMARC record policy when the message is detected as spoof, with a separate action for each sender policy (Microsoft Learn):

• p=quarantine: "Quarantine the message" or "Move the message to the recipients' Junk Email folders".
• p=reject: "Quarantine the message" or "Reject the message".

Microsoft's recommended settings table lists the default, Standard and Strict values as: honor DMARC on, p=quarantine → Quarantine the message, p=reject → Reject the message. Its DMARC setup article summarizes the general behavior slightly differently, as "Junk Email folder (configurable to quarantine)" for p=quarantine and "Rejected during SMTP (550 5.7.1)" for p=reject, stamped action=oreject. The two pages don't agree on the quarantine default, so check a real tenant with Get-AntiPhishPolicy | Format-List Name, HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction.

Three conditions matter:

1. The action applies when "the message is detected as spoof". Microsoft also says a composite authentication failure "doesn't directly result in a message being blocked"; it weighs other signals.
2. If the tenant's MX points to a filtering service in front of Microsoft 365, the honor setting "is applied only if Enhanced Filtering for Connectors is enabled" on the inbound connector.
3. Admins can override it with safe senders, the Tenant Allow/Block List, allowed senders in anti-spam policies, or mail flow rules.

Microsoft's Exchange Online NDR reference also lists 5.7.509 Access denied for mail whose From domain fails DMARC and publishes p=reject, so senders may see either code.

Microsoft also treats your outbound mail differently. Mail from a Microsoft 365 domain that fails DMARC at the destination "is routed through the High-risk delivery pool for outbound messages if the DMARC policy for the domain is p=reject or p=quarantine", and "there's no override for this behavior."

Yahoo

Yahoo's SMTP error codes page lists 553 or 554 for "Your message failed authentication checks against your sending domain's DMARC or DKIM policy." Yahoo doesn't publicly describe how it handles p=quarantine failures, so don't assume a specific folder.

What are the risks of each policy?

The quiet failure mode of quarantine is easy to miss. A misconfigured invoicing tool can send to the spam folder for weeks before a customer mentions it. Reject surfaces the same problem immediately, as a bounce, which is painful but obvious.

Both policies carry the same forwarding risk; reject just makes it more costly. RFC 9989 section 7.4 says domains publishing p=reject "MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages." Our guide to forwarding, SPF and ARC explains why.

When should you move from quarantine to reject?

RFC 9989 section 7.4 gives the cautious path for domains whose users might post to mailing lists: publish p=none "for at least a month", then p=quarantine "for an equally long period of time", and compare the results. It says such domains "SHOULD NOT" publish p=reject at all unless they've checked the impact and told users that list participation "may be hindered".

Move to reject when all of these are true:

1. You've run p=quarantine for at least a month, including a month-end and any seasonal mail such as payroll or newsletters.
2. Every legitimate source in your reports passes DMARC through aligned DKIM, not just aligned SPF. Check selectors with the DKIM Checker.
3. The remaining failures are forwarding, mailing lists you've accepted, or sources you've confirmed aren't yours. Unknown sources in DMARC reports shows how to sort them.
4. Nobody has reported legitimate mail stuck in spam during the quarantine stage.
5. Your SPF record has no PermError and you know which ending you use; SPF softfail vs hardfail explains why -all can reject forwarded mail before DMARC runs.
6. Someone owns the reports after the switch, so new failures get noticed.

Use test mode as a bridge

RFC 9989 replaced pct with t=y. With p=reject; t=y, updated receivers apply the policy one level down, which the RFC spells out: "if the policy is 'reject' and the value of the 't' tag is 'y', a policy of 'quarantine' will be applied to failing messages". Receivers still following the older RFC 7489 ignore t, so some will apply full reject. Treat the step as real enforcement for part of your mail. DMARC record examples shows the exact records, and our DMARCbis guide covers pct and t in detail.

Domains that don't send mail

Skip quarantine. Publish v=DMARC1; p=reject with v=spf1 -all on every parked or non-sending domain straight away. See protect parked domains from spoofing.

Which records should you publish?

Keep rua in every record. Reports are how you see a new failure after you tighten the policy. The DMARC Record Generator builds each one, and DMARC subdomain policy explains sp and np.

How do you check what happened to a failing message?

1. Ask the recipient for the full headers if the message was delivered to spam, or for the bounce text if it was rejected.
2. In the headers, read Authentication-Results. Look for dmarc=fail and the action, such as action=quarantine or action=oreject at Microsoft 365. Our Email Header Analyzer reads it in your browser.
3. In a bounce, look for the code: 550 5.7.26 from Gmail, 550 5.7.1 or 5.7.509 from Microsoft 365, 553 or 554 from Yahoo.
4. In your aggregate reports, check the disposition and any reason. Load them into the DMARC Report Analyzer to see dispositions per source.

Next steps

• Check your current policy and tags with the DMARC Checker.
• Confirm every sending service signs with aligned DKIM before you move past quarantine.
• If you're unsure, run p=quarantine for a month, then p=reject; t=y, then p=reject, reading reports at each step.
• iBlockSpam's domain monitoring alerts you if your DMARC record changes unexpectedly, weekly on Protect and daily on Protect Plus.

Related: why the "DMARC policy not enabled" warning appears. If you use iBlockSpam, its DMARC monitoring recommends when your own senders pass consistently enough to move from quarantine to reject.

Browse our other SPF, DKIM and DMARC guides.