Your DMARC record still has pct. RFC 9989 removed it.

RFC 9989, published in May 2026, lists pct, rf and ri among the tags removed from DMARC. For pct it names a successor: the t tag, whose values y and n are the analogues of pct=0 and pct=100. Values in between have no analogue. This page shows how to find the three tags in your record and what to change.

Measured 2026-09-24: 616 of 1,687 Y Combinator B2B companies with one readable DMARC record (36.5%) still carried at least one of the three tags: pct 602, ri 133, rf 36. One list, one day, DNS only, so this is not an internet-wide rate. Method and every count: How 1,939 Y Combinator B2B startups set up DMARC.

How to check your record

Read the record
```
dig +short TXT _dmarc.example.com
```
List any of the three removed tags; no output means none are present
```
dig +short TXT _dmarc.example.com | grep -oE '(pct|rf|ri)=[^;"]*'
```

Check your DMARC record Reads your live record and shows the policy it publishes and your reporting setup.

What to change

pct=0: replace it with t=y.
pct=100: delete it. Appendix A.6 treats t=n as its analogue, so you may write t=n instead if you want the intent visible.
Any value from 1 to 99: RFC 9989 has no analogue. Choose t=y, or delete the tag and let the published policy stand.
rf and ri: delete them.

Before: pct=100 and ri, both removed tags

v=DMARC1; p=quarantine; pct=100; ri=86400; rua=mailto:dmarc@example.com

After: the same policy, without the removed tags

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

Before: pct=0, used as a test switch

v=DMARC1; p=reject; pct=0; rua=mailto:dmarc@example.com

After: the t tag in its place

v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.com

What can break: deleting a value between 1 and 99 from an enforcing record asks receivers to apply your published policy to all failing mail, not a share of it. If you are not sure every legitimate sender is aligned, use t=y first and read your aggregate reports.

What the standard says

RFC 9989 Appendix C.5.2, "Tags Removed":

pct: Tag requesting application of the DMARC policy to only a percentage of messages. See Appendix A.6 for discussion.

rf: Tag specifying requested format of failure reports.

Section 9.3 marks all three "historic" in the IANA registry of DMARC tags, which it defines as:

the tag is considered deprecated and is not expected to be in use in any current implementation

Appendix A.6 explains why pct went:

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.

and what replaces it:

This version of the DMARC mechanism, therefore, introduces the "t" tag as shorthand for "testing", with the valid values of "y" and "n", which are meant to be analogous in their application by mailbox providers and intermediaries to the "pct" tag values "0" and "100", respectively.

Is pct still part of DMARC?

No. RFC 9989 Appendix C.5.2 lists pct, rf and ri as removed, and section 9.3 marks all three historic in the IANA registry of DMARC tags.

What replaces pct=0?

The t tag with the value y. RFC 9989 Appendix A.6 describes t=y and t=n as the analogues of pct=0 and pct=100.

What about pct=50 or any value between 1 and 99?

RFC 9989 has no analogue for them. Appendix A.6 says values other than 0 and 100 were usually not applied accurately. Choose t=y, or remove the tag and let the published policy stand.

How common are these tags now?

In our 24 September 2026 scan, 616 of 1,687 Y Combinator B2B companies with one readable DMARC record (36.5%) still carried at least one of pct, rf or ri.

What we do not claim

We report what your DNS publishes and what RFC 9989 says. We do not state what any particular mailbox provider does with a record that still carries these tags: those decisions are theirs, they are not published, and we cannot measure them from here.

Reviewed by Venkat Nookala, last reviewed 2026-09-24.