DMARC Policy: Quarantine vs Reject — Which to Choose in 2026

DMARC policy choice is where most teams introduce deliverability damage they didn’t intend. The wrong choice — typically jumping to reject too early — produces immediate placement collapse on legitimate mail. The right choice — staged migration from none to quarantine to (optionally) reject — produces gradual tightening with feedback at each step. This article covers what DMARC policies mean operationally in 2026, when each policy is appropriate, and the migration path that doesn’t break deliverability along the way. It pairs with the SPF setup guide, the DKIM setup guide, and the SPF/DKIM/DMARC overview.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together with an alignment check and a policy statement. The policy tells receiving servers what to do when authentication fails: nothing (none), send to spam (quarantine), or reject outright (reject). The choice has material consequences for deliverability and reputation, and most teams should not start at reject.

What DMARC actually does

A DMARC record is a TXT record at _dmarc.<yourdomain>. Example:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.com; pct=100; adkim=r; aspf=r

The pieces:

• v=DMARC1 — version
• p=none|quarantine|reject — the policy (what receiving servers do with failing mail)
• rua=mailto:... — where to send aggregate reports
• pct=100 — what percentage of failing mail the policy applies to (useful for staged rollouts)
• adkim=r|s — DKIM alignment mode (relaxed or strict)
• aspf=r|s — SPF alignment mode (relaxed or strict)

DMARC checks two things when mail arrives:

1. Authentication: Does SPF pass OR does DKIM pass?
2. Alignment: Does the SPF or DKIM domain match the From-address domain?

If both pass, DMARC passes. If both fail, DMARC fails — and the policy tells the receiving server what to do.

The three policy modes

p=none (monitoring mode). Receiving servers report on authentication results but don’t change mail handling. This is the starting point for every team. It produces aggregate reports (sent to the rua address) that show which sending sources are passing or failing authentication. The reports are the feedback mechanism that lets you fix authentication issues before tightening policy.

Duration in none: minimum 2–4 weeks, longer if the sending stack is complex. The goal is to confirm that 100% of legitimate mail is passing SPF or DKIM with proper alignment before moving on.

p=quarantine. Receiving servers send failing mail to spam/junk. The recipient can still find it but won’t see it in the inbox. This is the safe middle ground — failures are visibly demoted but not lost. Use this once monitoring data shows authentication is consistent.

Common rollout: start at p=quarantine; pct=10 (10% of failing mail is quarantined), gradually raise pct to 100 over 2–4 weeks. The pct mechanism lets you test impact on a small subset before full rollout.

p=reject. Receiving servers reject failing mail outright. The sender gets a bounce; the recipient never sees it. This is the strictest policy and produces the strongest anti-spoofing signal — but any authentication problem causes legitimate mail loss. Only use this when authentication is verified working at 100% across every sending source.

Most B2B teams in 2026 operate at p=quarantine rather than p=reject. Enterprise security teams and high-target brands (banks, government, large platforms) typically move to p=reject because the spoofing risk justifies the operational rigor.

The migration path

A safe DMARC migration looks like this:

Phase 1: SPF and DKIM verified working (week 0). Before adding DMARC, confirm that SPF and DKIM both pass for outgoing mail from every sending service. Use header inspection on test sends to verify dkim=pass and spf=pass results.

Phase 2: Add DMARC at p=none (week 1). Publish the DMARC record with p=none and a rua address that can receive XML reports. Most teams use a third-party service (Postmark’s DMARC monitoring, dmarcian, EasyDMARC, Valimail) to parse the reports — manually reading XML aggregate reports doesn’t scale.

Phase 3: Monitor for 2–4 weeks (weeks 2–5). Review the DMARC reports. The reports show:

• Which sending sources produced mail claiming to be from your domain
• Whether SPF and DKIM passed for each source
• Whether alignment held

Fix any authentication failures (typically: a sending service that wasn’t included in SPF, or a service signing with DKIM but not aligning to your domain).

Phase 4: Move to p=quarantine; pct=10 (week 6). Once reports show consistent authentication, start tightening. pct=10 means 10% of failing mail is quarantined — low-risk because most legitimate mail is now passing authentication, and the 10% sampling shows whether any falls through.

Phase 5: Raise pct gradually (weeks 7–9). Move to pct=25, then pct=50, then pct=100 over 2–3 weeks. At each step, monitor reports for any legitimate sending source that’s failing.

Phase 6 (optional): Move to p=reject; pct=10 and ramp. If your security posture requires it (financial services, government, brand-protection-critical sectors), repeat the pct-ramp for p=reject. For most B2B cold email senders, p=quarantine; pct=100 is the appropriate stopping point.

The whole migration takes 6–12 weeks done correctly. Teams that try to compress it produce mail loss; teams that skip phases entirely produce mail loss with no diagnostic visibility.

Alignment: the subtle part

DMARC requires that either SPF or DKIM not only pass but also align with the From-address domain. Alignment has two modes:

• Relaxed (adkim=r, aspf=r): the authenticated domain shares an organizational domain with the From-address. Example: From info@mail.company.com, DKIM signs with company.com — relaxed alignment passes because they share the company.com organizational domain.

• Strict (adkim=s, aspf=s): the authenticated domain must exactly match the From-address domain. Example above: From info@mail.company.com, DKIM with company.com — strict alignment fails because they don’t exactly match.

Relaxed is the default and works for most setups. Strict is used in high-security configurations where any subdomain variance should fail authentication.

The alignment problem most teams encounter: sending services that sign DKIM with their own domain (e.g., a generic SendGrid signing domain) rather than your domain. This produces DKIM pass + DKIM not-aligned, which DMARC treats as authentication failure. The fix is configuring the sending service to sign with your domain (sometimes called “custom DKIM” or “branded sending”).

Common DMARC policy mistakes

Starting at p=reject without monitoring. The single most damaging DMARC mistake. Without the monitoring phase, you don’t know which legitimate sources are failing authentication. p=reject causes those legitimate sources to bounce immediately. Production teams never start at reject.

Skipping the rua address. A DMARC record without rua doesn’t produce reports. Without reports, you have no feedback on authentication state. Always include rua pointing to an address you can monitor.

Ignoring DMARC reports for weeks. Reports arrive but no one reads them. By the time someone realizes there’s an authentication problem, several weeks of campaigns have run with failures. Production teams review DMARC reports weekly during migration, monthly steady-state.

Quarantine without ramp. Going from p=none to p=quarantine; pct=100 in one step skips the ramp that catches edge cases. The pct mechanism exists precisely to let you ramp safely.

Forgetting subdomains. A DMARC record on company.com doesn’t apply to mail.company.com by default. The sp= parameter sets policy for subdomains. Teams that publish DMARC on the apex domain but don’t set sp end up with subdomain mail bypassing the policy.

Not aligning DKIM with From-domain. When sending services sign with their domain, DKIM passes but doesn’t align — and DMARC treats this as failure. Always verify alignment, not just pass status, in DMARC reports.

Treating DMARC as a security feature only. DMARC has security benefits (anti-spoofing) and deliverability benefits (receiving systems trust mail from DMARC-published domains more). Most B2B teams adopt it for deliverability; the security benefit is a side effect.

DMARC policy choice in 2026 is a discipline-of-staging question, not a discipline-of-choosing-the-strictest question. The teams getting good deliverability outcomes use p=quarantine after careful migration. The teams getting deliverability disasters jump straight to p=reject without monitoring and watch legitimate mail bounce for weeks before they figure out why. For the full deliverability context, see the email deliverability guide.