A DMARC record reading p=quarantine; pct=10 used to mean "quarantine one in ten failing messages". As of May 2026 it means quarantine all of them.
Nothing about the record changed. Nobody edited DNS. The tag that made it a tenth was deleted from the standard, and a deleted tag is an ignored tag — so the policy that was being applied to a tenth of the mail is now applied to all of it.
What actually happened
RFC 9989, published in May 2026, obsoletes RFC 7489 and RFC 9091. Three tags did not survive the rewrite, and the specification lists them plainly:
"pct: Tag requesting application of the DMARC policy to only a percentage of messages. … rf: Tag specifying requested format of failure reports. … ri: Tag specifying requested interval between aggregate reports."
A deleted tag only matters because of the parsing rule in the same document:
"Only tags defined in that registry are to be processed; unknown tags MUST be ignored."
IANA's DMARC tag registry now lists pct, rf and ri with the status historic, which the RFC defines as "the tag is considered deprecated and is not expected to be in use in any current implementation".
A receiver reads your record, finds no pct in the current registry, and ignores it as required. It then applies your p policy to everything. The instruction did not fail; it was never read.
What the tag used to do
RFC 7489 was explicit, and the wording is worth having in front of you because it is the behaviour being withdrawn:
"If the 'pct' tag is present in the policy record, the Mail Receiver MUST NOT enact the requested policy … on more than the stated percent of the totality of affected messages."
That was the staged-rollout mechanism. You published p=quarantine; pct=10, watched a tenth of your failing mail get quarantined, discovered which of your own senders you had forgotten about, and turned the dial up. Almost every DMARC deployment guide written in the last decade recommends exactly that.
Why it was removed, in the working group's own words
This is not an oversight, and the specification says so:
"Operational experience showed that the 'pct' tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another."
⚠️ The working group's reason changes what the reader should conclude. The tag was already unreliable. A domain sitting on pct=10 was not getting a dependable 10% — it was getting whatever each receiver happened to implement. The deletion did not break a working mechanism; it retired one that had been quietly not working, and replaced ambiguity with a defined outcome.
The replacement does not replace it
RFC 9989 adds a test-mode tag, t. Setting t=y asks the receiver to apply a softer policy than the one you published: quarantine becomes none, reject becomes quarantine.
That is a useful test mode, but it is not a percentage-based rollout. For anyone parked at p=quarantine; pct=10, the two states now available sit on either side of where they were:
| Record | Share of failing mail quarantined |
|---|---|
p=quarantine; pct=10 under the old RFC | about 10% |
p=quarantine; t=y | 0% — policy none is applied |
p=quarantine | 100% |
Neither reproduces a partial rollout, because partial rollout is the thing the working group decided could not be done reliably. Whoever was using the dial has to choose an end of it.
How many are still parked there
We queried the DMARC records of 23 Malaysian federal government domains. 21 publish a DMARC record at all, and 12 of those carry pct=10:
| Measured, 4 September 2026 | Count |
|---|---|
| Domains queried | 23 |
| Publishing any DMARC record | 21 |
Carrying a fractional pct | 12, all at pct=10 |
| Reporting to the same shared address | 14 |
These are not twelve independent decisions. Fourteen of the records send their aggregate reports to one mailbox at the shared government mail platform, mygovuc.gov.my, and the twelve fractional records are otherwise near-identical in policy, subdomain policy and reporting addresses. That points to a single template, deployed widely, carrying one tag that changed meaning underneath it.
⚠️ One of the twelve is pdp.gov.my — the Personal Data Protection Department, the regulator whose breach-notification circular we wrote about last week. That is not a criticism of them specifically. It is the clearest possible illustration that this is a template problem rather than a competence problem: the same record is on the transport ministry, the treasury, the immigration department and the education ministry.
What this does not mean
It does not mean anything is broken or insecure. Enforcement going from 10% to 100% is enforcement going up. If those twelve domains have their sending infrastructure correctly aligned, the change is invisible and beneficial.
It does not mean the receivers are misbehaving either. They are doing exactly what the current standard tells them to do, and the old behaviour was the unreliable one.
The risk is narrower: surprise. A domain publishes pct=10 precisely because it is not confident its own senders are aligned. That is what a staged rollout is for. Those are the domains for which quiet promotion to full enforcement means legitimate mail starting to disappear into quarantine, with no change on their side to point at.
What to do about it
Check your own record. It takes one command and there is no ambiguity in the answer:
dig +short TXT _dmarc.example.comIf the reply contains pct= with any value below 100, you are relying on a tag that no longer exists. You have two honest options and no third one: remove it and accept full enforcement, or add t=y and accept none of it while you finish aligning your senders. Pick deliberately, because the standard has already picked for you.
If you are checking somebody else's domain — a supplier, a bank, a ministry — the same command works, and a fractional pct tells you they set up DMARC and have not revisited it since. Our DMARC, SPF and DKIM checker reads the same record if you would rather not use a terminal, and our DNS lookup shows the raw TXT reply.
Where this comes from, and what will date it
The removal, the parsing rule, the working group's stated reason and the definition of "historic" are all quoted from RFC 9989 itself. The withdrawn behaviour is quoted from RFC 7489 §6.6.4. The tag statuses were read from IANA's DMARC tag registry.
The Malaysian figures are ours: 23 federal government domains queried by DNS on 4 September 2026, counted here rather than taken from anyone's report. ⚠️ Two limits on that number. It is a sample we chose, not a census of Malaysian government mail, so it supports "this is widespread on a shared platform" and not a national percentage. And a DMARC record tells you what a domain asks receivers to do; we have not measured what any receiver actually does, which for a tag this recently retired will vary while implementations catch up.
The specification will not change back — tags do not return from historic. What will date this is the records themselves: as the twelve are cleaned up, the finding becomes history, which is the outcome worth wanting. The durable lesson is that a configuration file can change meaning without being edited, and your monitoring will not mention it.
View author profile → · Editorial policy
