DKIM2: What It Changes and What It Means for Senders

DKIM2, the planned replacement for DKIM, the standard that signs and verifies email, has reached its next public milestone. The IETF working group rewriting it published the latest version of the specification draft on May 17, 2026, and is on track to advance the standard toward formal approval over the next 12 to 18 months. This article unpacks what DKIM2 changes about email signing, why the IETF is rebuilding the standard now, and what (if anything) the change asks of domain owners running DMARC today.

DKIM (DomainKeys Identified Mail) is what tells a receiving inbox provider whether a message claiming to come from your domain has been altered or forged in transit. It is one of the two cryptographic checks DMARC depends on (the other is SPF). DKIM has been the email industry's signing standard since 2007. The IETF is openly proposing something more ambitious than a patch: a full redesign that addresses three problems DKIM has never been able to fix on its own.

Read on or click the links to skip down to a specific section.

• What DKIM Does, and Where It Falls Short
• What DKIM2 Changes
• Why Is the IETF Rebuilding DKIM Now?
• What Does Your DKIM Look Like Today?
• What This Means for You
• The Timeline for DKIM2 Implementation
• The Takeaway

What DKIM Does, and Where It Falls Short

DKIM (DomainKeys Identified Mail, defined in RFC 6376) works by attaching a cryptographic signature to every outbound email. The sending domain publishes a public key in DNS, and the receiving server uses the public key to verify the signature. If the signature matches, the receiver can trust two things: that the message was sent by someone with access to the domain's private key, and that the body and selected headers were not modified in transit.

The mechanism has three known weak points, and the IETF DKIM working group has documented all three in the DKIM2 motivation draft (draft-ietf-dkim-dkim2-motivation):

• Replay attacks work against DKIM. A DKIM signature is valid for any recipient. A spammer who captures one signed message (from a compromised account, or by signing up to a newsletter from a high-reputation domain) can resend it to millions of recipients, and every copy still passes DKIM verification. The original signing domain takes the reputation hit.
• Mailing lists and forwarders break the signature. Any intermediary that modifies the message body, even subtly (a list-name prefix on the subject, a footer, a content-transfer-encoding change), invalidates the DKIM signature. The receiver sees a DKIM failure and often a DMARC failure, even though the message is legitimate.
• Intermediary changes leave no audit trail. When DKIM fails on a forwarded message, the receiver has no protocol-level way to tell whether the failure was caused by an honest forwarder making a benign change or by a hostile actor tampering with content.

These weak points show up in real authentication data. In the DMARCeye Q1 2026 industry report, DKIM failure rates at large mailbox providers and enterprise mail systems run high: 19.6% at Microsoft, 11.1% at Google, 26.3% at Proofpoint, 22.9% at Mailgun. Best-in-class transactional senders in the same dataset (Bird, Amazon SES, SendGrid) post DKIM failure rates below 1%. The gap between the two groups is the operational reality DKIM2 is being designed to address.

As the Q1 report itself notes, high failure rates at major mailbox providers are almost always a customer-side configuration problem, not a flaw with the provider itself. Outbound mail flowing through a Microsoft 365 or Google Workspace tenant runs through forwarders, mailing lists, third-party relays, and legacy on-premises gateways. Any one of those can break the DKIM signature without the customer realizing it.

A reasonable hypothesis is that the dedicated transactional senders post the cleanest numbers because their entire business is sending one type of mail through one signing pipeline. General-purpose mailbox providers, by contrast, handle a much wider variety of mail flows that the original DKIM spec was never designed to keep intact. A deeper breakdown of compliance rates by ESP walks through the same pattern from the sending side.

What DKIM2 Changes

DKIM2 keeps the same basic idea - sign every outgoing email so the receiver can verify it came from your domain - but rebuilds how the signing works. The current specification draft (draft-ietf-dkim-dkim2-spec-02, published May 17, 2026, on the standards track) introduces four substantive changes.

Every server in the delivery chain signs the message. When you send an email today, only your sending server signs it. If anything in the middle of the delivery path touches the message - a corporate auto-forwarder, a mailing list that adds a subject prefix, an email security gateway that modifies headers - the original signature breaks, and the receiving inbox has no way to tell what changed or who changed it. DKIM2 changes this. Every mail server that handles the message adds its own signature, so the receiver ends up with a verifiable chain showing which domains touched the message and in what order. The chain-of-custody idea was previewed by the Authenticated Received Chain protocol (ARC, defined in RFC 8617), an experimental add-on now being retired in favor of DKIM2.

The signature is bound to the actual recipients of the message. DKIM today signs the email's contents (the body and a selected set of headers) but does not include who the email is being sent to. This is why a spammer who captures one signed message can resend it to millions of other people, and every copy still passes the signature check. DKIM2 fixes this by also signing the routing envelope: the MAIL FROM address (the sender) and the RCPT TO addresses (the recipients) the message was sent to. A captured DKIM2-signed message resent to a different recipient list immediately fails verification, because the recipient addresses in the envelope no longer match what the original signer signed.

Any server that modifies the message in transit leaves a written record of what it changed. When a mailing list adds a "[list-name]" prefix to your subject line or appends a footer to your message body, it silently breaks the original DKIM signature today, and the receiver has no way to tell whether the change was a benign edit or a hostile modification. DKIM2 lets the modifying server attach a small machine-readable note describing what it changed. The receiver software undoes each recorded change, reconstructs the original message, and verifies the original signature against the reconstruction. The format of the change notes is specified in a separate companion draft.

Bounce messages get signed too, so they cannot be forged. If you have ever received a bounce notification for an email you never sent, you have seen "backscatter": a spammer forged your sender address, the receiving server tried to deliver the message, could not, and bounced it back to you instead of the spammer. DKIM2 stops this by requiring bounce messages themselves to be cryptographically signed by the receiving server. A bounce can only be sent from a domain that originally received the message, and can only reach a domain that originally sent one.

Why Is the IETF Rebuilding DKIM Now?

The DKIM working group is candid about the reason: the earlier attempt to add chain-of-custody handling on top of DKIM did not reach the deployment levels needed to be reliable. ARC, published in 2019 as RFC 8617, was the IETF's first answer to the mailing-list and forwarder problem. ARC let intermediaries attest to the authentication state of a message at the moment they handled it, in theory letting downstream receivers trust the chain even if DKIM itself broke en route.

In practice, ARC remained an experimental specification with patchy adoption. The DKIM2 motivation draft says explicitly that the new standard is being built "based on the lessons learned from implementing the ARC experiment." ARC is now scheduled for reclassification as Historic in a separate IETF draft. DKIM2 is the consolidated, production-grade version of the same chain-of-custody idea, redesigned to be deployable as a core replacement for DKIM rather than an optional add-on.

The DKIM working group is doing the same kind of generational housekeeping that the DMARC working group is doing with DMARCbis, the planned update to DMARC itself. Both standards came out of the 2007-to-2015 era of email authentication, both have a decade-plus of operational experience showing where the original specs fell short, and both are being rewritten now with that experience in hand.

What Does Your DKIM Look Like Today?

Whatever DKIM2 looks like when it ships, the DKIM record you publish today still has to be correct. A misconfigured DKIM record is the most common reason mail from a legitimate sender ends up failing authentication, and (per the Q1 2026 data above) failure rates at the major mailbox providers are higher than most domain owners realize.

Enter your domain below to check what your published DKIM record looks like and whether it is set up correctly.

What This Means for You

How much DKIM2 matters to you depends on the role you play in the email ecosystem.

If you operate a single domain or run a small business: nothing changes for you today. Your DKIM record keeps working. Mailbox providers will continue to verify DKIM1 signatures for years after DKIM2 publishes, and your domain will not be expected to publish DKIM2 records until the major providers signal they are checking for them. Focus on getting your current DKIM right: one key per sending source, key rotation on a schedule, and alignment with your DMARC policy.

If you run an e-commerce store and depend on transactional email reaching the inbox, the Q1 2026 failure rates above are the more immediate concern. DKIM is the authentication method most likely to fail at the mailbox providers your customers use, and the failures happen because of operational details (forwarders, mailing lists, key rollover gaps) that have nothing to do with the DKIM2 standard. If you do not yet have DKIM monitoring in place, DMARCeye's free plan covers one domain with full report parsing, which is enough to see whether your DKIM is signing reliably.

If you are an agency or MSP managing domains for clients: DKIM2 is a multi-tenant transition that will eventually need coordinating across your portfolio. DMARCeye scopes each client account independently, including for the Model Context Protocol integration that lets you query authentication posture programmatically. Your team can monitor DKIM posture across many client domains from a single console while each client still sees only their own data. The visibility infrastructure you have today is what will carry the transition when it lands.

If you run enterprise mail infrastructure: watch the deployment profile draft (draft-moccia-dkim2-deployment-profile, published April 2026). The deployment profile draft describes how DKIM2 can be implemented through the existing milter interface most Mail Transfer Agents already support, without modifying the MTA core. The implication is that DKIM2 is being designed to drop into existing mail stacks rather than require a full rewrite. Take a key inventory now and identify which sending paths you would migrate first.

The Timeline for DKIM2 Implementation

DKIM2 is not a published RFC, and it is not close to being one. The main specification is at revision 02 as of May 17, 2026. IETF Internet-Drafts expire after six months, so the current revision needs to either advance or be republished before November 2026. Several supporting drafts (motivation, DNS specification, best current practices, deployment profile) are moving in parallel.

Even on an aggressive schedule, RFC publication is typically 12 to 18 months from a stable specification draft. Mailbox-provider adoption then takes years more: DMARC itself was published as RFC 7489 in 2015 and is still not universally enforced. Realistically, DKIM2 will not be the default for outbound mail until the late 2020s at the earliest.

The work worth doing in 2026 is making sure DKIM1 is correctly configured for every domain you care about. The new spec does not change that.

The Takeaway

DKIM2 is an honest rebuild of email signing that addresses the replay, accountability, and intermediary-modification gaps the IETF has documented over the standard's nearly 20-year lifespan. It carries forward what worked about ARC, drops what did not, and is being designed to be deployable inside existing mail stacks. None of this asks anything of domain owners today, but the visibility infrastructure you put in place now is what will carry you through the eventual transition.

If you are already running DMARC monitoring, what you can do today is verify your DKIM signatures are passing reliably and that your record is set up correctly. DMARCeye parses the DMARC reports your domain receives and shows you, in plain language, where DKIM is passing, where it is failing, and what is causing the failures, without requiring you to read the raw XML yourself.