DMARCbis Is Now Official: What RFC 9989, 9990 & 9991 Mean for Australian Businesses

For years, anyone following email authentication has been hearing about DMARCbis — the long-promised refresh of the DMARC standard. As of May 2026, it's no longer a draft. The IETF has published it as three new RFCs, and that changes one thing immediately: we can mostly stop saying "DMARCbis" and just call it what it is — DMARC.

If that sounds anticlimactic, good. For the overwhelming majority of Australian businesses, that's exactly the right reaction. Your records still work, your mail still flows, and there's no emergency on your DNS panel. But it's worth understanding what actually shipped, what the new guidance says, and the one or two things genuinely worth doing.

What actually got published

The original DMARC specification was a single document — RFC 7489, published back in 2015 with merely "Informational" status. DMARCbis replaces it with three focused documents, and promotes DMARC to a formal Proposed Standard on the IETF standards track (the same standing SPF and DKIM already hold):

• RFC 9989 — the core DMARC protocol: policy evaluation, alignment, record syntax.
• RFC 9990 — aggregate reporting (the daily XML reports you already receive).
• RFC 9991 — failure reporting (the near-real-time, per-message "forensic" reports).

Splitting it into three means each piece can evolve on its own schedule from here. It does not mean you have three things to configure — your DMARC record is still a single TXT record, and it still begins with v=DMARC1.

"Forget DMARCbis" — the naming actually matters

You'll see plenty of commentary along the lines of "forget DMARCbis, it's just DMARC now." That's not a throwaway line — it's the practical reality. "DMARCbis" was only ever the IETF's internal working title for the revision effort ("bis" is standards-speak for "a second take"). Now that the revision is the published standard, the parallel name has done its job.

Why does this matter to you? Because some vendors have spent the last couple of years marketing "DMARCbis readiness" as though it were a separate product you need to buy into. It isn't. There is no v=DMARC2. There is no migration deadline stamped on your domain. There is just DMARC, slightly refined, and the same job it always did: stopping criminals from sending email that looks like it came from you.

What changed under the hood

Three things are worth knowing about:

1. Cleaner tags

Three rarely-useful tags are deprecated: pct (the percentage tag almost everyone set to 0 or 100), rf (forensic report format — only one format ever existed), and ri (report interval — widely ignored). In their place, the new t tag gives a clean binary: t=y for testing, t=n for full enforcement. No more guessing what pct=25 was supposed to achieve.

Two genuinely useful additions arrive too: np (a policy for non-existent subdomains — a real anti-spoofing win) and psd (a flag for public-suffix registry operators, which almost no ordinary business will ever need).

2. The DNS Tree Walk

The biggest behind-the-scenes change. DMARC used to lean on the externally-maintained Public Suffix List to work out where one organisation's domain ends and another begins. DMARCbis replaces that with a DNS Tree Walk — receivers now query DNS directly, walking up the domain label by label. It's more accurate and self-contained, and for you it happens entirely at the receiving end (Gmail, Microsoft 365, Yahoo). Nothing to configure.

3. The careful new language around p=reject

This is the change most worth reading slowly, because it's easy to misread. DMARCbis adds explicit caution around the strongest policy. It advises that domains hosting large numbers of general-purpose user mailboxes — the Gmail and Outlook.com class of provider — shouldn't reflexively default to p=reject, because legitimate forwarded and mailing-list mail can break under it. The RFC even instructs receivers not to reject a message solely because they saw p=reject.

For a typical Australian business, this changes nothing. If your domain sends invoices, quotes, notifications and staff email — rather than hosting thousands of third-party consumer mailboxes — then p=reject is still exactly where you want to land, and it remains the gold standard for shutting down domain spoofing. The new caution is aimed squarely at a specific class of mailbox provider. Reading it as "reject is now discouraged for everyone" is the mistake to avoid.

What Australian businesses should actually do

The to-do list is short and unhurried:

1. Clean up deprecated tags when convenient. If your record carries pct, rf or ri, they won't break anything — receivers will simply ignore them — but tidying them up is good housekeeping.
2. Consider np=reject. If your domain doesn't send mail from subdomains, this closes a real spoofing gap (attackers inventing billing.yourdomain.com.au and the like). Worth adding now, RFC or no RFC.
3. Stay at — or keep heading toward — p=reject if you're a normal sending business. The new guidance doesn't change your destination.
4. Make sure your monitoring tool understands the new report format. When the big providers switch to DMARCbis-style reports, any platform that can't parse the new XML will quietly lose visibility into who's sending as you.

None of this is urgent. Receiver adoption is still early — only a handful of providers send DMARCbis-format reports today — so you have time. The value is in being correctly positioned before the major providers roll it out over the coming months.

The bottom line

DMARCbis being published is a milestone, not an alarm. The standard you've been running is now formally blessed, slightly cleaner, and better at handling subdomains. The headline for Australian businesses hasn't changed since we first wrote about this update: don't panic, don't ignore it — and if you're on a platform that automates DNS, the transition mostly happens without you.

It's just DMARC now. And if your domain's properly enforced, you're already ready for it.