DMARCbisRFC 9989 — the revised DMARC specification
DMARCbis is the IETF's update to the original DMARC specification, formalized as RFC 9989. It's not a new protocol you need to adopt separately — it's a clarified, corrected version of the rules receivers already use, closing gaps the original 2015 specification (RFC 7489) left ambiguous after a decade of real-world deployment.
If you already have a DMARC record, DMARCbis mostly changes what happens behind the scenes at the receiver, plus a handful of tags worth knowing about because they replace ones you may still be using.
pct= is being removed
The original pct= tag let you apply your DMARC policy to only a percentage of mail — a gradual rollout mechanism. DMARCbis removes it entirely, because partial enforcement created a trap: administrators would set pct=50 as a permanent "safety net" rather than a temporary rollout step, leaving half of impersonating mail unblocked indefinitely. Under DMARCbis, a domain is either enforcing or it isn't.
t=y replaces pct as the rollout mechanism
In place of a percentage, DMARCbis adds t=y (testing mode), which receivers apply by treating the effective policy as one level lower than published — for example, a p=reject record with t=y is treated as p=quarantine until testing mode is removed. It's a clearer, binary way to soft-launch a policy change.
np= — policy for non-existent subdomains
np= is new in DMARCbis: it sets the policy specifically for subdomains that don't exist in DNS at all — closing a specific spoofing angle where an attacker sends mail from a subdomain that was never registered, which the original spec didn't clearly address.
rf= and ri= are deprecated
Two tags from the original spec — rf= (forensic report format) and ri= (report interval) — are deprecated under DMARCbis (RFC 9990/9991), since forensic reports were rarely honored by major receivers in practice and the report interval was never widely respected. They're safe to remove from an existing record.
psd= — Public Suffix Domain declaration
DMARCbis formalizes psd= for organizations that manage a public suffix domain (a domain under which unrelated third parties register their own subdomains, like a registrar or a large hosting platform) — letting them apply DMARC policy correctly across a namespace they don't fully control end-to-end.
How Trustliant handles this
Trustliant's DMARC engine parses and validates records with DMARCbis awareness today: it recognizes np= and psd=, warns when pct= is set below 100 that DMARCbis is phasing the tag out, flags t=y testing-mode records with the effective-policy explanation, and calls out rf=/ri= as safe to remove per RFC 9990/9991 — so a domain's DMARC posture is evaluated against where the specification is headed, not just where it started in 2015.
Questions we get about DMARCbis
- Do I need to change my DMARC record because of DMARCbis?
- Not urgently. DMARCbis mostly clarifies receiver-side behavior and deprecates a few rarely-used tags. If your record uses pct= below 100 as a long-term setting, or still has rf=/ri= tags, those are worth revisiting — but a standard v=DMARC1; p=reject; rua=... record needs no changes.
- Is DMARCbis a separate thing from DMARC I need to publish?
- No — there's no separate "DMARCbis record." It's the same _dmarc TXT record; DMARCbis just describes updated rules for how that record's tags are interpreted and validated by up-to-date receivers and tools.