Email authentication

p=quarantine vs p=reject: Which DMARC Policy Should You Use? [2026]

TL;DR: p=quarantine tells receivers to send mail that fails DMARC to the spam folder. p=reject tells them to bounce it outright at the receiving server. Reject is stronger, but the gap between them is smaller than most vendors imply, and p=quarantine is a defensible end state for many domains. The right answer depends on your threat model and whether you can afford to lose a legitimate message you haven't classified yet. Don't jump to reject to feel finished. Earn it with evidence.

By Adam, DMARCit · Last updated July 2026

What each policy actually tells receivers

DMARC gives you three policy values. p=none is monitor-only: the receiver takes no action on failing mail and just sends you aggregate reports. p=quarantine asks the receiver to treat failing mail as suspicious, which in practice means the spam or junk folder. p=reject asks the receiver to refuse the message during the SMTP transaction, so it never reaches the mailbox at all. The current specification for all three is RFC 9989 (DMARCbis), which replaced the original RFC 7489 in May 2026.

The word "asks" is load-bearing. DMARC policy is a request, not a command. Large receivers honor it, but each one applies its own local overrides on top: a message that a receiver believes was forwarded, or arrived via a known mailing list, may be exempted from your policy even when it fails alignment. Those overrides show up in your aggregate reports under policy_evaluated, and they are the reason your enforced record can look busier in the reports than you expected.

Everything on this page assumes the message in question failed DMARC, meaning neither SPF nor DKIM passed and aligned with the domain in the From: header. Mail that passes DMARC is never touched by your policy value, no matter what you set. If legitimate mail is landing in spam after you publish p=quarantine, that is an alignment problem, not a policy problem, and the fix is upstream.

The real difference: recoverable vs gone

The practical distinction is recoverability. At p=quarantine, a failing message still gets delivered somewhere the recipient can reach it. It rots in the junk folder, but a determined human can dig it out, mark it "not spam," and rescue the thread. At p=reject, the message is refused at the door. The only artifact is a bounce notification back at the sender, and the recipient never knows it existed.

That asymmetry cuts both ways. Reject is better security: spoofed mail impersonating your domain dies before anyone sees it, so there is no phishing lure sitting in a junk folder waiting for a curious click. But reject is also less forgiving of your own mistakes. A legitimate sender you forgot to align produces a hard bounce and an angry internal thread, where the same misconfiguration under quarantine produces a "check your spam folder" workaround.

This is why the honest framing is not "reject is the goal and quarantine is a stepping stone." It is "reject trades recoverability for airtightness." Whether that trade is worth it depends entirely on which failure you fear more: a spoofed message surviving in a spam folder, or a legitimate message you misclassified disappearing without a trace.

When p=quarantine is a defensible end state

A lot of DMARC guidance treats anything short of p=reject as unfinished work. That is vendor framing, not operational reality. For a large share of domains, p=quarantine is a perfectly reasonable place to stop. Failing mail goes to spam, which neutralizes the vast majority of domain-spoofing abuse, and you keep the recoverability cushion for the long tail of legitimate mail that flows through forwarders and lists you can never fully enumerate.

Quarantine is the right end state when your domain isn't a marquee phishing target, when you have a messy sending footprint with forwarders and mailing lists you can't fully control, and when the cost of one lost legitimate message is high relative to the marginal security gain of bouncing spoofed mail instead of junking it. A small professional-services firm whose biggest risk is invoice-fraud spoofing, not a nation-state campaign, is usually well served by full quarantine.

The one thing quarantine-as-end-state requires is honesty about why you stopped. "We hold at quarantine because our forwarding footprint makes reject risky" is a defensible engineering decision. "We published p=quarantine; t=y to satisfy an auditor and never dropped the testing flag" is enforcement cosplay: at t=y the receiver still treats failing mail as p=none, so DMARC leaves every failing message untouched. If you are going to stop at quarantine, publish it for real. Drop t=y so receivers actually junk failing mail, on purpose.

When p=reject is worth the risk

Reject earns its keep in a few specific situations. If your domain is a genuine phishing target, a bank, a large payroll or benefits provider, a well-known consumer brand, then a spoofed message surviving in a recipient's spam folder is a real lure, and bouncing it outright is worth the operational cost. The airtightness is the point.

Regulatory and contractual regimes can also make the call for you. The US federal CISA BOD 18-01 directive names p=reject explicitly for federal agencies, and various security frameworks and enterprise vendor questionnaires increasingly ask for it by name. If a contract or a compliance regime you are bound by says reject, then quarantine is not an option regardless of your own risk math.

A note on the Gmail and Yahoo bulk-sender requirements, because they get misquoted constantly. The rules that took effect in February 2024 require bulk senders to publish a DMARC record, with a minimum policy of p=none. They do not require quarantine or reject. Meeting the Gmail and Yahoo bar is a reason to have DMARC at all, not a reason to jump to reject. Anyone citing those requirements to push you to p=reject is selling urgency, not accuracy.

The enforcement ramp: none to quarantine to reject

You do not flip from p=none to p=reject in one move. You ramp, and the ramp is gated on evidence, not on a calendar. The sequence is: sit at p=none long enough to build a complete sender inventory from your aggregate reports (30 days is a reasonable floor), move to p=quarantine, then to p=reject, and let alignment on your legitimate mail hold at each step before you climb to the next.

The safety lever for each step is the t= testing flag, introduced in RFC 9989. Publishing p=quarantine; t=y tells receivers to keep your quarantine policy on record but apply it one level softer while you test, so failing mail is treated as p=none instead of being junked. Publishing p=reject; t=y does the same one notch up: failing mail is quarantined rather than bounced. That gives you a recoverable dry run of each enforcement step in production before it lands for real. Drop the flag (t=n is the default) once your alignment rate on legitimate volume holds above your threshold over a multi-day lookback. For the full staged plan with back-off steps, see /learn/dmarc-pct-rollout.

A word on pct=, because older rollout guides lean on it. The pct= tag once asked receivers to apply your policy to a percentage of failing mail, ramped 10, 25, 50, 75, 100. RFC 9989 removed it. Receivers applied those intermediate percentages inconsistently for over a decade, so the same record produced different enforcement at different mailbox providers. Treat pct= as legacy: the DMARCit generator no longer emits it, the checker flags it obsolete, and any receiver you care about may ignore it. The binary t= flag is what replaced it.

Before you touch enforcement at all, your SPF needs to be healthy. An SPF record throwing permerror because it blew past the 10-lookup limit removes SPF as an alignment path and makes your DMARC failures worse, not better. Fix that first: see /learn/spf-permerror. Publishing p=reject on top of a broken SPF record is how you turn a config error into a deliverability incident.

What breaks at reject (and how to see it first)

Three things account for nearly every "we moved to reject and lost mail" story, and all three are visible in your aggregate reports before you commit if you know what to look for.

Forwarding breaks SPF. When a message is forwarded, the forwarding server becomes the new sender, but the return-path domain often stays yours, so the SPF check runs against an IP that isn't in your record and fails. DKIM usually survives forwarding as long as the body isn't modified, so a forwarded message that still carries an aligned DKIM signature passes DMARC anyway. The ones that break are forwards where DKIM was stripped or never present. At quarantine those land in spam; at reject they bounce.

Mailing lists break DKIM. Discussion lists routinely rewrite the subject line, append a footer, or otherwise modify the body, which invalidates the original DKIM signature. Some lists rewrite the From: header to their own domain (which sidesteps the problem), but the ones that don't will fail DMARC on your domain. ARC exists to preserve authentication results across these hops, but receiver support is uneven, so you cannot assume it saves you.

Unclassified legitimate senders. The SaaS tool marketing signed up for last quarter without telling IT. The transactional provider whose DKIM was never set up. These show up in your aggregate reports as failing sources with real volume. The whole point of holding at quarantine and reading reports is to find and align them before reject turns them into bounces. If you can't name every source of meaningful failing volume in your reports, you are not ready for reject.

The DMARCit approach

DMARCit's enforcement-readiness flow is built around the idea that the policy value is the easy part and the gate is the hard part. The product tracks every sending source it sees in your aggregate reports, lets you mark each one legitimate, unauthorized, forwarded, or needs-review, and computes an alignment rate on your legitimate volume over a configurable lookback window. The advance recommendation is unblocked only when that rate clears the threshold, so you move from quarantine toward reject on evidence rather than on a reminder in your calendar.

We don't write your DNS for you. The tool generates the next TXT record value with the rollback value pre-computed next to it, preserves your existing rua=, ruf=, and sp= tags in the diff, sets the t= testing flag for you on the dry-run rungs, and polls DNS after you publish to confirm the change landed. The honest framing is that this is alignment-evidence-gated, not enforcement-on-autopilot. You still own the decision to advance to reject. We make the evidence and the rollback visible in the same place as the button.

For the guided walkthrough of the staged ramp, see /enforcement-readiness. For where DMARCit sits in the broader category, see the /compare/dmarc-tools pillar and pricing at /pricing.

FAQ