RFC 9989 removes the DMARC pct tag, which applied a policy to only a percentage of failing mail. It adds a t tag with values y and n. Setting t=y asks receivers not to apply your policy and to treat failures one level lower: quarantine acts like none, and reject acts like quarantine.
Why pct went away
The RFC explains the reasoning plainly. Operational experience showed pct was usually not applied accurately unless the value was 0 or 100. Other values behaved differently from one implementation to another.
The two exact values were the useful ones. The default of 100 needed no special handling. A value of 0 took on a meaning of its own: some intermediaries and mailbox providers used it as a signal to do something extra, usually rewriting the From header to avoid DMARC failures downstream. That also helped domain owners, because aggregate reports could show how much of their mail passed through intermediaries that do not rewrite From.
Since only two values were meaningful, the authors replaced pct with a two-value tag.
How t works
t=nis the default. Apply the policy as written.t=yis a request not to apply the policy, while still applying any special handling. The domain owner expects failing mail to be handled one level below the stated policy.
The RFC spells out the mapping: with quarantine and t=y, failing messages get none. With reject and t=y, they get quarantine. The tag does not change report generation and has no effect when the policy is none.
Phasing in a policy now
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; t=y; rua=mailto:dmarc-reports@example.com"
This says: our target is reject, we are still testing, so treat failures as quarantine for now. Once reports show no legitimate failures, remove t=y.
Compared with pct, this is coarser. You cannot ask for 10 percent. You get a clear state: testing or not. A useful side effect is that the aggregate report records a policy override reason of policy_test_mode when a message was exempted because of testing mode, so you can see the effect in the data.
Practical advice
- If you published pct below 100, do not assume receivers will keep honouring it. Move to a stage plan using the p value and t.
- Do not leave t=y forever. It signals you are not confident in your own policy.
- Watch aggregate reports for override reasons so you know when receivers act on testing mode.
- If your DMARC tooling still generates pct values, check for an update.
Support will vary during the transition. I could not confirm which receivers already handle t, so verify with your reports rather than assuming.
Quick check
Can I still publish pct?
The RFC removes it from the tag list, and unknown tags must be ignored by processors following the new document. Older receivers may still read it. Prefer t going forward.
Sources
Last reviewed: 19 October 2026.
