DMARC has a new RFC — and pct is gone

RFC 9989, published in May 2026, is the current DMARC specification. It obsoletes RFC 7489 (the long-standing Informational DMARC document) and RFC 9091. The most consequential change for anyone with a deployed DMARC record: the pct tag has been removed from the specification (RFC 9989 Appendix A.6). Records still containing pct= are not fatally broken — unknown tags are ignored — but pct is no longer a supported way to phase in enforcement, and you should stop relying on it.

Updated July 14, 2026 · DMARC

Verification note. We checked this against the RFC Editor rather than against secondary summaries, because a great deal of DMARC content on the web still describes pct as current. Read the source: RFC 9989.

What changed

ItemStatus under RFC 9989
RFC 7489 (DMARC, Informational)Obsoleted
RFC 9091 (DMARC PSD extension, Experimental)Obsoleted
pct=Removed from the specification (Appendix A.6)
t=yTesting indicator
p=, sp=, rua=, adkim=, aspf=Retained

Why pct is gone

The idea was reasonable: pct=10 would apply your policy to a sample of failing mail, so you could dial enforcement up gradually and watch for collateral damage. In practice the tag was a persistent source of confusion and inconsistent implementation. It made a domain's effective policy probabilistic and therefore hard to reason about, hard to report on, and hard to debug. The working group removed it rather than continue to standardise something that did not behave predictably across receivers.

What this means for your record

Nothing is on fire. DMARC parsers ignore unknown tags, so a record like v=DMARC1; p=none; pct=100; rua=mailto:… is still evaluated normally for everything else. But:

How to stage enforcement now

  1. p=none with rua. Collect aggregate reports until you can name every source sending as your domain. This is the step people rush; don't.
  2. Fix alignment for each legitimate source. DMARC needs SPF or DKIM to pass and align with the visible From domain — passing alone is not enough.
  3. sp= for subdomains. This is the real replacement for gradual rollout: enforce on the organizational domain while a lagging subdomain stays permissive, rather than enforcing probabilistically across everything.
  4. p=quarantine, then p=reject, reading reports after each move.

Check what you currently publish

We parse the live record and flag tags that are no longer in the spec.

Frequently asked

What is RFC 9989?

RFC 9989 is the DMARC specification published in May 2026. It obsoletes RFC 7489 and RFC 9091, and moves DMARC onto the IETF Standards Track. It is now the authoritative definition of DMARC.

Was the DMARC pct tag removed?

Yes. RFC 9989 removes the pct tag from the DMARC specification — see Appendix A.6, which lists the changes from RFC 7489. pct was intended to let a domain apply its policy to a percentage of messages during rollout, but it interacted badly with the way receivers and reporters implemented it, and it is no longer part of the spec.

Do I have to remove pct from my DMARC record?

It is not an emergency. DMARC parsers ignore tags they do not recognise, so a record with pct= will still be evaluated for its p, rua and alignment tags. But pct no longer does what you think it does, so you should not use it to stage a rollout, and you should remove it when you next touch the record to avoid misleading whoever reads it after you.

How do I roll out DMARC enforcement without pct?

Use the tools that actually work: start at p=none and read your aggregate reports until you can account for every legitimate sender; then move to p=quarantine, then p=reject. Use the sp tag to apply a different policy to subdomains, so you can enforce on the parent while a lagging subdomain catches up. RFC 9989 also defines t=y as a testing indicator.

Related

Automate this → — free tier, public pricing, API key emailed in about thirty seconds. No call with anyone.