DMARC has technically been running on an informational RFC from 2015 for its entire operational life, even as Google, Yahoo, and Microsoft built hard enforcement on top of it. That changed on May 20, 2026, when the IETF’s RFC Editor published three documents collectively known as DMARCbis: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting, and RFC 9991 for failure reporting. Together they replace RFC 7489 and, for the first time, put DMARC on the IETF Standards Track as a Proposed Standard rather than an informational note that receivers happened to enforce anyway.
What is actually new
The most consequential technical change is how DMARC determines the “organisational domain” for a sending domain, the level at which policy actually applies. The old approach depended on the Public Suffix List, a manually maintained, crowd-sourced text file that frequently lagged behind how domains and registrars actually structured things, particularly for country-code domains like co.uk, com.de, or similar structures common across Europe. RFC 9989 replaces that dependency with a live DNS tree walk, querying DNS directly to determine domain boundaries rather than relying on a static list that could be stale or simply wrong for a given registry.
Beyond that, DMARCbis formalises Public Suffix Domain handling more coherently, tidies up tags that existed in the original spec but never worked reliably in practice, and folds a decade of operational lessons from receivers and senders back into the base document. Existing DMARC records are not broken by any of this. The v=DMARC1 version tag is unchanged, and the p, sp, rua, ruf, adkim, aspf, and fo tags all retain their existing meaning. Major email service providers have described the update as a clarification of practices most senders already follow, not a mandate to rebuild DNS records this week.
Why it matters even without an urgent deadline
The timing is what gives DMARCbis practical weight. 2026 is the first year all three dominant consumer mailbox providers reject unauthenticated bulk mail outright rather than routing it to spam, and current adoption data shows only around 16 percent of domains have any DMARC record at all, with just roughly a third of those set to the enforcing p=reject policy that actually stops spoofed mail. An organisation that has never revisited its DMARC configuration since first publishing a record is a strong candidate for problems the DNS tree walk change was specifically built to catch, particularly if it operates under a country-code or multi-level domain structure typical of European business registration.
Becoming an IETF Standards Track protocol also changes the conversation for compliance teams. NIS2 and DORA do not name DMARC directly, but both directives require demonstrable email and identity controls for in-scope sectors, and auditors increasingly point to DMARC enforcement as evidence of basic email hygiene. A formally standardised protocol, rather than an informational document receivers chose to enforce, is a cleaner reference point to cite in a security policy or a vendor risk questionnaire.
What to actually check
Confirm your DMARC record still resolves correctly under a DNS tree walk if your domain sits on a country-code or multi-level suffix, review whether your policy has ever moved past p=none to actual enforcement, and check that SPF and DKIM alignment covers every subdomain and third-party sender touching your domain, not just your primary marketing platform. None of this requires urgent emergency action, but it is exactly the kind of housekeeping that gets skipped indefinitely without a prompt, and a standard finally becoming official is as good a prompt as any.
If your organisation needs its DMARC, SPF, and DKIM configuration audited against the new standard, or wants help moving from a passive p=none policy to real enforcement without breaking legitimate mail flows, contact Excello Digital. We help European organisations keep their email authentication current as the underlying standards, and the enforcement behind them, keep evolving.