News
DMARCbis and DKIM2: the next generation of email authentication is on the way
DMARCbis and DKIM2: the next generation of email authentication is on the way
DMARCbis and DKIM2: The Next Generation of Email Authentication Is Here
2026 marks a turning point for email security: DMARC finally becomes a fully fledged standard with the publication of DMARCbis, while the IETF is preparing DKIM2, a deep redesign of email signing. Here is a closer look at these changes, why they matter for your domain, and how e-securemail is getting you ready for them.
In a world where email remains cybercriminals' primary attack vector, guaranteeing the authenticity of messages has become a fundamental requirement. Domain spoofing, phishing, signature replay: attack techniques exploit the limitations of the historical authentication standards. It is precisely to close these structural gaps that the IETF, the Internet's standards body, has undertaken the overhaul of the two pillars of email authentication: DMARC and DKIM.
DMARCbis: DMARC Achieves Standard Status
Since 2015, DMARC (Domain-based Message Authentication, Reporting and Conformance) has allowed domain owners to publish a policy telling receiving servers how to handle messages that fail SPF and DKIM checks. Paradoxically, the original specification (RFC 7489) only had "Informational" status: DMARC was massively deployed, yet had never actually been an Internet standard.
That has now changed. In May 2026, the IETF published DMARCbis, which replaces RFC 7489 and elevates DMARC to Proposed Standard status. The specification is now carried by three normative documents:
RFC 9989, which describes the core protocol (policies, alignment, organizational domain discovery); RFC 9990, dedicated to aggregate reporting; and RFC 9991, dedicated to failure reporting.
Why DMARCbis Matters
Beyond the symbolism, DMARCbis fixes structural weaknesses identified over more than a decade of operation. The most significant is the removal of the Public Suffix List, the manually maintained external list on which organizational domain determination used to depend. It is replaced by the DNS Tree Walk: domain discovery is now performed through successive DNS queries — autonomous, reliable, and free of any third-party dependency.
DMARCbis also clarifies the policy applicable to non-existent subdomains — a blind spot widely exploited by attackers — through the new np tag, introduces an explicit testing mode (t tag), and removes tags that were sources of ambiguity and misconfiguration (pct, ri, rf). Finally, the new conformance section turns DMARC from a mere checkbox into a genuine operating model: authenticate your mail flows, publish your policy, collect reports, analyze, and remediate.
DKIM2: An End-to-End Chain of Trust
The second undertaking is even more ambitious. DKIM (RFC 6376), the protocol that has cryptographically signed emails since 2007, suffers from limitations that two decades of patches have never resolved: a signature applied only at origin, which breaks as soon as a legitimate intermediary — mailing list, forwarder, security gateway — modifies the message; no proof that the recipient was actually the intended recipient; and above all, the ability to replay a correctly signed message to millions of addresses, a technique now massively exploited by spam and phishing campaigns ("DKIM replay").
DKIM2, currently being standardized within the IETF DKIM working group (draft draft-ietf-dkim-dkim2-spec, on the Standards Track), rebuilds the protocol around one powerful idea: the chain of custody.
What DKIM2 Changes
With DKIM2, every server that handles a message adds its own signature, forming a verifiable chain showing which domains touched the message, in what order, and with what modifications. Legitimate intermediaries precisely document their changes — a footer added by a mailing list, a URL rewritten by a security gateway — so that the recipient can "undo" them and validate the original signature. Signatures are timestamped and bound to the recipient, which neutralizes replay attacks. Delivery status notifications can only be sent to parties actually involved in the transmission, eliminating a classic source of abuse. Finally, DKIM2 features native cryptographic agility, notably paving the way for the transition to post-quantum algorithms.
In short: where DKIM answers the question "was this message signed by this domain?", DKIM2 answers a far richer one — "what path did this message take, who modified it, and were those modifications legitimate?".
e-securemail: Ready for DMARCbis, Ahead of the Curve on DKIM2
At Secuserve, we have been following this standardization work from the outset. The e-securemail platform supports DMARCbis when evaluating your mail flows, and our teams are preparing DKIM2 support so as to be ready as soon as the standard is finalized — with no action required on your side, in keeping with our fully managed, sovereign service model.
One Concrete Action to Take Today
These new standards are only as strong as the foundations they rest on: your DKIM signing keys. In accordance with RFC 8301, 1024-bit RSA keys are now considered too weak. If your domain is still signed with such a key, your e-securemail interface will alert you and let you generate a new 2048-bit key in one click: publish it in your DNS zone under the new selector, then activate it. Your emails remain signed with the current key until the new one is activated — the migration takes place without any interruption.
By strengthening your SPF, DKIM, and DMARC configurations now, you meet the growing requirements of major mailbox providers and prepare confidently for the arrival of DKIM2. Our teams are at your disposal to support you in this process.
For any questions, contact our support team through your ticketing portal or at support@secuserve.com.
References
RFC 9989 — DMARCbis, core protocol: rfc-editor.org/rfc/rfc9989
RFC 9990 — DMARC, aggregate reporting: rfc-editor.org/rfc/rfc9990
RFC 9991 — DMARC, failure reporting: rfc-editor.org/rfc/rfc9991
RFC 7489 — DMARC (historical specification, replaced): rfc-editor.org/rfc/rfc7489
RFC 6376 — DKIM (current specification): rfc-editor.org/rfc/rfc6376
RFC 8301 — DKIM cryptographic requirements (2048-bit keys): rfc-editor.org/rfc/rfc8301
IETF DKIM2 draft — specification: datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec
IETF DKIM2 draft — motivation: datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-motivation