DMARCbis is official: what RFC 9989 actually changes for Australian businesses

After more than five years of work, the IETF has finished rewriting DMARC. In May 2026 three new documents — RFC 9989 (the core protocol), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting) — formally replaced RFC 7489, the original 2015 specification.

Before anything else, the reassuring part: nothing you've already published breaks. Records still start with v=DMARC1, every existing record keeps working, and there is no "DMARC2" to scramble towards. If your domain is set up correctly today, it is still set up correctly tomorrow.

So why write about it? Because while the syntax is unchanged, the advice underneath it has shifted — and one of those shifts directly contradicts the standard rollout playbook that nearly every DMARC vendor, ours included, has been repeating for a decade. If you manage email for a business, or you're a tradie, clinic, church or firm wondering whether your domain is actually protected, this is the part worth ten minutes.

First, why this even matters

The original DMARC spec was never a formal internet standard. It was published in 2015 as an "Informational" document — useful, widely adopted, but technically sitting outside the IETF's standards track. RFC 9989 changes that: DMARC is now an IETF Proposed Standard — the first rung of the official standards track, and the first time the protocol carries the IETF's own endorsement rather than sitting beside it, which is a meaningful step up in authority. Splitting it into three documents also means the reporting formats can evolve in future without re-opening the core protocol.

That's the housekeeping. Here's what changed in practice.

The big one: p=reject is no longer the default finish line

For ten years the advice has been identical everywhere: start at p=none to watch, move to p=quarantine, then finish at p=reject. Reject was the goal. Reject meant you'd "made it."

RFC 9989 pushes back on that last step (§7.4, and Appendix C.6). For domains that host general-purpose mailboxes — that is, real humans sending real email, the situation almost every small business is in — the spec now says p=quarantine should be the end state, not a stepping stone to reject. It goes further and tells receiving mail servers that they must not reject a message purely because it failed against a p=reject policy; absent other signals, they're to treat it as quarantine anyway.

The reason is the problem DMARC has never solved: indirect mail. When someone on your domain posts to a mailing list, or their message is forwarded through an intermediary, the forwarding service resends it with your address still in the "From" line. SPF breaks because the email no longer comes from your servers, and DKIM often breaks because the message was modified in transit. Under a strict p=reject, those legitimate messages get rejected — and mailing-list software, seeing the bounces, can quietly unsubscribe your people. After a decade waiting for a technical fix that never gained traction, the working group simply changed the guidance to match reality.

What this means for you, in plain terms:

• If your domain is where staff and customers send normal day-to-day email, p=quarantine is now the recommended, fully-protected destination. You are not "falling short" by stopping there.
• If you have a dedicated, machine-only sending domain or subdomain — invoices, booking confirmations, marketing blasts, nothing with a human behind it — p=reject is still appropriate there.
• For names that never send mail at all, locking them down hard still applies, and we'll come to that next.

This is the one change worth a fresh look at your current setup. If a previous provider pushed you to p=reject on your main mailbox domain, that decision is worth revisiting — not because it's broken, but because the people who wrote the standard now think quarantine is the better resting place for that kind of domain.

The two-stream problem (and the fix)

Here's where it gets practical, because most businesses have two different kinds of mail going out under one domain, and they need opposite policies.

Take a typical small business on yourbusiness.com.au. Staff send normal email from their mailboxes — some of them post to an industry mailing list, some have mail auto-forwarded. That stream wants p=quarantine, for all the reasons above. But the same business also runs accounting software that emails invoices and statements to customers. That's a machine. It sends down a fixed path, no human behind it, and it never touches a mailing list. That stream wants p=reject — there's nothing for reject to break, and invoices are exactly the kind of mail criminals love to spoof.

Pick one policy for the whole domain and you get the wrong fit on one of the streams: quarantine leaves your invoices softer than they should be, reject risks bouncing a staffer off a mailing list. The fix isn't to compromise. It's to put the two streams on different names, so each gets the policy that suits it.

In practice that means sending the invoices from a dedicated subdomain — say invoices.yourbusiness.com.au — with its own SPF and DKIM set up for the accounting software, and its own DMARC policy. Your records end up looking like this:

# The main domain, where humans send — rests at quarantine.
# sp=reject locks down any subdomain that doesn't publish its own policy;
# np=reject rejects mail from subdomains that don't exist at all.
_dmarc.yourbusiness.com.au
  v=DMARC1; p=quarantine; sp=reject; np=reject; rua=mailto:[email protected]

# The invoice subdomain — a machine-only stream, locked to reject.
_dmarc.invoices.yourbusiness.com.au
  v=DMARC1; p=reject; rua=mailto:[email protected]

The accounting software is then pointed at invoices.yourbusiness.com.au so its mail sends as, say, [email protected]. The humans keep their normal addresses at quarantine; the invoices go out hard-locked at reject; everything else is covered by sp and np on the parent.

One honest note for the real world: this is a small migration, not a DNS-only flip. The accounting package has to support a custom sending domain — many do, including the common ones, though it varies by product and plan — and the new subdomain needs to be verified and given a little time to establish its sending reputation before you lock it to reject. Worth doing properly rather than overnight.

If you've never thought about which of your mail streams is which, that's the question worth sitting with: is the software that sends your invoices using the same domain as your staff — and is anything stopping someone from forging it?

pct is gone — and that's quietly a good thing

The old pct tag let you apply a policy to a percentage of mail — pct=25, then pct=50, then pct=100 — as a way to ease into enforcement. It's been removed.

Why? The working group found it never worked the way people assumed. Mail receivers handled the in-between values so inconsistently that anything other than 0% or 100% was effectively a coin toss. The "gradual percentage rollout" looked precise but wasn't.

In its place is a simpler test-mode flag, t=y, which asks receivers to apply the next-lower policy while you watch your reports — a one or two week dry run before you commit. It's coarser than the old percentages, but it's honest about what's actually deterministic.

There's a broader point here that's easy to miss. The spec is steering people away from faking a gradual rollout with percentages and towards genuinely progressing the policy itself — none, then quarantine, then (where appropriate) reject — based on what your real mail data shows. The new t=y test step gives you a safe report-only dry run before each real enforcement move, which is a cleaner way to ease in than the old percentage dial ever was. If you publish pct anywhere today, nothing breaks; just drop it from new records.

(Two lesser-used tags, rf and ri, were removed at the same time. Almost nobody set them by hand, so for most readers this is trivia.)

A genuinely useful new tag: np

The new np tag sets a policy for subdomains that don't exist in your DNS. This is a small, low-risk win.

Picture an attacker spoofing accounts.yourbusiness.com.au — a subdomain you've never created. With np=reject published on your main domain, you tell the world that mail from non-existent subdomains should be rejected outright. Because it only ever applies to names that genuinely don't exist, it can't accidentally affect a real subdomain you do send from. For most businesses, adding np=reject is free protection against a common impersonation trick.

Two other new flags, psd and t, exist mainly for registry operators and large, complex organisations. If you're a normal business, you can safely ignore them — your tooling and your receivers will handle the defaults.

The Public Suffix List is out; a "DNS Tree Walk" is in

This is the most technical change, and for most readers it's invisible. To work out where your "organisational domain" sits, DMARC used to consult an offline list maintained by a third party. RFC 9989 replaces that with a live DNS lookup that walks up your domain tree (capped at eight queries).

For a straightforward domain — yourbusiness.com.au with mail on it — this produces exactly the same result as before. No change. The one place it can bite: if you have a tangled DNS setup with old, forgotten subdomain records, the new method may surface them. If you suddenly see odd subdomains turning up in your DMARC reports, that's the tree walk exposing something that was always there but previously skipped — and it's worth cleaning up.

Small changes to the reports themselves

If you (or your provider) analyse your DMARC aggregate reports, the data gained a few fields: a marker showing whether a receiver used the old list or the new tree walk, the new np and test-mode values, and a requirement that the DKIM selector now always be included. These are additive — existing report tooling keeps working — but they make it easier to correlate failures with things like DKIM key changes. Failure reports also picked up a formal privacy section, acknowledging they can leak personal information; most large providers already limit or disable them for that reason.

What you should actually do

For the overwhelming majority of Australian businesses, the honest answer is: not much, and nothing urgently.

1. If you're already at enforcement, revisit the p=reject question. Hosting normal staff mailboxes? p=quarantine is now the recommended end state. Dedicated sending subdomain with no humans? Reject is still fine.
2. Stop using pct in any new records. Use t=y for a short test run instead.
3. Consider adding np=reject if you don't intentionally send from bare, record-less subdomains. Easy, low-risk hardening.
4. Tidy up stray subdomain DNS records if your setup is complex.
5. Everything else can wait. v=DMARC1 keeps working and the transition across the email ecosystem will be gradual.

And the uncomfortable reality underneath all of this: most small and medium businesses aren't anywhere near these questions yet. Our own research across more than 10,000 Australian domains in 22 sectors keeps finding the same thing — large shares of businesses still have no enforcement at all and remain trivially spoofable. In our conveyancing-sector teardown, for example, more than three quarters of firms nationally could be impersonated by anyone who cared to try. For those businesses, the p=quarantine-versus-p=reject debate is academic. The first job is getting onto the ladder at all.

Where we sit

We make a DMARC product, so take the straight version: this update changes the advice more than it changes any record you've already published. We're working through the new spec across our platform — clearing the now-deprecated tags out of the records we manage, and moving our enforcement engine onto the standard's none → testing → enforcing model, so a domain progresses by policy plus a safe report-only step rather than by a percentage dial. That's a staged migration we're rolling out carefully, not a switch we've flipped overnight.

What hasn't changed is the part that matters most for you. If you're not sure where your domain stands, the fastest way to find out is to run it through our free DMARC checker. And if you want the deeper, evergreen walkthrough of how DMARC, SPF and DKIM fit together, our DMARCbis explainer covers the fundamentals.

The standard grew up in May 2026. For most businesses, the right response isn't panic — it's a five-minute check that you're on the ladder at all, and a quieter conversation about whether quarantine, not reject, is where your domain should rest.