Introduction
For most of DMARC's first decade, the pct tag was a fixture of every rollout playbook. Administrators moving a domain toward enforcement would publish a policy of quarantine or reject alongside pct=10, then pct=25, then pct=50, on the theory that receivers would apply the policy to only that share of failing mail while the rest was treated as none. It felt like a safety valve — a way to dip a toe into enforcement without committing.
DMARCbis, published in May 2026 as RFC 9989, removes the pct tag entirely, along with rf and ri. Enforcement is now all-or-nothing: a policy is applied at full strength or not at all. For MSPs, this is less a loss than a clarification, because percentage-based enforcement was never the disciplined rollout method it was often treated as. This article explains what changed, why the change is sound, and what a safer staged rollout looks like without pct. It complements the DMARC for MSPs pillar.
Why this matters for MSPs
If your rollout runbooks, onboarding scripts or client proposals mention "staging with pct," they now describe a mechanism that no longer exists in the standard. A record carrying pct=25 does not become invalid overnight — receivers implementing DMARCbis simply ignore the tag — but the practical effect is important: the enforcement level jumps to whatever p= says, applied to all failing mail, not a quarter of it. A client you believed was gently staged at 25 percent is, to a modern receiver, fully enforcing. Understanding that shift is the difference between a controlled transition and an unexpected delivery incident.
What pct did, and why it was always a blunt instrument
The idea behind pct was probabilistic sampling. A receiver evaluating failing mail would, in effect, roll dice and apply the published policy to the configured percentage of messages, downgrading the rest to none. In theory this let a small fraction of failures get quarantined or rejected while the administrator watched the reports.
In practice it had well-known weaknesses. The sampling was decided independently by each receiver, so the effective enforcement varied from one mailbox provider to another and was never as precise as the number implied. It also entangled two separate ideas — how strict the policy is and how far along the rollout is — inside a single record, which made reports harder to interpret. When a failing message was delivered anyway, you could not always tell whether the sender had been treated as none because it fell outside the percentage or because something else was going on. Worst of all, a low percentage created a false sense of safety: pct=10 on a domain with an unknown sender inventory does not make enforcement safe, it just means one failing message in ten from a legitimate-but-unauthenticated sender gets quarantined instead of all of them. The underlying problem — senders that are not authenticating correctly — is still there.
What DMARCbis changed
RFC 9989 makes the model explicit and simpler. There is no percentage. A policy of quarantine or reject means that policy, applied to all failing mail. The rollout signal that remains is the new t tag: t=y marks a record as being in a testing or transitional state, which is an honest declaration of intent rather than a probabilistic dial. Alongside pct, the rarely implemented rf (report format) tag and the widely ignored ri (report interval) tag were also removed, trimming the specification down to the parts receivers actually honour. The three tags that arrived in their place — np, psd and t — are covered in new DMARC tags explained.
Why percentages were never a substitute for analysis
The deeper lesson is that a safe move to enforcement was never really about the percentage. It was, and still is, about knowing your senders. A domain is ready for p=reject when you can account for every source that legitimately sends on its behalf, when those sources produce aligned SPF or aligned DKIM results, and when your aggregate reports show a clean, well-understood picture rather than a stream of unexplained failures. When those conditions are met, moving to enforcement is low-risk whether you do it at 10 percent or 100. When they are not met, no percentage makes it safe — it only changes how many legitimate messages you disrupt while the real problem goes unaddressed.
Percentage-based staging, in other words, was a way of managing the blast radius of an incomplete rollout, not a way of completing the rollout. DMARCbis simply removes the illusion and points everyone at the work that actually matters.
A better rollout model without pct
The rollout that MSPs should standardize on is driven by evidence, not by a dial, and it moves through the policy levels in sequence.
- Begin at
p=noneand collect aggregate reports until you have a confident, complete inventory of every sending source, including marketing platforms, ticketing systems, billing services and anything else that mails as the client. - Bring each source into alignment by fixing SPF includes and DKIM signing until legitimate mail reliably produces an aligned pass, and confirm that alignment quality is stable over time rather than intermittent.
- Move to
p=quarantineonce the reports show that legitimate mail is authenticating and only unknown or unwanted sources are failing, usingt=yif you want to signal that you are still in a transitional window. - Advance to
p=rejectwhen quarantine has run cleanly, then remove anyt=ytesting signal so the record states your true, settled intent.
Each step is gated by what the reports show, and each step is reversible if something unexpected appears. That is a genuinely controlled rollout, and it is more defensible to a client than any percentage ever was. The mechanics of moving through the levels safely are covered in DMARC enforcement after RFC 9989.
What to do with records that still carry pct
Because a pct value is now ignored rather than rejected, a client record that still reads p=quarantine; pct=25 remains syntactically valid and keeps functioning — but its real-world effect has changed, because modern receivers apply the quarantine policy to all failing mail rather than a quarter of it. Treat every such record as a review item, not an emergency. Decide, per domain, whether the intended state is full enforcement, in which case you simply remove the now-inert pct tag, or continued monitoring, in which case you step the policy back to p=none and finish authenticating senders before advancing again. Either way, the record should end up stating exactly what you mean, with no leftover tag implying a partial rollout that receivers no longer honour.
The client conversation
This change also sharpens how MSPs should sell and describe the work. It is tempting to promise a client that you will "just set pct=10 and see how it goes," because it sounds cautious and cheap. That promise was always thin, and DMARCbis makes it untenable. The honest and more valuable offer is different: you will build a real inventory of the client's senders, bring each one into SPF and DKIM alignment, watch the reports until the picture is clean, and then move the domain to enforcement in controlled steps. That is a service worth paying for, and it produces a domain that is genuinely protected rather than one that merely looks staged. When you rebuild a client's record for this workflow, the DMARC generator produces clean, pct-free records aligned to the current standard.
Related articles
- DMARC for MSPs — complete guide
- DMARC enforcement after RFC 9989: p=reject still requires care
- New DMARC tags explained: np, psd and t
Authoritative references
- RFC 9989 — core DMARC protocol, which removes pct, rf and ri
- IANA DMARC parameters registry — the authoritative, current tag list
- RFC 7489 — the obsoleted 2015 specification that defined pct
Author: DMARC AI editorial team Last updated: August 2026