DMARCbis Explained: What Australian Businesses Need to Know

If you have been managing DMARC for your organisation, you have probably heard plenty about DMARCbis — the updated DMARC specification developed by the Internet Engineering Task Force (IETF). As of May 2026 it is no longer a draft: it has been published as RFC 9989, 9990 and 9991, replacing the original RFC 7489 from 2015. It is the most significant update to the protocol in a decade.

The good news? Your existing DMARC records still work. DMARCbis is an evolution, not a revolution. But there are meaningful changes 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, and a follow-up on what the published RFCs mean. This post highlights what matters most.

What Is DMARCbis?

DMARCbis was the working title for the updated DMARC specification. Now published, 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 single original RFC 7489 has been split into three: RFC 9989 (core protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting).

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 — and now that the standard is published, most of the industry simply calls it "DMARC."

What Is Being Removed

Three tags are 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. But as receivers adopt DMARCbis, these tags will simply be ignored.

What Is Being Added

Three new tags are 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.

A Note on p=reject

DMARCbis adds careful new language around the strongest policy. It advises that domains hosting large numbers of general-purpose user mailboxes — the Gmail and Outlook.com class of provider — should not reflexively default to p=reject, because legitimate forwarded and mailing-list mail can break under it. For a typical Australian sending business, this changes nothing: p=reject remains the right destination and the strongest defence against spoofing. We unpack this in detail in our post on the published RFCs.

Aggregate Reports Are Getting an Upgrade

To see what your current DMARC record looks like, run our free DMARC Checker against your domain. It performs a live DNS lookup, parses every tag, and highlights which fields need attention.

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
• May 2026: Published as RFC 9989, 9990 and 9991 (Proposed Standard)
• 2026 onward: Provider adoption begins (Google, Microsoft, Yahoo)

Receiver-side adoption is still early — for now, only a handful of providers (such as United Internet AG: GMX, mail.com, WEB.DE) send reports in the 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, 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.
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.