DMARCbis (RFC 9989): What Actually Changed and What to Fix in Your Record

Short answer: DMARC has a new spec. In May 2026 the IETF published DMARCbis — RFC 9989 (with companions 9990/9991) — replacing RFC 7489 and promoting DMARC to a Proposed Standard. Most records published before 2026 now carry tags the new standard deprecates.

What changed

• pct= is deprecated. The percentage rollout mechanism never worked reliably (receivers implemented it inconsistently) and is now formally gone. Modern receivers ignore it. Staged rollout is instead achieved by moving p=none → p=quarantine → p=reject deliberately.
• rf= and ri= are deprecated. Failure-report format and reporting-interval tags — receivers largely ignored these for years; now it's official.
• The Public Suffix List is replaced by a DNS "tree walk". Receivers now discover your organizational domain by walking up the DNS tree looking for DMARC records, instead of consulting the PSL. For most senders nothing breaks, but subdomain policy behavior (sp=, and the new np= for non-existent subdomains) is now cleaner and worth setting explicitly.
• p=quarantine/reject now requires actual alignment discipline — nothing new mechanically, but the standard formalizes what Gmail/Microsoft already enforce.

What to do with your record

1. Remove pct=, rf= and ri= if present — they're dead weight that signals an unmaintained record.
2. Keep (or add) rua= — aggregate reporting is unchanged and remains your visibility into spoofing.
3. Consider explicit sp= and np= policies if you run subdomains — np=reject shuts down spoofing on non-existent subdomains cheaply.
4. Re-validate after editing.

Our DMARC checker validates against RFC 9989 — it flags the deprecated tags automatically, one of the few free checkers that does.