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

URL: https://iblockspam.com/blog/dmarc-quarantine-vs-reject
Last updated: 2026-10-10
Published: 2026-10-10
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> What p=quarantine and p=reject do to failing mail at Gmail, Microsoft 365 and Yahoo, what RFC 9989 says, the risks of each, and when to move to reject.

## Short answer

p=quarantine asks receivers to treat failing mail as suspicious, which usually means the spam folder or a quarantine. p=reject asks them to refuse it, so it bounces. Reject protects your domain more fully but loses forwarded and list mail that fails. Move from quarantine to reject only after reports show every legitimate sender passing with aligned DKIM.

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](https://iblockspam.com/blog/dmarc-none-to-reject-small-business).

## What do p=quarantine and p=reject mean?

[RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), 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.

| Receiver | Failing mail, `p=quarantine` | Failing mail, `p=reject` | Admin can change it? |
|---|---|---|---|
| Gmail | Google's rollout guide: "Messages that don't pass DMARC go to the recipient's spam folder" | Bounced with `550 5.7.26` | Not described in Google's DMARC help pages |
| Microsoft 365 (default policy) | Quarantine the message (alternative: Junk Email folder) | Reject the message (alternative: quarantine) | Yes, per anti-phishing policy |
| Yahoo | Not publicly documented | `553` or `554`, failed DMARC authentication checks | n/a |

### Gmail

Google's [recommended DMARC rollout](https://knowledge.workspace.google.com/admin/security/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](https://support.google.com/mail/answer/14229414?hl=en) 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](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes) 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](https://iblockspam.com/smtp-errors/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](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about)):

- **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](https://learn.microsoft.com/en-us/defender-office-365/recommended-settings-for-eop-and-office365) 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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) 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](https://iblockspam.com/smtp-errors/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](https://senders.yahooinc.com/smtp-error-codes/) 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?

| | `p=quarantine` | `p=reject` |
|---|---|---|
| Spoofed mail | Usually lands in spam or a quarantine, where some recipients still find and open it | Refused at receivers that follow it; never reaches the recipient |
| Legitimate mail that fails | Junked silently; nobody gets an error | Bounces back to the sender, so failures are visible |
| Recovery | Recipients or admins can release it | The sender has to resend after fixing the problem |
| Forwarded mail without aligned DKIM | Ends up in spam | Bounces at the final mailbox |
| Mailing lists that edit posts | Posts go to spam for some subscribers | Posts bounce; RFC 9989 warns subscribers can be unsubscribed automatically |
| Visibility in reports | `disposition` shows `quarantine` | `disposition` shows `reject`, unless the receiver overrode it |

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](https://www.rfc-editor.org/rfc/rfc9989.html#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](https://iblockspam.com/blog/email-forwarding-breaks-spf-dmarc-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](https://iblockspam.com/tools/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](https://iblockspam.com/blog/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](https://iblockspam.com/blog/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](https://iblockspam.com/blog/dmarc-record-examples) shows the exact records, and our [DMARCbis guide](https://iblockspam.com/blog/dmarcbis-rfc-9989-what-changed) 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](https://iblockspam.com/blog/protect-parked-domains-from-spoofing).

## Which records should you publish?

| Situation | Record |
|---|---|
| Quarantine stage | `v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com` |
| Testing reject at updated receivers | `v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.com` |
| Full reject | `v=DMARC1; p=reject; rua=mailto:dmarc@example.com` |
| Reject on main domain, quarantine on subdomains still being fixed | `v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc@example.com` |
| Parked domain | `v=DMARC1; p=reject` |

Keep `rua` in every record. Reports are how you see a new failure after you tighten the policy. The [DMARC Record Generator](https://iblockspam.com/tools/dmarc-generator) builds each one, and [DMARC subdomain policy](https://iblockspam.com/blog/dmarc-subdomain-policy-sp) 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](https://iblockspam.com/tools/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](https://iblockspam.com/tools/dmarc-report-analyzer) to see dispositions per source.

## Next steps

- Check your current policy and tags with the [DMARC Checker](https://iblockspam.com/tools/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](https://iblockspam.com/features/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](https://iblockspam.com/blog/dmarc-policy-not-enabled). If you use iBlockSpam, its [DMARC monitoring](https://iblockspam.com/features/dmarc-monitoring) recommends when your own senders pass consistently enough to move from `quarantine` to `reject`.

Browse our other [SPF, DKIM and DMARC guides](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### Is p=quarantine enough to stop spoofing of my domain?

It stops most spoofed mail from reaching the inbox at receivers that honor DMARC, because failing messages go to spam or a quarantine. Recipients can still find them there, and some will. p=reject goes further: receivers that follow it refuse the message, so it never reaches the recipient at all.

### Do Gmail and Outlook actually reject mail when my policy is p=reject?

Usually, yes. Gmail bounces it with 550 5.7.26 and the text 'Unauthenticated email from domain-name is not accepted due to domain's DMARC policy.' Microsoft 365's default anti-phishing policy rejects mail detected as spoof when the sender publishes p=reject. Both still weigh other signals, and admins can override the action for their own tenant.

### Where does mail go when it fails DMARC with p=quarantine in Microsoft 365?

It depends on the recipient tenant's anti-phishing policy. Microsoft's recommended settings list Quarantine the message as the default action for p=quarantine, with Move to Junk Email folder as the alternative. Its DMARC setup article describes the general behavior as the Junk Email folder, configurable to quarantine, so check Get-AntiPhishPolicy for your own tenant.

### Can p=reject cause legitimate email to bounce?

Yes, if a legitimate sender isn't aligned or a message is forwarded or changed on the way. Mailing lists that edit posts are the classic case. That's why RFC 9989 asks domains using p=reject to sign with valid DKIM, not rely on SPF alone, and to test at p=none and p=quarantine first.

### Should a domain that never sends email use quarantine or reject?

Reject. A domain that sends no mail has no legitimate messages to lose, so there's no reason for a softer policy. Publish v=DMARC1; p=reject together with an SPF record of v=spf1 -all, and a null MX record if the domain receives no mail either.

## Sources

- [RFC 9989: DMARC, sections 3.2.9, 4.7, 5.4, 7.2 and 7.4](https://www.rfc-editor.org/rfc/rfc9989.html)
- [Microsoft Learn: Anti-phishing policies (Spoof protection and sender DMARC policies)](https://learn.microsoft.com/en-us/defender-office-365/anti-phishing-policies-about)
- [Microsoft Learn: Recommended settings for EOP and Defender for Office 365 (anti-phishing defaults)](https://learn.microsoft.com/en-us/defender-office-365/recommended-settings-for-eop-and-office365)
- [Microsoft Learn: Set up DMARC to validate email in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure)
- [Google Workspace Admin Help: Recommended DMARC rollout](https://knowledge.workspace.google.com/admin/security/recommended-dmarc-rollout)
- [Google Workspace Admin Help: Gmail SMTP errors and codes](https://knowledge.workspace.google.com/admin/support/troubleshooting/gmail-smtp-errors-and-codes)
- [Gmail Help: Email sender guidelines FAQ](https://support.google.com/mail/answer/14229414?hl=en)
- [Yahoo Sender Hub: SMTP error codes](https://senders.yahooinc.com/smtp-error-codes/)

## Free tools for this guide

- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.
- [DMARC Record Generator](https://iblockspam.com/tools/dmarc-generator): Build a DMARC record with the right policy, reporting and alignment settings.
- [DMARC Report Analyzer](https://iblockspam.com/tools/dmarc-report-analyzer): Read DMARC aggregate reports (XML, gzip or zip): see who sends as your domain and what fails — runs in your browser.
- [DKIM Checker](https://iblockspam.com/tools/dkim-checker): Validate DKIM keys by selector, including key type and strength.

---

Source: iBlockSpam, https://iblockspam.com/blog/dmarc-quarantine-vs-reject (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt