DMARC Policy: Quarantine vs Reject (When to Advance)

DMARC tells receiving servers what to do with mail that fails SPF and DKIM alignment for your domain. The hard part is not publishing the record — it is choosing when to tighten the policy from observation to enforcement without blackholing legitimate mail you forgot about.

This guide walks the p=none → p=quarantine → p=reject path, explains what each policy actually triggers at Gmail, Yahoo, and Microsoft, and gives you the concrete signals that say "advance" or "hold".

DMARC quarantine vs reject at the receiving server

DMARC (RFC 7489) defines three policy values for the p= tag in your _dmarc TXT record. Receivers honor them differently, but the intent is fixed:

• p=none — Take no action based on DMARC. Send aggregate (rua) and, optionally, failure (ruf) reports. The receiver still applies its own spam filters.
• p=quarantine — Treat failing mail as suspicious. In practice, most large receivers route it to the spam or junk folder. Gmail may also throttle the sending IP.
• p=reject — Refuse failing mail at SMTP time with a 5xx, or silently drop after acceptance. The message never reaches the recipient, not even the spam folder.

The choice between p=quarantine and p=reject is the choice between "the user has a chance to fish a misclassified message out of spam" and "the message is gone." That difference matters for password resets, signed contracts, and shipping notifications.

Note that receivers are not bound to your policy verbatim. Gmail has historically applied a softer interpretation of p=quarantine for low-volume senders and a stricter interpretation of p=reject once a domain crosses the Bulk Sender threshold.

A real DMARC record at each stage

A monitoring record looks like this:

_dmarc.example.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-forensics@example.com; fo=1; adkim=r; aspf=r"

After 30 days of clean reports, you advance to quarantine with a partial rollout:

_dmarc.example.com.  IN TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com; sp=quarantine; adkim=r; aspf=r"

And once you have proof that all legitimate streams align, the final state:

_dmarc.example.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; sp=reject; adkim=s; aspf=s"

Note the adkim=s and aspf=s at the end — strict alignment is reasonable only after you have audited every sender and confirmed each one uses your exact domain in the visible From header, not just an organizational parent.

Read aggregate reports before changing anything

rua reports are XML files that mailbox providers send daily, summarizing every message they saw claiming to be from your domain. Each report row tells you:

• The source IP that sent the message.
• The result of SPF and DKIM checks.
• Whether each result aligned with the visible From domain.
• The disposition the receiver applied.

Forward rua= to a parser — Postmark's, Dmarcian's, or your own — because raw XML is not human-readable at volume. What you are looking for, before tightening anything, is two answers:

1. Which IPs and domains are sending mail "as you" that you do not control? Those are spoofers, and DMARC enforcement is meant to stop them.
2. Which IPs and domains are sending mail "as you" that you do control but that are failing alignment? Those are the false positives that will break if you move to p=reject.

The second list is the one that bites teams. Common culprits: a billing platform sending invoices via its own SPF domain, a hiring tool sending interview confirmations, a marketing platform that signs with its own d= value, a transactional provider that has not been DKIM-aligned to your domain. Each one must be fixed (custom DKIM, MAIL FROM alignment, or a subdomain delegation) before you advance.

The pct= rollout knob

The pct= tag is the percentage of failing messages the receiver should apply the policy to. The rest are treated as if your policy were one step softer. So p=quarantine; pct=25 means: of failing messages, 25% go to spam, 75% are treated as if p=none.

pct= lets you turn the dial gradually instead of cutting traffic in half overnight. Start at pct=10 or pct=25, watch your bounce and complaint rates and your aggregate reports for a week, then step up. Receivers select which messages to apply the policy to pseudo-randomly per recipient, so the impact is statistically smooth.

Two cautions. First, Gmail and a few others ignore pct= for p=reject and treat any non-100 value as p=quarantine instead. So pct= is most useful during the quarantine phase. Second, when you finally cut over to full enforcement, drop pct= from the record entirely — the default is 100 and explicit is clearer.

Subdomain policy with sp=

The sp= tag sets the policy for subdomains of the domain in the record. If you publish DMARC on example.com and do not set sp=, the policy inherits to every subdomain.

This matters in two cases:

• You have a marketing subdomain (news.example.com) that uses a different ESP and is not yet aligned. Set sp=none while you fix it, so your apex policy can advance without breaking the subdomain.
• You only send transactional mail from a dedicated subdomain (mail.example.com) and never from the apex. Publish DMARC on the subdomain at p=reject and on the apex with p=reject; sp=reject to block spoofing of both.

The mistake to avoid is publishing p=reject on the apex with no sp= while a subdomain is still misaligned. Inheritance will kill that subdomain's mail.

A staged rollout plan

Treat this as a four-stage rollout, not a binary on/off switch. Each stage gates on report data, not on the calendar — but the calendar below is a realistic minimum.

Week 1–2: monitoring

Publish v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain; fo=1. Confirm reports arrive within 24–48 hours. Identify every sending source. Fix any unaligned source you own.

Week 3–4: low-percentage quarantine

Switch to p=quarantine; pct=10. Watch your support inbox for "I did not get the email" reports. Check aggregate reports for a meaningful drop in failing volume from spoofers but no new failures from your own infrastructure.

Week 5–6: ramp quarantine to 100%

Step pct= to 25, then 50, then 100, in roughly weekly increments. If failures from your own senders reappear in rua reports at any step, hold and fix before advancing.

Week 7+: cut over to reject

Once 100% quarantine has been steady for at least two weeks with no surprise unaligned legitimate senders, switch the apex to p=reject and drop pct=. If you operate subdomains, advance sp= on the same schedule.

The whole sequence is usually 6 to 10 weeks. Going faster is rarely worth the risk of losing receipt or password-reset traffic to drops you cannot recover.

Why this matters for Gmail and Yahoo bulk senders

Gmail and Yahoo's 2024 Bulk Sender requirements now require DMARC enforcement (p=quarantine or p=reject) on the organizational domain of any sender exceeding 5,000 messages per day to Gmail or Yahoo recipients. p=none no longer satisfies them at scale, and they will reject or rate-limit non-compliant senders.

If your transactional volume is approaching that line, the work above is not optional — it is a deliverability requirement. Practical implication: most teams should plan to be at p=quarantine minimum, with pct=100, before they expect to cross the 5,000-recipient threshold consistently.

Signals you are not ready to advance

Hold the policy where it is — or roll back — if any of the following are true.

• Unaligned legitimate senders still appearing in rua reports. Every row that you recognize as your own traffic but that shows dkim=fail and spf=fail alignment is a future blackholed message. Fix the source before moving on.
• Low pct= exposure. A clean week at pct=10 does not prove you survive at pct=100. The legitimate sources you missed are statistically unlikely to show up until you ramp.
• Forwarders breaking SPF. Mail forwarded by a recipient's mailbox provider often loses SPF alignment. DKIM should still survive forwarding, but if your messages depend on SPF alone for alignment, mailing-list and forward traffic will fail under enforcement. Add DKIM signing before advancing.
• Mailing-list traffic. Discussion lists that rewrite the Subject: or From: header break DKIM signatures. If your domain is used to post to lists, you will get DMARC failures every time. Either move list-posting to a subdomain with sp=none, or accept the breakage and warn your users.

Advancement is a one-way ratchet only in the sense that rolling back signals weakness to receivers. You can always temporarily move from p=reject to p=quarantine while you debug — DNS changes propagate in minutes, and a one-day rollback is much cheaper than a week of dropped password resets.