DMARC Quarantine vs Reject: Which Policy to Use

Quarantine sends failing mail to spam or junk, reject bounces it during SMTP so it never reaches the mailbox. For most brand domains, the right end state is p=reject, but only after 2 to 4 weeks of p=none reporting shows every legitimate sender aligned.

Organizations often approach DMARC quarantine vs reject as a one-time choice, when it is really a rollout sequence, and the wrong order is what breaks invoices, helpdesk mail, and legit forwarding.

What Quarantine and Reject Do to a Failing Message

A failed DMARC message gets two very different treatments. Quarantine tells the receiver to treat it as suspicious, so it usually lands in spam, junk, or another holding path controlled by the provider. Reject tells the receiver to refuse the message during SMTP, so it never reaches the mailbox. RFC 7489 draws that line clearly, but each receiver still applies it in its own way RFC 7489.

The part teams get wrong

Quarantine does not mean inbox placement. The message is still available to the recipient, just not in the inbox, and the provider decides how long to keep it Google Workspace DMARC guidance. Reject is stronger, but it still does not guarantee the same bounce behavior everywhere. Microsoft notes that p=reject can result in outright rejection or discard depending on the destination system Microsoft DMARC configuration.

Quarantine is the stage for visibility and recovery. Reject is the stage for hard enforcement after every legitimate sender has been mapped.

That rollout mindset is the right one. If the sender map is incomplete, reject is too early and it will break real mail. If you want the implementation sequence that supports that rollout, the guide for email deliverability teams is the right companion read, and HarvestMyData on email deliverability is a useful reference for how teams think about inbox outcomes in practice.

The short version

• p=quarantine: failing mail is usually held, filtered, or sent to spam.
• p=reject: failing mail is refused at the SMTP layer.
• Neither policy fixes bad alignment on its own.
• The policy only works when SPF or DKIM aligns with the visible From domain.

Where Most Domains Sit Today

The market is still messy, and that matters. In the Mailwarm network study, October 2026, DNS checks across 12,936 custom domains showed that 16% used p=reject, 16% used p=quarantine, 45% were still at p=none, and 24% had no DMARC record at all. That means monitoring still outruns enforcement by a wide margin, even among domains that are actively sending mail [Mailwarm network study, October 2026].

What that says about real-world rollout

p=none is not a failure. It's the observation stage, and too many teams leave it too soon or skip it entirely. The bigger issue is the gap between publishing a record and using it to control sender behavior. If nearly half of domains are still in monitor-only mode, then the work is not policy selection, it's sender discovery and alignment cleanup.

That lines up with how mailbox providers and enterprise gateways behave. Google and Yahoo's 2024 sender rules made SPF, DKIM, and DMARC relevant for broad delivery, but they didn't make enforcement mandatory at the same strength level. In other words, authentication became table stakes, but policy strength still depends on rollout quality EASydmarc DMARC adoption report 2026.

Opinionated take: if a domain is still at p=none, that's usually not because nobody knows what to do. It's because nobody has fully mapped who is actually sending.

The practical mistake is rushing from “we published DMARC” to “we're protected.” Those are not the same thing.

How Gmail, Microsoft, and Yahoo Each Treat the Policies

DMARC is a receiver-side instruction, not a promise of delivery. The same failing message can be handled differently depending on the mailbox provider, and that difference matters more than policy theory. Gmail, Microsoft, and Yahoo all honor quarantine and reject, but they expose the failure in different ways, which changes how you diagnose a rollout.

Provider-by-provider behavior at the SMTP layer

Microsoft is the clearest to operationalize because the reject signal is explicit. Its guidance shows that p=quarantine can send mail to Junk, inbox with an identifier, or another quarantine path, while p=reject can trigger rejection or discard depending on how the destination handles the message Microsoft 365 DMARC configuration. Gmail's guidance points the same way, quarantine is a staged control, not a free pass into the inbox Google Workspace admin security guidance.

The operator takeaway is simple. Reject gives you a hard failure signal, which is easier to count and investigate. Quarantine gives you a softer, receiver-defined path, which is better for validation but less precise. Gmail, Microsoft, and Yahoo all follow that pattern, even when the exact spam or inbox outcome differs.

If your sender team cannot explain where failed messages land at Gmail, Microsoft, and Yahoo, the domain is not ready for reject.

Test against all three, then compare those results with aggregate reports. That is how you separate policy behavior from reputation filtering and content scoring.

The Rollout We Use on Our Own Domains

We start with p=none because the essential work is finding every sender before enforcement begins. Google's recommended path is to monitor first, map the legitimate sources, then tighten policy only after the reports make the picture clear Google recommended DMARC rollout.

Start with reporting

The first record is simple:

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

That gives you room to see CRM tools, billing platforms, helpdesks, newsletter systems, and forwarding paths in aggregate reports. Two to four weeks is enough for most domains, because one clean day means nothing. You want a stable pattern.

Practical rule: if the report set still contains unfamiliar sources, the domain is not ready for reject.

Move to quarantine before you harden

Once the legitimate senders are known, quarantine becomes the intermediate control:

v=DMARC1; p=quarantine; pct=5; rua=mailto:reports@example.com

The pct tag exists for staged rollout, and Google recommends percentage-based progression instead of a sudden flip Google DMARC percentage guidance. That staged approach matters because third-party systems can still fail alignment even when they look correct on paper.

Quarantine is not the finish line. It is the test step that shows whether your auth stack holds up under real traffic before you force a hard fail.

End at reject for brand domains

When reports stay clean, the final state is:

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

That is the point where spoofing gets much harder and any new failure stands out fast. For teams that want the mechanics spelled out in one place, the full DMARC rollout is a useful reference. For broader sender hygiene, mass email deliverability tips is the right companion reading.

Why Cold Outreach Domains Should Not Follow the Same Playbook

Secondary outreach domains are different. Brand domains need stronger anti-spoofing posture because they carry trust across the company. Cold outreach domains care more about sender reputation, mailbox placement, and behavioral signals, so the policy target is usually alignment, not maximum strictness.

Why quarantine is usually enough there

Once SPF or DKIM aligns, mailbox providers mostly care about how the sender behaves. That means warmup, engagement, complaint rates, and content quality do more work than a stricter DMARC policy. For cold outreach, reject can create unnecessary operational noise if the team hasn't fully mapped every sending system or forwarding path.

Quarantine still gives a useful safety net. It protects the domain from obvious spoofing while avoiding the harder failure mode of reject, which is silent non-delivery for a sender nobody remembered to register. That's especially relevant when sales tools, recruiting tools, or vendor platforms send under a subdomain or shared brand identity.

For teams focused on outbound, Mailwarm's deliverability guide for cold outreach is the right companion reading. Mailwarm itself is a premium email warmup and deliverability platform, and that matters here because cold domains need real inbox engagement, not just policy tightening.

Short version: brand domains should end at reject. Cold outreach domains usually shouldn't.

The strictest DMARC setting is not what makes a cold domain perform. Reputation does.

What Breaks When You Jump to Reject Too Early

Reject forces every weak spot in the sender map to show up at the SMTP layer. If you still have uncatalogued senders, mismatched DKIM, or inherited policy on a subdomain, the failures appear as bounces, missing mail, and support tickets that look unrelated until you trace them back.

Forwarding and intermediary mail

Forwarded mail is the first thing that breaks. The forwarding host often becomes the SMTP sender, so SPF alignment falls apart even though the original message was legitimate. Under reject, that mail can bounce. Under quarantine, it is still more visible, which gives you a chance to catch the forwarding path before enforcement gets strict.

CRM and helpdesk systems

CRMs and helpdesk platforms are another common failure point. They often send as the brand domain, but if DKIM is not aligned, DMARC fails and reject stops the message. Teams usually discover this after a support inbox goes quiet, even though the vendor says delivery is fine.

Subdomain inheritance

sp= creates another trap. A strict policy at the root domain can flow down to a subdomain nobody treated as active, and that subdomain starts bouncing mail as soon as reject lands. The break is rarely tidy. It shows up as a sudden delivery drop, not a clean alert.

Operational rule: if delivery drops after reject, the problem is usually a sender nobody mapped.

Microsoft's guidance says the failure condition plainly, DMARC fails when SPF and DKIM do not align with the visible From domain Microsoft DMARC security ops guide. RFC 7489 treats forwarding as a known source of SPF breakage, and that is why reject should come after you have a complete sender inventory, not before.

Putting It Together and What to Do Next

For brand domains, the path is boring on purpose. Start at p=none, read aggregate reports, fix every real sender, move to quarantine with pct, then end at reject. For secondary outreach domains, stop at quarantine if alignment is clean and the send stack is already mapped.

The question isn't which policy sounds stricter. It's which policy matches the current visibility. If the reports still show unknown senders, reject is premature. If the reports are clean and every legitimate source is aligned, reject is the right end state.

Use check your DMARC record to confirm what's live right now. If the aggregate reports still show sources nobody can explain, that's when an account manager should get involved and trace the sender map before enforcement tightens.

Mailwarm helps teams build sender reputation, monitor inbox placement, and reduce spam risk with real inbox engagement and expert deliverability guidance. If DMARC reports still show unknown senders, visit Mailwarm and use it alongside your rollout before you move from quarantine to reject.