DMARC Policies Explained: None vs Quarantine vs Reject

Why Three Levels, Not Just One On/Off Switch

A domain owner turning on DMARC for the first time is, in effect, making a claim: "every legitimate piece of mail from my domain will pass SPF or DKIM in alignment." That claim is very often wrong on day one, not because the domain owner is careless, but because modern organizations send mail through more channels than anyone tracks in one place — a CRM, a support desk, a billing platform, a marketing tool, sometimes a contractor's own infrastructure. If DMARC only had a single strict enforcement mode, every domain would need that claim to be true immediately, and getting it wrong would mean real mail silently disappearing.

The three-tier policy model — none, quarantine, reject — exists specifically to let that claim be verified gradually, with real data, before anything is actually blocked. It's not three unrelated settings to pick from; it's a deliberate progression, and understanding it as a progression rather than a menu is the single biggest factor in a DMARC rollout going smoothly.

p=none: Monitoring Without Consequence

At p=none, DMARC evaluation still happens on every receiving server that supports it — SPF and DKIM are still checked, alignment is still calculated — but the result has zero effect on delivery. Passing or failing mail is treated identically by the receiver's DMARC layer; other filtering systems (spam filters, reputation checks) continue operating exactly as they would without DMARC at all. The entire value at this stage is the reporting: aggregate reports flow to the rua address exactly as they would under a stricter policy, giving the domain owner a real, empirical picture of who is sending mail as their domain and whether it's authenticating correctly.

This is why p=none should never be skipped, even by a technically confident team that's sure they know every sending source. Aggregate reports consistently surface systems that weren't on anyone's list — an old marketing platform still configured months after a migration, a support tool a different department set up independently, occasionally infrastructure nobody currently at the organization even remembers provisioning.

p=quarantine: Consequence Without Finality

Moving to quarantine introduces actual enforcement for the first time. Mail failing DMARC is now marked as suspicious by the receiving system, which in practice usually means routing to a spam or junk folder rather than the primary inbox — though the exact handling is up to each receiver's own filtering logic, since DMARC specifies the policy request, not the implementation detail of how "quarantine" is displayed. The message isn't destroyed; a recipient checking their spam folder can still find and recover it, which is what makes this stage meaningfully less risky than reject while still providing real protection against casual spoofing attempts.

This is also the stage where the pct tag earns its keep. Rather than quarantining 100% of failing mail immediately, a cautious rollout applies quarantine to a small percentage first — pct=10 or pct=25 are common starting points — and raises it over successive weeks while continuing to watch aggregate reports for anything unexpected.

p=reject: Full Enforcement

At p=reject, mail failing DMARC alignment is refused at the SMTP protocol level — the receiving server declines to accept the message at all, and the sending server (if well-behaved) generates a bounce back to whoever attempted to send it. There's no spam folder safety net at this stage; a message that fails is simply never delivered anywhere the recipient can find it. This is the strongest protection DMARC offers and the appropriate end state for a domain that has verified, through weeks of clean aggregate reports, that every legitimate sending source passes.

The operational stakes of reaching reject prematurely are genuinely serious. An overlooked legitimate sender doesn't get flagged or delayed — its mail vanishes, often with no error visible to the team that configured it, only a quiet drop in some downstream metric (invoice emails not arriving, notification emails going unanswered) that can take a surprisingly long time to trace back to a DNS policy change.

Policy Comparison at a Glance

A Realistic Rollout Timeline

This timeline is illustrative, not universal — a simple domain with one email platform might move through it in half the time, while a large enterprise with dozens of decentralized sending sources can reasonably take several months. The pacing should be driven by what the reports actually show, not by a calendar target.

Use Cases Across Organization Types

What Rushing the Rollout Actually Costs

The cost of moving too fast through the policy tiers isn't hypothetical or abstract — it shows up as specific, traceable operational damage. Invoices that never arrive because a billing platform's mail was quietly rejected. Password reset emails that customers report as "not working" when they were actually blocked at the DMARC layer. A support ticketing system whose reply notifications stop reaching customers, discovered only when someone notices response rates dropping. Each of these is recoverable, but each also takes real time to diagnose precisely because the failure is silent — no error message points back to a DNS policy change from three weeks earlier. This is the practical argument for the conservative rollout pace described above: not caution for its own sake, but avoiding a specific, common, and frustratingly hard-to-trace category of incident.

Communicating a Policy Change Internally

Beyond the technical rollout, a policy change that could affect mail delivery deserves a brief internal heads-up before it happens, especially the move to p=reject. A short note to IT, customer support, and marketing teams — "we're tightening email authentication on [date]; if you notice unexpected delivery issues with a specific platform after this, check with [owner] before assuming it's unrelated" — turns a potential multi-day mystery into a five-minute diagnosis if something unexpected does surface. This is a small process step, but it's one of the more consistently underrated parts of a smooth DMARC rollout in any organization larger than a one-person operation.

Policy Decisions Aren't Always Permanent

It's worth normalizing the idea that a domain can move backward through the tiers temporarily without that being a failure of the rollout. If a significant new sending platform is added after a domain has already reached quarantine or reject, and its alignment hasn't yet been verified, deliberately stepping back to a lower pct — or briefly to none for that specific transition period — is a reasonable, controlled choice rather than an admission of a broken process. The tiers exist to be moved through safely in both directions as circumstances change, not just climbed once and left alone.

Policy Rollout for Newly Registered Domains

A brand-new domain, registered specifically for a new product or brand launch with no sending history at all, presents a different rollout calculus than an established domain accumulating years of sender sprawl. With no legacy senders to discover, a new domain can often move through the tiers considerably faster — sometimes reaching p=reject within days rather than months — provided every sending source is deliberately configured and verified from the start rather than organically accumulated over time the way established domains typically are.

Coordinating Policy Changes With Change Freezes

Organizations with formal change management processes — freeze periods around major sales events, product launches, or fiscal year-end — should treat DMARC policy changes as subject to the same coordination discipline as other infrastructure changes, particularly the move to quarantine or reject. Scheduling enforcement changes outside of business-critical periods, and avoiding stacking a policy change with other unrelated infrastructure work in the same window, keeps troubleshooting simple if something unexpected does surface.

Setting Internal Expectations for Rollout Duration

Communicating a realistic timeline upfront — to management, to other technical stakeholders — helps avoid pressure to skip stages for the sake of speed. Framing the rollout explicitly as "weeks of monitoring before any enforcement, followed by gradual, verified enforcement increases" sets an expectation that prevents the common but risky push to reach reject prematurely just to mark the project complete ahead of schedule.

Related Reading in This Series

For the conceptual foundation, start with What Is DMARC?. For the full tag syntax including pct and sp, see DMARC Record Explained. For how alignment actually determines pass/fail during this rollout, read DMARC Alignment. To check where your domain currently stands, open DMARC Lookup.