DMARCbis: The Biggest DMARC Update in a Decade
DMARC is getting its first major revision since 2015. Here's what's changing, what stays the same, and why DMARC Busta customers don't need to worry.
What Is DMARCbis?
DMARCbis is the updated specification of DMARC, developed by the Internet Engineering Task Force (IETF). It's not a replacement — it's a refinement of the protocol that has protected email domains since 2015.
The original DMARC specification (RFC 7489) was published as an "Informational" document. DMARCbis elevates DMARC to a formal "Proposed Standard," reflecting how essential email authentication has become.
Think of it as DMARC growing up. The core protection stays the same — your domain is still guarded against spoofing and phishing. But the specification is being restructured to be clearer, simpler to implement, and better equipped for modern email ecosystems.
The good news
Your existing DMARC records remain valid. DMARCbis records still start with v=DMARC1. This is an evolution, not a revolution — no emergency changes required.
What's Actually Changing?
DMARCbis introduces a handful of practical improvements — removing tags that caused confusion, adding tags that close security gaps, and modernising how reports are structured.
Tags Being Removed
Percentage of emails to apply policy
In practice, nearly everyone used either 0 or 100. Receivers implemented it inconsistently, making values between those unreliable.
Forensic report format
Only one format was ever supported (afrf), making this tag pointless.
Report interval
Most receivers ignored it and sent reports daily regardless. Reports will now simply be sent daily or more frequently.
Tags Being Added
Testing mode toggle
Replaces pct with a simple binary: t=y (testing — policy downgraded one level) or t=n (full enforcement).
No more guessing what pct=25 means.
Non-existent subdomain policy
Applies a DMARC policy to subdomains that don't actually exist in DNS.
Closes a loophole where attackers spoof emails from made-up subdomains.
Public suffix domain
Indicates whether a domain is a public suffix (like .com.au) operated by a registry.
Used by the DNS Tree Walk algorithm. Most domain owners won't need this.
DNS Tree Walk Replaces the Public Suffix List
DMARC has always needed to figure out the "organisational domain" — the registered domain that owns a given subdomain. Until now, it relied on an external list called the Public Suffix List (PSL) to do this.
DMARCbis replaces the PSL with a DNS Tree Walk algorithm — a method that queries DNS directly, walking up label by label from the sending domain until it finds the DMARC policy. This is more accurate, doesn't depend on an external list being kept up to date, and gives domain owners more control.
For most Australian businesses, this change happens behind the scenes at the receiver end (Gmail, Microsoft, Yahoo). You don't need to do anything — but your DMARC management platform should understand it.
Aggregate Reports Are Getting an Upgrade
The XML format used for DMARC aggregate reports is being modernised:
-
New XML namespace (
urn:ietf:params:xml:ns:dmarc-2.0) to distinguish DMARCbis-era reports -
New fields:
<testing>,<np>,<discovery_method> -
New
passdisposition added alongside existingquarantineandreject -
sampled_outoverride reason removed (sincepctis gone) - The specification is now split into three separate documents: base protocol, aggregate reporting, and failure reporting
Why this matters for your platform: If your DMARC monitoring tool can't parse the new report format, you'll start losing visibility when major email providers switch. DMARC Busta's report parser is being updated to handle both formats seamlessly.
What Does This Mean for Australian Businesses?
The short answer: don't panic, but don't ignore it either.
Your existing DMARC record still works
DMARCbis records continue to use v=DMARC1. Your current DMARC, SPF, and DKIM setup remains fully functional. There is no deadline to change anything.
Deprecated tags should be cleaned up — eventually
If your DMARC record includes pct, rf, or ri tags, they won't break anything immediately. But as receivers adopt DMARCbis, these tags will be ignored. It's good housekeeping to remove them and adopt t=y or t=n when you're ready.
Consider adding the np tag
If your domain doesn't use subdomains for email, adding np=reject closes a real spoofing vector. Attackers can create subdomains that don't exist — billing.yourdomain.com.au, support.yourdomain.com.au — and spoof emails from them. The np tag stops this.
Make sure your DMARC platform handles the transition
This is the most important point. When Gmail, Microsoft 365, and Yahoo start sending reports in the DMARCbis format, your monitoring tool needs to parse them correctly. If it can't, you lose visibility into who's sending email on behalf of your domain — exactly when you need it most.
Australian compliance requirements aren't changing (yet)
The SMB1001:2025 standard and ASD Essential Eight both reference DMARC, but don't specify a particular version. DMARCbis readiness positions you ahead of any future compliance updates.
DMARCbis Timeline
Where are we now?
Original DMARC Published
RFC 7489 published as "Informational" status
IETF Development
DMARC Working Group develops DMARCbis drafts
Documents Submitted
Main DMARCbis documents submitted for publication
Failure Reporting Submitted
Failure reporting document submitted for publication
RFC Publication
Publication as Proposed Standard
Provider Adoption
Google, Microsoft, Yahoo begin adopting DMARCbis report format and tag handling
Note: As of April 2026, receiver-side adoption is minimal. Only United Internet AG (GMX, mail.com, WEB.DE) currently sends reports in DMARCbis format. The RFC publication will trigger wider adoption.
How DMARC Busta Keeps You Ahead
Most DMARC platforms are taking a wait-and-see approach. We're not. DMARC Busta is built to handle the DMARCbis transition automatically — because that's what Autopilot does.
Autopilot Manages Tag Migration
When DMARCbis tags become standard, Autopilot will update your DMARC records automatically — replacing deprecated tags with their DMARCbis equivalents. No manual DNS changes required.
Report Parser Handles Both Formats
Our DMARC report engine is being updated to parse both RFC 7489 and DMARCbis XML report formats. When Google or Microsoft switch, your dashboard won't skip a beat.
Scanner Detects DMARCbis Readiness
Our free domain scanner checks your DMARC record for deprecated tags and missing DMARCbis improvements — giving you a clear picture of where you stand.
Non-Existent Subdomain Protection
DMARCbis introduces the np tag to block subdomain spoofing. DMARC Busta will recommend and deploy this protection as part of your domain's security posture.
No other DMARC platform makes DNS changes for you automatically.
Competitors monitor and advise — DMARC Busta's Autopilot actually updates your records. That's the difference between reading about DMARCbis and being ready for it.
DMARCbis FAQ
v=DMARC1. There is no v=DMARC2.pct, rf, ri) and consider adding new ones (t, np), but there's no urgency.v=DMARC1 records. The changes are additive and backwards-compatible. However, deprecated tags like pct may be ignored by receivers as they adopt DMARCbis.pct tag is being replaced by the simpler t tag. If you're using pct=100 (or no pct tag at all), you're already at full enforcement — equivalent to t=n. If you're using pct=0 for testing, that's equivalent to t=y. During the transition, both tags will coexist.Check Your Domain's DMARCbis Readiness
Run a free scan to see if your domain is using deprecated DMARC tags, missing subdomain protection, or ready for the DMARCbis transition.
No credit card required