DMARC pct Tag: Phasing In Enforcement Gradually

VigilDog Team · October 10, 2026 · 6 min read

Flipping DMARC straight to p=reject on a busy domain is how you find out about that forgotten billing system nobody documented, the hard way, when its mail vanishes. The pct tag exists precisely so you don't have to make that jump all at once. Used well, it turns enforcement into a dial you turn a quarter at a time while you watch what breaks.

What the DMARC pct tag actually does

The pct tag tells receiving mail servers what percentage of messages that fail DMARC should have your published policy applied to them. It takes an integer from 1 to 100, and if you omit it the default is 100, every failing message gets the full treatment. So v=DMARC1; p=quarantine; pct=25; rua=mailto:reports@example.com means: of all mail claiming to be from example.com that fails DMARC, quarantine a random 25%.

The critical detail most guides skip is what happens to the other 75%. Receivers don't ignore it, they apply the next-weaker policy instead. So with p=quarantine and pct=25, the unselected 75% is treated as p=none (delivered, but still reported). With p=reject and pct=25, the unselected 75% is quarantined rather than delivered. Enforcement steps down one level for the portion pct doesn't cover, which is exactly what makes it a safe throttle.

The mechanism, one level at a time

Because unselected mail falls back to the next-lower disposition, pct only has meaning when your policy is quarantine or reject. Setting pct on p=none does nothing, none already takes no action, so there's no weaker policy to fall back to. If you're still in monitoring, the pct tag is inert; it only starts biting once you move to quarantine.

This is why you always reach enforcement in two dimensions, not one: first the policy level (none → quarantine → reject), then the percentage within that level. The diagram below shows where DMARC evaluation sits relative to SPF and DKIM, pct acts on the outcome of that final DMARC pass/fail decision.

Senderyour domainSPFauthorised IP?DKIMsignature valid?AlignmentFrom matches?DMARC policynone / quarantine / rejectInbox
How SPF, DKIM and DMARC verify an email

A staged rollout schedule you can actually follow

Spend real time at p=none first, reading aggregate reports until you can name every legitimate sender, your ESP, your CRM, invoicing, help desk, and whatever marketing spun up last quarter. Only once SPF and DKIM align for all of them should you touch pct. If your records aren't clean yet, fix alignment first using our SPF, DKIM and DMARC guide.

  • Weeks 1-3, p=none, no pct. Pure monitoring. Confirm every legit source aligns.
  • Week 4, p=quarantine; pct=25. A quarter of failing mail goes to spam folders.
  • Week 6, p=quarantine; pct=50, then 75, watching report volume and support tickets.
  • Week 8, p=quarantine; pct=100. Full quarantine before you ever say the word reject.
  • Week 10, p=reject; pct=25, then step 50 → 75 → 100 over the following weeks.
  • Hold a level longer, or roll back a step, the moment reports show a legit source failing.

An honest caveat: pct is on its way out

The DMARCbis work at the IETF, the update meant to replace the original RFC 7489, removes the pct tag entirely. The authors found the partial-enforcement behavior confusing and inconsistently implemented, and the replacement guidance is simply to use p=quarantine as the intermediate step before p=reject, rather than a percentage dial.

For now, in early 2026, the major receivers (Google, Microsoft, Yahoo) still honor pct under the existing spec, so it remains a useful rollout tool today. But write your plan so it survives pct's removal: treat the quarantine level itself as your primary safety stage, and lean on pct as a finer sub-throttle rather than the whole strategy. That way, when you drop pct, your rollout barely changes.

Watch the reports, not the calendar

Every pct increase is a hypothesis: "another slice of failing mail is safe to punish." The only thing that confirms or refutes it is your aggregate (rua) reports. Before each step, check that failing volume is genuinely spoofing and not a real sender you missed, a quick pass through a DMARC record checker confirms your syntax is valid before you publish each change.

This is the part teams quietly drop after week two, and it's the part that matters most. VigilDog's email deliverability monitoring parses your DMARC aggregate reports continuously and flags a new failing source the day it appears, so a misconfigured sender surfaces as an alert while you're still at 25%, not as a bounced invoice after you hit reject.

Questions

Frequently asked

What does pct=100 mean in a DMARC record?

It means your policy applies to 100% of messages that fail DMARC, the full-enforcement default. Since 100 is the default value, `p=reject` and `p=reject; pct=100` behave identically.

Does the pct tag work with p=none?

No. With p=none there's no action to apply and no weaker policy to fall back to, so pct has no effect. It only becomes meaningful at p=quarantine or p=reject.

Is the DMARC pct tag being deprecated?

Yes, the DMARCbis revision removes pct in favor of using p=quarantine as the stepping stone to p=reject. Major receivers still honor it today, but build your rollout so it survives the tag's eventual removal.

Turn the enforcement dial with a safety net

VigilDog reads your DMARC aggregate reports and alerts you the moment a legitimate sender starts failing, so every pct increase is a decision, not a gamble.

Your first domain is free forever