The DMARC pct tag is gone — what to do with your record

If you've ever set up DMARC from a tutorial, there's a decent chance your DNS record contains something like this:

v=DMARC1; p=quarantine; pct=50; rua=mailto:reports@example.com

That pct=50 was supposed to mean "apply my quarantine policy to half the failing mail" — a dimmer switch for rolling out enforcement gradually. As of RFC 9989, the Standards Track revision of DMARC published in 2026, the pct tag no longer exists. Here's why it was removed, what replaced it, and exactly what to do with a record that still carries it.

Why pct was removed

The uncomfortable truth, stated plainly in RFC 9989's own Appendix A.6: receivers didn't implement it. The spec's language is that the tag "was usually not accurately applied" unless the value was 0 or 100, and that behavior for intermediate values "varied widely from one implementation to another."

Think about what pct=30 asks a mailbox provider to do: roll a die for each failing message and enforce on 30% of them. Some receivers did something like that. Others rounded to all-or-nothing. The result was that a domain owner publishing pct=30 had no reliable idea what they'd actually deployed — the worst property a security control can have. A gradual rollout you can't measure isn't gradual; it's just uncertain.

The two values that did work reliably were the endpoints. pct=100 (the default) required no special handling. And pct=0 — logically "publish a policy but apply it to nothing" — took on a life of its own.

The strange afterlife of pct=0

pct=0 should have been pointless. In practice, mailing list software and forwarding intermediaries started treating it as a signal: this domain has an enforcement policy on paper but isn't enforcing yet, so apply the workarounds (like rewriting the From header) that an enforced domain needs.

That gave domain owners something genuinely useful: publish p=quarantine; pct=0, then compare your aggregate reports before and after. Mail flowing through intermediaries that don't rewrite the From header shows up as the failures that would have been quarantined for real. It was an inelegant measurement tool, but it was the only one of its kind, and the community valued it enough that DMARCbis preserved the capability while deleting the tag.

The replacement: t=y

RFC 9989 introduces the t tag — "t" for testing — with exactly two values:

No percentages, no dice-rolling, no pretending receivers will do arithmetic they never did. The honest two-state reality of the old tag, formalized.

What to do with your record

If your record says pct=100: delete the tag. 100 was already the default; the tag was decorative. Nothing about your enforcement changes.

If your record says pct=0: replace it with t=y. Same practical meaning, current syntax. Note the same caveat that applied to pct=0: your policy isn't protecting anything while it's in testing mode — it's a measurement configuration, and it should have an exit date.

If your record says anything in between — pct=25, pct=50, pct=90: this is the case worth pausing on, because the tag never reliably did what the number suggests. You published a dial; receivers saw a switch, and different receivers saw it thrown in different directions. Decide what you actually want — if the mail you see failing in reports is all illegitimate, go to the full policy with no pct; if you're not sure, drop back to explicit monitoring (p=none with rua=) and read a month of reports before deciding. That reading step is the part most rollouts skip, and it's the part the new spec now formally prescribes.

If you have no idea what your record says: check your domain — takes about fifteen seconds and grades the whole setup.

Do receivers still honor pct?

Yes, for now — and probably for years. The installed base of DMARC implementations was built against RFC 7489, and pct handling won't be ripped out of mail servers overnight. Nothing catastrophic happens to a record that still carries the tag: receivers that honor it behave as before, and receivers on the new spec treat it as an unknown tag, which DMARC has always required them to ignore.

So this isn't an emergency. It's housekeeping — but housekeeping with a deadline of "whenever receivers start dropping 7489 behaviors," which is not a date anyone will announce. A record that says what current receivers actually implement is strictly better than one that depends on legacy behavior, and the migration takes thirty seconds in your DNS panel.

The one-line takeaways

• pct is removed in RFC 9989; rf and ri went with it.
• pct=100 → delete the tag.
• pct=0 → replace with t=y.
• Anything in between was never reliable — pick a real policy, informed by your aggregate reports.
• Unknown tags are ignored by design, so none of this breaks anything today.

Want to see where your domain stands, pct and all? Run the free check — we'll read your live record and tell you, in plain language, what every tag is doing.