Email authentication

DMARC pct= Rollout: Staged Enforcement in 30 Days [2026]

TL;DR: The pct= tag tells receivers what percentage of failing email to apply your policy to. It's how you safely ramp from p=quarantine to p=reject without flipping a switch and breaking everyone. The canonical ladder is 10 → 25 → 50 → 75 → 100, gated on alignment-rate evidence between each step. Plan on a 30-day rollout in the best case; expect to pause for two to four weeks at one of the rungs while a misaligned sender gets fixed.

What pct= actually does

The pct= tag is defined in RFC 7489 §6.3 as the percentage of messages from the sender's mail stream to which the DMARC policy is to be applied:

“Percentage of messages from the Domain Owner's mail stream to which the DMARC policy is to be applied. However, this MUST NOT be applied to the DMARC-generated reports, all of which must be sent and received unhindered.”

In plainer English: when you publish p=quarantine; pct=10, you're telling receivers “if a message from my domain fails DMARC alignment, quarantine 10% of them — and treat the other 90% as if my policy were p=none (just monitor and report).” The mechanism is sampling at the receiver. You don't choose which 10% — the receiver does, on a per-message basis.

A few details that get lost in the typical pct= explainer:

• pct= only modifies p=quarantine and p=reject. At p=none, it has no meaningful effect — there's no policy to apply to a fraction of. Most receivers ignore pct= at p=none gracefully; some validators flag it as a noop. Don't bother publishing pct= until you're at p=quarantine or higher.
• The remainder gets the next-weakest disposition. RFC 7489 §6.6.4: at p=reject; pct=10, 10% of failing mail is rejected and the other 90% is quarantined (not “treated as p=none”). At p=quarantine; pct=10, 10% is quarantined and the other 90% is treated as p=none. This matters when you ramp from full quarantine to staged reject.
• Receivers report what they actually did. Aggregate reports include both policy_published (what you said) and policy_evaluated (what the receiver applied, including the sampling outcome and any local override). When you read rua= reports during a staged ramp, you'll see both — that's how you measure whether the sample is doing what you expect.
• Default is pct=100. If you don't specify pct=, the receiver applies the policy to 100% of failing mail.

The whole point of pct= is to give you a sampling lever. Used well, it lets you observe a small slice of enforcement consequences in production before they land on 100% of failing mail. Used badly — set once and forgotten, or moved up the ladder without checking the evidence — it's just a misleading way to publish enforcement.

The canonical ladder (10/25/50/75/100)

Almost every DMARC vendor recommends a different pct= ladder. We've seen 1/10/50/100, 5/25/75/100, 10/50/100, and “just go straight to 100.” None of them are wrong in any strict sense — but the rungs aren't equally useful, and the right ladder is the one whose rungs actually tell you something between steps.

Our canonical ladder is 10 → 25 → 50 → 75 → 100.

p=quarantine; pct=10
   ↓  (≥7 days; alignment rate ≥ 99% on legitimate volume)
p=quarantine; pct=25
   ↓
p=quarantine; pct=50
   ↓
p=quarantine; pct=75
   ↓
p=quarantine; pct=100

Why each rung matters:

• pct=10 — enough sample to detect breakage, low enough customer impact. If a misaligned sender exists you haven't found yet, a 10% sample produces enough quarantined mail in your aggregate reports to surface it within a few days, and few enough to recover from without a customer complaint storm.
• pct=25 — confirmation. The same evidence you collected at 10% should hold at 25%. If alignment rate drops between rungs, that's a signal something changed mid-ramp.
• pct=50 — halfway gate. Half your failing volume is now being enforced. If you were going to discover a hidden sender via enforcement, you've discovered it by now.
• pct=75 — approaching parity. The remaining 25% sampled-out is small enough that the difference from pct=100 is mostly noise. A clean week here is the strongest pre-publish signal that pct=100 will be uneventful.
• pct=100 — full quarantine. Every failing message is dispositioned by the receiver. If you're going to advance from quarantine to reject, this is the rung you hold at while the evidence accumulates.

The rungs aren't sacred — what's sacred is the gating between them. We use this specific ladder because it's the Microsoft / RFC-recommended primitive cited in spike #11 and because it's locked as the canonical UX across the DMARCit product surface and our customer-facing pages. If you cherry-pick a different ladder, fine — but commit to it, gate it on evidence, and don't skip rungs.

Diagram 1 (designer flag): “DMARC pct= ladder” — horizontal staircase with five rungs (10, 25, 50, 75, 100), each rung annotated with the dwell-time gate and the alignment-rate threshold to advance.

The alignment-rate gate (the differentiator)

Most DMARC tools let you flip pct= on a calendar. You set a reminder for “advance to 25% next Monday,” and when Monday rolls around the tool surfaces a button. The tool doesn't check whether the evidence supports the advance. That's a policy-toggle workflow.

The right approach is alignment-evidence-gated: advance only when alignment rate clears a threshold over a configurable lookback window. Same destination, different rigor. (This is the same framing locked across /enforcement-readiness and the /compare/mimecast page — consistency is the point.)

What “alignment rate” means in practice: the percentage of legitimate volume from your domain in the lookback window where SPF or DKIM passed and aligned with the From: header domain, divided by the total legitimate volume. A typical advance threshold is 99% or higher [VERIFY 7] over a 7-day lookback window [VERIFY 8]. (See /enforcement-readiness for the readiness-evaluator UX that surfaces this.)

A few things to internalize about alignment rate as a gate:

• It's not real-time. DMARC aggregate reports arrive on a daily cadence at best. Receivers batch across a 24-hour window, and delivery can lag another day. Anyone selling “real-time alignment-rate dashboards” is overstating the input data. The honest framing is at-best next-day evidence — a lookback over discrete daily data, not a live signal.
• It's measured on legitimate volume only. Including unauthorized volume (spoofing, sources you've classified as “ignore”) in the denominator pushes the rate down for reasons unrelated to readiness. The DMARCit readiness evaluator excludes flagged-unauthorized sources from the gate; if you're computing this manually, do the same.
• It accounts for policy_evaluated overrides. If a receiver applied a local override (forwarded, mailing_list, local_policy, sampled_out) and didn't enforce, that's not a failure of your alignment. Strip overrides from the gate calculation, or you'll under-count alignment.
• One bad day shouldn't reset the clock. A flaky DKIM key on Tuesday that got fixed Wednesday isn't a reason to back off, but it should pause the advance until the next clean lookback window.

Most “stuck at p=none” stories reduce to one of two failures: the ramp had no gate, or it had a tool that toggled policy on a calendar with no evidence check. The cure in both cases is the same — make the evidence visible at every rung, and only advance when it clears.

Worked example: 30-day staged rollout

Here's a defensible 30-day rollout plan, assuming you've already completed sender inventory at p=none and SPF is healthy. (If you haven't, read /learn/p-quarantine-vs-p-reject first, and fix /learn/spf-permerror before you touch enforcement.)

That's the optimistic case. Real rollouts often pause for two to four weeks at one of the rungs while a misaligned sender gets fixed, or while a stakeholder team negotiates with a vendor whose DKIM signing is broken. A 30-day rollout that takes 60 days because you held at pct=50 for three weeks is a successful rollout. A 14-day rollout that finished on time but rolled back two weeks later because the gate was wrong is a failed rollout dressed in the costume of a fast one.

Diagram 2 (designer flag): “30-day rollout calendar” — horizontal timeline with the seven advance points (Day 0, 7, 14, 21, 28, 35) and the daily-report cadence underneath, showing where the gate is checked and where pauses commonly happen.

When to pause and back off

The whole point of staged rollout is that you can stop and reverse. Failure modes that justify pausing or backing off:

• Alignment rate drops mid-ramp. A previously-aligned sender broke — an ESP rotated DKIM keys without telling you, marketing migrated a vendor over the weekend, an internal flow got rerouted through a forwarder. Aggregate reports will show the drop within 24-48 hours. Back-off action: revert pct= to the previous rung (or pct=0 to disable enforcement entirely if the breakage is severe), publish, confirm via DNS poll, then investigate.
• A new sender appeared and isn't yet aligned. Sometime between rungs, a new sending source showed up — usually a vendor someone signed up for without telling IT. Hold at the current rung. Don't advance until the new source is either aligned or explicitly classified.
• Quarantine bounce-back complaints. A customer or internal user reports a legitimate email landed in spam. Shouldn't happen if your alignment rate is genuinely above 99%, but the long tail is real. More than a couple per week: drop back a rung and investigate.
• Aggregate reports stop arriving. If rua= mail stops, you've lost the gate. Fix the report flow before you advance.

The back-off sequence is the same in every case: revert the pct= value, confirm via DNS, investigate, fix or classify, then re-advance from where you were (not from pct=10 — you don't lose all your evidence by backing off one rung).

Revert isn't free. DNS caching and report delays mean the revert doesn't take effect instantly at all receivers. Plan on a 24-48 hour window. If the breakage needs to be gone now, that's an argument for pct=0 or a temporary p=none republish — not a reason to skip the revert.

The DMARCit approach

Most DMARC tools treat the pct= ladder as a calendar event: pick a date, click a button, the record updates. That's a policy-toggle workflow. We think it's the wrong shape — the ladder isn't the hard part, the gate is.

DMARCit's enforcement-readiness flow is alignment-evidence-gated, not policy-toggle. The product surface tracks each sending source on your domain, lets you mark it legitimate, unauthorized, forwarded, or needs-review, computes alignment rate over a configurable lookback window with overrides excluded, and gates the advance CTA on the rate clearing the threshold for the configured dwell time. The CTA isn't “advance to pct=25 because Monday.” It's “alignment rate is 99.4% over the last 7 days; advance to pct=25 is unblocked” — or, more often, “alignment rate dipped to 97.8% on Tuesday; advance is blocked, here's the source that broke.”

We don't auto-write your DNS. The tool generates the new TXT record value for you to apply yourself, with the rollback value pre-computed and visible alongside it. Existing rua=, ruf=, and sp= tags are preserved in the diff (losing them is a customer incident, and we won't risk it). After you publish, we poll DNS to confirm the change landed and warn about the report-lag window before you check the next gate.

We automate the mechanics. You still own the call to advance. That's the honest framing — alignment-evidence-gated isn't enforcement-by-autopilot. It's a tool that surfaces the evidence and the rollback in the same place as the advance CTA, so the decision is informed.

For the full guided walkthrough — the staged-quarantine UX with source-marking and the pct ladder integrated with alignment-rate evidence at each step — see /enforcement-readiness. For pricing, /pricing.

Common pct= pitfalls

The most common mistakes we see:

• Setting pct= at p=none. No meaningful effect — receivers ignore it gracefully and validators flag it as a noop. Drop the pct= tag while you're at p=none; only add it once you're publishing p=quarantine or higher.
• Advancing too fast. Skipping the alignment-rate gate is the version of “moving fast” that ends in a customer-incident retrospective. If you advance on a calendar and not on evidence, you've published the rung but not earned it.
• Forgetting to advance. The operator publishes p=quarantine; pct=10 to satisfy an auditor and then never moves it. Six months later the record still says pct=10 and 90% of failing mail is being treated as p=none. That's not enforcement; that's enforcement cosplay. Set a calendar reminder plus an evidence gate.
• Interaction with subdomain policies. pct= applies to the org-domain policy. The subdomain's effective policy is whatever sp= says (or p= if sp= is absent). If you want staged rollout for subdomains, think about it explicitly. (See /learn/dmarc-subdomain-sp-tag (coming soon).)
• Misunderstanding what the receiver does with the remainder. At p=reject; pct=10, the 90% sampled-out is quarantined, not treated as p=none. RFC 7489 §6.6.4 has the receipt.
• Treating pct= as a long-term posture. It's a ramp, not a destination. Holding at pct=50 indefinitely means the gate isn't being checked or it's broken. Either advance to 100 or back off to a defensible rung.

The path from pct=100 to p=reject

p=quarantine; pct=100 is not the same as p=reject. Quarantine sends failing mail to spam; reject bounces it. The mail still gets to the recipient at quarantine — it might rot in junk, but a determined human can rescue it. At reject, the mail is gone, and the only artifact is a bounce notification at the sender.

The path from pct=100 quarantine to p=reject looks like:

1. Hold at p=quarantine; pct=100 for at least the configured lookback window (typically 7-14 days). Alignment rate ≥ 99% on legitimate volume, no new unclassified sources, no overrides driving the rate down.
2. Publish p=reject; pct=10 (preserving all other tags). DNS poll confirms.
3. Walk the same ladder you walked for quarantine: 10 → 25 → 50 → 75 → 100, gated on the same alignment-rate evidence.
4. At p=reject; pct=100, you're done. Maintenance mode is monitoring rua= for drift and watching for new senders that need to be aligned or classified.

For the full quarantine-vs-reject framing — when reject is the right end-state and when quarantine forever is fine — see /learn/p-quarantine-vs-p-reject. The short version: if you're a phishing target, a bulk sender meeting Gmail/Yahoo 2024 requirements, or under a regulatory regime that names p=reject explicitly, finish the ladder. Otherwise, p=quarantine; pct=100 is a defensible end-state for many domains.

What to do next

If you're planning a staged DMARC rollout:

1. Check that your SPF is healthy (no permerror, no temperror, lookup count well under 10). Run a free SPF check before you publish enforcement.
2. Confirm you have at least 30 days of rua= aggregate reports and a complete sender inventory. (See /learn/dmarc-monitoring for the signal set.)
3. Read /learn/p-quarantine-vs-p-reject for the policy-value framing if you haven't.
4. Publish p=quarantine; pct=10. Walk the canonical 10 → 25 → 50 → 75 → 100 ladder, gated on alignment rate ≥ 99% over a 7-day lookback.
5. Hold at p=quarantine; pct=100 for at least the configured lookback window before considering p=reject.