DMARCbis Is Coming: What Australian Businesses Need to Know in 2026

If you have been managing DMARC for your organisation, you have probably heard whispers about DMARCbis — the updated DMARC specification being developed by the Internet Engineering Task Force (IETF). It is the most significant update to the protocol since the original RFC 7489 was published in 2015.

The good news? Your existing DMARC records still work. DMARCbis is an evolution, not a revolution. But there are meaningful changes coming that every Australian business should understand — especially if you are working toward SMB1001 or Essential Eight compliance.

We have published a comprehensive DMARCbis Explained page that covers the full specification. This post highlights what matters most.

What Is DMARCbis?

DMARCbis is the working title for the updated DMARC specification. It elevates DMARC from an "Informational" document to a formal Proposed Standard — giving it the same standing as SPF and DKIM in the IETF standards track.

The DMARC version identifier stays the same: v=DMARC1. There is no v=DMARC2. Some people call it "DMARC 2.0" informally, but that is not an official designation.

What Is Being Removed

Three tags are being deprecated:

• pct (percentage tag) — In practice, nearly everyone used either 0 or 100, and receivers implemented it inconsistently. Values like pct=25 were unreliable.
• rf (forensic report format) — Only one format was ever supported (afrf), making this tag redundant.
• ri (report interval) — Most receivers ignored it and sent reports daily regardless.

If your DMARC record currently uses any of these tags, they will not break anything immediately. But as receivers adopt DMARCbis, these tags will simply be ignored.

What Is Being Added

Three new tags are being introduced:

t — Testing Mode

The t tag replaces pct with a clean binary choice: t=y means testing mode (policy is downgraded one level), and t=n means full enforcement. No more ambiguity about what pct=25 actually means in practice.

np — Non-existent Subdomain Policy

This is a genuinely useful addition. The np tag lets you apply a DMARC policy to subdomains that do not exist in DNS. Without it, attackers can spoof emails from made-up subdomains like invoices.yourdomain.com.au even if your root domain has p=reject. Adding np=reject closes that loophole.

psd — Public Suffix Domain

The psd tag indicates whether a domain is a public suffix (like .com.au) operated by a registry. Most domain owners will never need this tag — it is primarily for registry operators.

DNS Tree Walk: The Biggest Behind-the-Scenes Change

The original DMARC specification relied on the Public Suffix List (PSL) — an external, community-maintained list — to determine where organisational domain boundaries sit. DMARCbis replaces this with a DNS Tree Walk algorithm that queries DNS directly, walking up label by label from the sending domain until it finds the applicable DMARC policy.

This is more accurate, does not depend on an external list being kept up to date, and gives domain owners more control. For most Australian businesses, this change happens entirely at the receiver end (Gmail, Microsoft 365, Yahoo) — you do not need to do anything.

Aggregate Reports Are Getting an Upgrade

DMARCbis introduces a new XML namespace for aggregate reports, along with new fields like <testing>, <np>, and <discovery_method>. A new pass disposition is added alongside the existing quarantine and reject values.

This matters because your DMARC monitoring tool needs to be able to parse the new format. When major email providers like Google and Microsoft switch to DMARCbis reporting, any platform that cannot handle the new XML structure will start losing visibility into your email authentication data.

The Timeline

Here is where things stand:

• 2015: Original DMARC published as RFC 7489 (Informational)
• 2020-2024: IETF DMARC Working Group develops DMARCbis drafts
• April 2025: Base protocol and aggregate reporting documents submitted for publication
• November 2025: Failure reporting document submitted
• 2026 (expected): RFC publication as Proposed Standard
• 2026-2027: Provider adoption begins (Google, Microsoft, Yahoo)

As of April 2026, receiver-side adoption is minimal. Only United Internet AG (GMX, mail.com, WEB.DE) currently sends reports in DMARCbis format. There is no urgency to make changes today — but there is value in being prepared.

What You Should Do Now

For most Australian businesses, the action list is straightforward:

1. Audit your current DMARC record — Check whether you are using pct, rf, or ri tags. These will not cause problems yet, but cleaning them up now is good housekeeping.
2. Consider adding np=reject — If your domain does not use subdomains for email, this closes a real spoofing vector right now, even before DMARCbis is formally adopted.
3. Check your monitoring platform — Make sure your DMARC reporting tool can handle the new XML format. When Gmail and Microsoft switch, you need to maintain visibility.
4. Keep your SPF and DKIM healthy — DMARCbis does not change SPF or DKIM. The foundation of email authentication remains the same.

The Bottom Line

DMARCbis is not something to panic about. Your existing DMARC records remain valid, your emails will keep flowing, and the transition will be gradual. But it is something to be aware of — particularly if you are managing email authentication for multiple domains or working toward compliance standards.

The businesses that prepare early will have the smoothest transition. And if you are using a platform with automation capabilities, the transition will happen without you lifting a finger.

For the complete technical breakdown — including tag-by-tag comparisons, the DNS Tree Walk algorithm, and report format changes — visit our DMARCbis Explained page.