# DMARC Reject vs Quarantine: What's the Difference?

> DMARC reject vs quarantine: reject blocks failing email outright, quarantine sends it to spam. Compare both policies and learn when to move to reject.

**The difference between DMARC reject and quarantine is what happens to email that fails authentication: `p=reject` tells receiving servers to refuse the message entirely, while `p=quarantine` tells them to accept it but treat it as suspicious, usually by delivering it to the spam folder.** Reject is the stronger end state; quarantine is the safer stepping stone while you confirm every legitimate sender passes SPF and DKIM.

| | `p=quarantine` | `p=reject` |
|---|---|---|
| **Failing email is** | Delivered to spam/junk (or held in a gateway quarantine) | Refused during delivery, never reaches the recipient |
| **Protection level** | Strong (spoofed mail is kept out of the inbox | Strongest) spoofed mail is never delivered at all |
| **Risk to legitimate mail** | Low (a misconfigured sender lands in spam and can be recovered | Higher) a misconfigured sender bounces outright |
| **Best for** | Rollout and testing phase | Fully verified sending setup (the end goal) |

Both policies only apply to mail that **fails** DMARC, messages where neither [SPF nor DKIM](/learning/what-is-email-authentication-and-why-does-it-matter) passes with a domain that aligns with the visible From address. Mail that authenticates correctly is delivered normally under either policy.

## What does a DMARC quarantine policy do?

[`p=quarantine`](/learning/glossary/dmarc-p-quarantine) instructs receiving servers to accept email that fails DMARC but treat it with suspicion. In practice, consumer mailbox providers like Gmail and Yahoo route these messages to the spam or junk folder, while some business email gateways hold them in an administrative quarantine for review instead.

Quarantine is the standard middle stage of a DMARC rollout. It delivers real protection (spoofed messages stop landing in inboxes) while leaving a safety net: if you missed a legitimate sending service in your [SPF record](/tools/spf) or forgot to enable DKIM signing somewhere, those messages are still delivered (just to spam), not silently destroyed. You can spot the problem in your [DMARC reports](/resources-post/how-to-understand-dmarc-reports), fix the authentication gap, and move on without losing mail.

## What does a DMARC reject policy do?

`p=reject` is the strictest DMARC policy: it tells receiving servers to refuse any message that fails DMARC during the SMTP transaction, so the message is bounced and never reaches the recipient in any folder. This is the policy that actually stops domain spoofing. Attackers can no longer land impersonated mail anywhere in your recipients' mailboxes.

The trade-off is that reject leaves no room for authentication mistakes. If a legitimate service sends on your behalf but isn't covered by SPF or DKIM, that mail bounces. That's why reject should be the destination of a staged rollout, not the starting point.

## DMARC quarantine vs reject: which is more secure?

Reject is more secure, because failing mail is never delivered, there's no chance a user digs a convincing phishing message out of the spam folder and acts on it. Quarantine still blocks the inbox, but the message technically exists in the recipient's mailbox.

![Side-by-side comparison of DMARC reject and quarantine policies covering action on failure, security level, and when to use each.](/images/figures/dmarc-reject-vs-quarantine-whats-the-difference-fig1.webp "1200x488")
*Reject blocks failing email outright; quarantine routes it to spam while you test.*

That said, "more secure" only matters once your own mail reliably passes. A premature reject policy doesn't make you safer: it makes your invoices, password resets, and notifications bounce. Security teams should judge readiness by DMARC report data, not by ambition.

## What about DMARC none vs quarantine?

`p=none` is the third policy option: [monitoring mode](/learning/glossary/dmarc-p-none). Mail that fails DMARC is still delivered normally. The only effect is that you receive aggregate reports showing which sources are sending as your domain and whether they authenticate. None provides visibility but zero protection; quarantine is the first policy level that changes how failing mail is handled.

Every DMARC deployment should start at `p=none` to build an inventory of legitimate senders. But staying there long-term defeats the purpose: spoofed mail is still delivered while you watch it happen in reports.

## Which DMARC policy should you use, and in what order?

The proven rollout order is **none → quarantine → reject**:

1. **Start at `p=none`** and collect aggregate reports for a few weeks to identify every service sending as your domain.
2. **Fix authentication** for each legitimate source: add them to SPF, enable DKIM signing, and confirm alignment.
3. **Move to `p=quarantine`** once reports show your legitimate mail passing consistently. To ease into it, publish `t=y` alongside the policy: receivers report as if the policy were live but hold off applying it. (The old `pct` tag did this by sampling a percentage of failing mail; RFC 9989 removed it.)
4. **Move to `p=reject`** when quarantine has run cleanly, no legitimate mail failing, and you're confident the sender inventory is complete.

![Four steps for safely moving a DMARC policy from quarantine to reject.](/images/figures/dmarc-reject-vs-quarantine-whats-the-difference-fig2.webp "1200x699")
*Move gradually: monitor reports and verify senders before enforcing reject.*

You can build a correct record for any stage with our free [DMARC record generator](/tools/dmarc-generator), and verify what's currently published with the [DMARC checker](/tools/dmarc). For a deeper look at when tightening makes sense, see [should you be changing your DMARC policy to make it stricter over time](/learning/what-should-dmarc-policy-be-set-to).

## How do you move from quarantine to reject safely?

Treat the switch as a data-driven decision:

- **Watch aggregate reports while at quarantine.** Every failing source should be either an attacker or a sender you've deliberately chosen not to authorize. Never a forgotten legitimate service.
- **Check subdomains.** Unless you set a separate subdomain policy (`sp`), your policy applies to subdomains too, so confirm their senders are authenticated as well.
- **Phase with `t=y`, not `pct`.** RFC 9989 removed `pct`, and `t=y` takes over its staged-rollout job: publish the stricter policy, keep getting reports, and receivers hold off enforcing it until you drop the tag. Plenty of receivers still honour `pct` from the RFC 7489 era, where mail outside the percentage fell back to the next-less-strict policy (reject falling back to quarantine), but that behaviour is no longer in the spec, so do not build a rollout on it.
- **Keep monitoring after enforcement.** New tools and vendors get added constantly; each one needs SPF/DKIM set up before it starts sending, or its mail will bounce.

## Frequently asked questions

### Does p=quarantine always send mail to the spam folder?

No. DMARC expresses a request, and the receiving server decides how to honor it. Most consumer providers deliver quarantined mail to spam/junk, but enterprise gateways may hold it in an admin quarantine, tag the subject, or apply extra filtering instead.

### Is p=none pointless since it blocks nothing?

No: it's the essential first step. None gives you the reporting data to find every legitimate sender before you enforce anything. It's only a problem when a domain stays at none indefinitely, which leaves spoofing unaddressed.

### What happens to forwarded email under p=reject?

Forwarding usually breaks SPF because the forwarding server isn't in your SPF record, but DKIM signatures normally survive forwarding intact. Since DMARC passes when either SPF or DKIM passes with alignment, properly DKIM-signed mail still passes after forwarding. That's why enabling DKIM everywhere matters before moving to reject.

### Can a DMARC policy affect email that passes authentication?

No. Reject and quarantine only apply to messages that fail DMARC. Mail that passes SPF or DKIM with alignment is delivered normally regardless of policy, though it's still subject to ordinary spam filtering like any other message.

## Ready to enforce your DMARC policy?

Understanding reject vs quarantine is the easy part. The work is getting every legitimate sender authenticated so you can enforce with confidence. Palisade automates that journey for MSPs and businesses: monitoring reports, flagging unauthenticated senders, and guiding domains from none to quarantine to reject without lost mail. Start by checking where your domain stands with our free [Email Security Score](/tools/email-security-score).