DMARCbis: What the DMARC Specification Update Means for Your Organisation
DMARC grows up
RFC 7489, published in 2015, has been the backbone of email authentication for nearly a decade. It held up remarkably well — but the cracks are showing. Ambiguous definitions, conflicting interpretations between mailbox providers, and a single-document structure that tries to cover everything have led to implementation differences that make life harder for administrators.
DMARCbis is the answer. The IETF DMARC working group has rewritten the specification from the ground up and split it into three separate documents, which were published as Standards Track RFCs in May 2026. The result is cleaner, more precise, and more practical.
Three RFCs instead of one
The biggest structural change: DMARCbis replaces the existing RFC 7489 with three standalone documents.
- RFC 9989 — DMARC (Core) covers the DMARC protocol itself: policies, identifier alignment, reporting mechanics. It obsoletes RFC 7489 (DMARC) and RFC 9091 (the PSL-based Organizational Domain rules).
- RFC 9990 — DMARC Aggregate Reporting defines the format and semantics of RUA (aggregate) reports separately and with far more precision than before.
- RFC 9991 — DMARC Failure Reporting treats RUF (forensic) reports as a distinct topic, including privacy considerations. It also updates the older RFC 6591.
This split might sound like bureaucracy, but it is a genuine improvement. If you only need to implement aggregate reporting, you no longer have to work through the entire protocol document. Implementers can reference the relevant RFC directly.
What changes in substance
Sharper definitions for identifier alignment
One of the most common sources of confusion in DMARC is the alignment concept: when exactly is a message considered DMARC-compliant? DMARCbis significantly tightens the definitions for Relaxed and Strict Alignment. The handling of subdomains in particular is described more precisely — an area that regularly leads to misconfigurations in practice.
Revised policy inheritance
The question of which DMARC policy applies to a subdomain when no explicit policy is set was not cleanly answered in RFC 7489 — and identifying the Organizational Domain via the Public Suffix List (PSL) regularly led to misinterpretations. RFC 9989 replaces that approach with a DNS tree walk: receivers walk the domain hierarchy label by label until they find a _dmarc record or reach the Organizational Domain. RFC 9989 also introduces a new np= tag that lets you set a distinct policy for non-existent subdomains. For organisations with many subdomains, this is an important clarification.
More precise reporting
The aggregate reporting format (DMARC RUA) stays largely the same at its core, but DMARCbis specifies more clearly which fields are mandatory, which are optional, and how receivers should handle missing or unexpected values. This reduces variance between reports from different mailbox providers — a pain point anyone who has manually parsed DMARC reports will recognise immediately.
ARC integration
Authenticated Received Chain (ARC) — the mechanism that makes email forwarding through mailing lists or forwarders DMARC-compatible — gets more explicit treatment in DMARCbis. RFC 7489 predates ARC standardisation; DMARCbis explicitly describes how ARC signatures can be considered during DMARC evaluation.
What stays the same
The fundamental logic of DMARC does not change. SPF and DKIM remain the two authentication mechanisms. The alignment principle is preserved. The policy values none, quarantine, and reject are unchanged. If you have a correct DMARC configuration today, there is no need to panic.
The DNS record format also remains compatible. An existing _dmarc TXT record will continue to work under DMARCbis — there are no breaking changes for senders.
What this means in practice
For most IT administrators, little changes in the short term. DMARCbis was published in May 2026 as RFC 9989, RFC 9990, and RFC 9991 on the Standards Track — the specification is now finalised. Mailbox providers like Google and Microsoft will roll out their implementations over the coming months.
In the medium term, the organisations that benefit most are those that:
- Operate many subdomains and have been uncertain which policy applies
- Process DMARC reports automatically and struggle with inconsistent report formats
- Use email forwarding or mailing lists where ARC becomes relevant
For MSPs and IT service providers managing DMARC across multiple clients, the clearer specification means less room for interpretation — and less support overhead.
Now is a good time for a health check
DMARCbis does not change the fundamentals — but it is a good prompt to review your current DMARC setup. Are all subdomains covered? Are aggregate reports being evaluated? Is your policy already at reject, or still sitting at none?
With DMARCPulse’s free domain check, you can see in seconds where your domain stands and what needs to be done.