🆕 DMARCbis (DMARC 2.0)
DMARC was published in 2015 as RFC 7489, an Informational document. In May 2026 the IETF replaced it with three Proposed Standards, known informally as DMARCbis or DMARC 2.0: RFC 9989 (the core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting). Nothing already published breaks. Existing DMARC records keep working. The revision is mostly about how receivers behave and which tags belong in the core spec.
The short version
- Receivers look up your organizational domain by walking up DNS instead of using the Public Suffix List.
- Three new tags:
np=,t=, andpsd=. - Three old tags removed from core DMARC:
pct=,rf=, andri=(the last moved into the reporting RFC). - SPF alignment now checks MAIL FROM only. The HELO fallback is gone.
- DMARC went from Informational (RFC 7489) to Proposed Standard (RFC 9989), so expect more consistent enforcement over time.
The DNS Tree Walk
The main change in DMARCbis is how receivers find your organizational domain. Under RFC 7489 they consulted the Public Suffix List (PSL), a Mozilla-maintained file shipped with each implementation. The PSL was inconsistent across vendors, drifted out of date, and didn't cover newer registries cleanly.
DMARCbis replaces that with a DNS Tree Walk. Starting at the full domain in the email's RFC5322.From, the receiver looks up _dmarc.<name> at each level, walking up to five labels toward the root. The first level that returns a DMARC record is treated as the organizational domain. If nothing is found, the receiver checks for a psd= public-suffix record at the registry level.
The practical effects: organizational-domain detection is consistent across receivers, harder to game with creative subdomain registration, and lives entirely in DNS where you can see and control it. It's a receiver-side change, so there's nothing you need to do to your record.
RFC 7489 vs DMARCbis at a glance
| Topic | RFC 7489 (2015) | DMARCbis (2026) |
|---|---|---|
| Status | Informational | Proposed Standard (RFC 9989/9990/9991) |
| Org domain lookup | Public Suffix List | DNS Tree Walk (up to 5 labels) |
| Subdomain spoofing of non-existent names | Implicit (covered by sp=) |
Explicit via np= |
| Staged rollout | pct= (percentage) |
t= (testing mode y/n) |
| Registry-level policy | Experimental (RFC 9091) | Core via psd= |
| Reporting format / interval | rf=, ri= in core |
rf= removed, ri= moved to RFC 9990 |
| SPF alignment | MAIL FROM, fall back to HELO | MAIL FROM only |
New tags in DMARCbis
DMARCbis adds three tags to the core spec. Each has a full reference page with valid values, defaults, and examples.
np=
np=reject blocks spoofing of NXDOMAIN names like support-recovery.yourbank.com that no DNS record covers today.t=
t=y tells receivers your policy isn't fully rolled out yet. Replaces the percentage-based staging that pct= used to do.psd=
Removed and relocated tags
These tags still parse cleanly if you leave them in an existing record. Receivers that implement DMARCbis will ignore them. New records should leave them out.
pct=
t=y for staged rollouts instead. Percentage-based sampling caused inconsistent receiver behaviour and is no longer specified.rf=
ri=
SPF alignment also changed. RFC 7489 checked MAIL FROM and fell back to the SMTP HELO identity if MAIL FROM was null. DMARCbis drops the HELO fallback entirely. If you've been relying on bounce traffic aligning via HELO, that path no longer counts.
What this means for the records you publish today
Nothing breaks. Your existing record is still valid and still respected by every receiver running the older spec. The DNS Tree Walk and the Proposed Standard status are receiver-side behaviour that doesn't require any change on your end.
Over time, two changes are worth making:
- Add
np=rejectto close the gap on non-existent subdomain spoofing. If you publishp=reject; sp=rejecttoday, addingnp=rejectis the natural completion. - If you're still running a staged rollout via
pct=, plan to retire it. Uset=ywhile you watch reports, then remove both tags once you're confident.
No urgency on either one. They're hardening, not fixes.
🛡️ Check or update your DMARC record
Run the analyser against your current record, or build a new one with the DMARCbis tags wired in.
Frequently Asked Questions
Is DMARCbis the same as DMARC 2.0?
Yes. "DMARCbis" is the IETF working-group nickname for the revision that became RFC 9989, 9990, and 9991. "DMARC 2.0" is the informal industry name for the same thing. There is no separate "version 2" of the protocol; the version tag in your record is still v=DMARC1.
Do I need to change my DMARC record right now?
No. Existing records keep working. Receivers running the new spec parse them the same way the old ones did. The only reason to edit is to add np=reject for stronger subdomain coverage, or to retire pct= in favour of t=y. Neither is urgent.
What happened to pct=?
It was removed in RFC 9989. Percentage-based sampling produced inconsistent behaviour across receivers, and the working group landed on a simpler t=y testing flag for staged rollouts. If you publish pct= today, DMARCbis receivers will ignore it. Older receivers still honour it, so leaving it in place during a transition is safe.
What is the DNS Tree Walk?
The receiver looks for a DMARC record at the full domain in the email's From header. If nothing is published there, it strips one label and looks again. It repeats this up to five times, walking from the full name toward the root. The first level that publishes a DMARC record is treated as the organizational domain. This replaces the older Public Suffix List approach, which depended on a file that each receiver shipped and updated separately.
Will my aggregate or failure reports change format?
The reporting RFCs (9990 for aggregate, 9991 for failure) are tidied up but largely compatible with what RFC 7489 specified. If your current reporting pipeline parses RFC 7489 aggregate XML correctly, it'll keep working. The ri= tag that controlled aggregate interval has moved out of the core record into the aggregate-reporting RFC, but most receivers ignored custom intervals anyway and sent daily.