DMARCbis Is Now Official
In May 2026 the IETF published DMARC's first major revision since 2015 — three new RFCs replacing the original RFC 7489. Here's what changed, what stays the same, and why DMARC Busta customers don't need to do a thing.
What Is DMARCbis?
DMARCbis is the updated specification of DMARC, developed by the Internet Engineering Task Force (IETF) and published in May 2026. 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 in 2015 as a single "Informational" document. DMARCbis splits it into three RFCs — RFC 9989 (the core protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting) — and elevates DMARC to a formal "Proposed Standard," reflecting how essential email authentication has become.
One thing worth knowing: now that it's published, the wider industry has largely stopped calling it "DMARCbis." That was always just the IETF's working title — the standard it produced is simply DMARC. We use the term here because it's what people are searching for, but the records in your DNS don't change.
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.
One nuance worth understanding: p=reject
DMARCbis adds careful new language around the strongest policy. It advises that domains hosting general-purpose user mailboxes — think large consumer providers like Gmail or Outlook.com — shouldn't necessarily default to p=reject, because legitimate forwarded and mailing-list mail can break under it. The RFC even tells receivers not to reject a message solely because it saw p=reject.
For the typical Australian business this changes nothing. If your domain sends transactional and business mail — invoices, quotes, notifications — rather than hosting thousands of third-party mailboxes, p=reject remains exactly where you want to be, and it's still the gold standard for stopping domain spoofing. The caution is aimed at a specific class of mailbox provider, not at you. DMARC Busta's Autopilot already accounts for this distinction when it decides how far to take your policy.
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 9989, 9990 & 9991
Published as Proposed Standard, replacing RFC 7489
Provider Adoption
Now that the RFCs are published, Google, Microsoft and Yahoo are expected to roll out DMARCbis report format and tag handling over the coming months
Note: Publication is the starting gun, not the finish line. 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. The major providers are expected to follow now that the standard is final.
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.
We're Migrating Tags For You
The records we manage no longer carry any deprecated tags — rf and ri went first, and in July 2026 we retired pct staging fleet-wide: Autopilot now advances policy in full, evidence-gated steps rather than percentages. Adopting the new t tag as the testing mechanism is on our roadmap — when it ships, your records update automatically, no manual DNS changes.
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.
Automation most DMARC platforms don't offer.
Most DMARC tools monitor and advise — DMARC Busta's Autopilot actually updates your records. That's the difference between reading about DMARCbis and being ready for it.
Software writing your DNS records should invite scrutiny, not applause — here's how Autopilot decides, where the guardrails sit, and what to ask any vendor that automates DMARC enforcement.
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.RFC 9989 (core protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting) — replacing the original RFC 7489 from 2015. Major email providers like Google, Microsoft, and Yahoo are expected to begin adopting the changes over the following months.p=reject specifically for domains that host large numbers of general-purpose user mailboxes (the Gmail/Outlook.com class of provider), where legitimate forwarded and mailing-list mail can break. If your domain sends business and transactional mail rather than hosting third-party mailboxes, p=reject is still the right destination and the strongest protection against spoofing. The new guidance is targeted, not a blanket retreat from enforcement.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.pct, rf and ri, and whether subdomain protection (np) is in place. The DMARC records we manage no longer carry any of the deprecated tags: rf and ri were removed first, and in July 2026 we retired pct staging fleet-wide — Autopilot now advances policy in full, evidence-gated steps rather than percentages. Support for the new t (testing) and np tags in Autopilot's progression is on our roadmap; when it ships, Autopilot will update your records automatically with no manual DNS changes.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