DMARCbis is Here. Your Clients’ DMARC Records Need a Second Look.

The DMARC spec your clients’ records were written against stopped being current in May 2026.

RFC 9989, known as DMARCbis, officially replaced RFC 7489, the document that has defined DMARC since 2015. If you set up a client’s DMARC record any time in the last decade, it was written against the old spec. That doesn’t mean it’s broken. It does mean the ground shifted under it, and most monitoring tools haven’t caught up.

Here’s what actually changed, what it means for the records you’re responsible for, and what to do about it.

What DMARCbis actually changed

Existing records continue to work. DMARCbis is additive and doesn’t invalidate anything you’ve already set up. v=DMARC1 stays the same. The changes are three new tags and a different method for finding the authoritative policy record for complex domain structures.

Three new tags

np= sets a policy specifically for non-existent subdomains, the kind attackers probe when they send from made-up addresses like [email protected]. Previously, your sp= subdomain policy covered these, but there was no way to treat “this subdomain exists but sends no mail” differently from “this subdomain doesn’t exist at all.” Now there is.

psd= tells receivers whether your domain is a public suffix (like co.uk) or an organisational boundary. Setting psd=n signals that you’re a normal domain and receivers should stop the lookup here. It’s mostly relevant for unusual TLD structures, but it’s part of the spec now.

t= replaces pct= as the mechanism for controlling enforcement during rollout. Setting t=y puts the record into test mode, but the behaviour is more precise than pct= ever was: it softens the stated policy by exactly one level. A p=reject record with t=y is treated as quarantine. A p=quarantine record with t=y is treated as none. It’s a graduated step-down, not a coin flip applied to a percentage of messages.

DNS Tree Walk replaces the Public Suffix List

This is the structural change worth understanding. Under the old spec, receivers determined your organisational domain by consulting a Public Suffix List (PSL), a community-maintained file listing every public suffix. Under DMARCbis, receivers walk up the DNS hierarchy instead: query _dmarc.invoices.example.com, not found, query _dmarc.example.com, found, stop. The walk is capped at 8 queries to prevent loops and limit exposure to malicious domain structures.

This matters for clients with complex subdomain setups. A PSL-based receiver and a DNS Tree Walk receiver can reach different conclusions about which domain’s policy applies. The fix is simple: make sure every domain you manage has an explicit _dmarc record at the right level. But it’s worth auditing if you haven’t recently.

What about DKIM2?

DKIM2 has been mentioned alongside DMARCbis, but the two are at very different stages.

DMARCbis is a published, active standard. RFC 9989 is final. Compliant receivers are already implementing it. Adapt now.

DKIM2 is still a working draft. The DKIM2 spec hasn’t been published as an RFC. Keep an eye on it, but don’t change production infrastructure yet.

The key improvement DKIM2 makes over current DKIM is a verifiable chain of custody: every server that handles a message signs it, which solves the long-standing problem of DKIM signatures breaking when email is forwarded. It also explicitly encodes the intended recipients, preventing replay attacks.

As of mid-2026, Stalwart is the only production mail server with a full DKIM2 implementation. Major providers like Google and Yahoo are expected to run it in experimental mode around Q4 2026, with dual-signing (both classic DKIM and DKIM2 headers) as the transition strategy for at least the next two years.

There’s also a practical detection problem: DKIM2 key records in DNS look identical to DKIM1 records. You can’t tell from a DNS lookup alone whether a domain is using DKIM2. Detection requires reading email headers, specifically DKIM2-Signature and Message-Instance, which is out of scope for a DNS monitoring tool until deployment is widespread.

When your clients’ mail providers start dual-signing, the signals will be visible.

What does this mean in practice?

If you manage DNS for clients, these are the things worth checking now:

Audit and remove pct= tags immediately. RFC 9989 removed pct= entirely. Compliant receivers silently ignore unknown tags, so pct=50 in a record is now skipped, and the policy applies to 100% of messages. A client who has been using pct=50 for a cautious rollout is now getting full enforcement from any RFC 9989-compliant receiver, whether they know it or not. If they’re not ready for full enforcement, switch to t=y explicitly.
Check _dmarc records at each subdomain level for complex setups. DNS Tree Walk is more predictable than PSL lookups, but only when records are where receivers expect them. A subdomain with no _dmarc record at its own level inherits from the parent, which may or may not match what you intend.
Consider adding np=reject for clients already at p=reject. If sp= covers existing subdomains, np= closes the remaining gap for non-existent ones. Low effort, cleaner posture.
Leave DKIM alone for now. No action is needed until DKIM2 deployment is real and detectable.

kant.au now runs the DNS Tree Walk natively for every domain you’re monitoring, which means it finds inherited DMARC policies exactly the way RFC 9989-compliant receivers do. If a subdomain is silently inheriting a policy from a parent domain you didn’t intend, that mismatch shows up before it causes a live delivery failure for your client. Want to check a single domain’s setup right now? Check it for free. To track pct= tags and inherited policies across your whole client list automatically, start a free 14-day trial.

RFC 9989, DMARCbis core protocol
RFC 9990, DMARCbis aggregate reporting
draft-ietf-dkim-dkim2-spec, DKIM2 draft