DKIM2 in 2026: What Email Admins Need to Know

What DKIM2 Is and Why It Exists

DKIM, DomainKeys Identified Mail, has been a core email authentication standard since 2007. It works by attaching a digital signature to outgoing messages. Receivers verify the signature using a public key published in DNS. If the signature checks out, the message has not been tampered with in transit.

DKIM2 is a draft revision of that spec, currently being developed through the IETF. It keeps the core signing concept but adds features that address a fundamental problem with the original design: DKIM signatures break whenever any intermediate system modifies the message — a mailing list adding a footer, a forwarder reformatting the body, any header insertion. When the signature breaks, authentication fails even for legitimately sent mail.

DKIM2 is expected to reach broad deployment no sooner than 2027–2028, depending on working group review cycles and the RFC publication process. It is not something to implement today. But it is something to understand, because it will eventually change how email authentication works for everyone.

Chain of Custody - Ordered Signatures Instead of One Breakable Signature

Current DKIM uses a single signature. That signature breaks the moment any intermediate system modifies the message. DKIM2 replaces this with an ordered chain of signatures. Each intermediate handler — each MTA, mailing list, or forwarding service — adds its own signature with a sequence number (i=1, i=2, etc.). The final verifier can see the entire chain and confirm that each signer was authorized, even if the message changed between signatures.

This is the direct replacement for ARC (Authenticated Received Chain), which solved the same problem using a separate header chain rather than integrated signatures. DKIM2's approach is more compact — it does not require receivers to maintain a separate validation state alongside the standard authentication result.

Message-Instance Headers - Reconstructing Message State

DKIM2 introduces Message-Instance headers. These are JSON instructions, base64-encoded, that describe modifications made to a message and in what order. A verifier can use these instructions to reconstruct the message state at any point in the chain. This means a DKIM2 signature can survive modifications that would invalidate a standard DKIM signature — the verifier can work backward through the recipe and confirm the signature was valid before the modification happened.

This matters most for mailing lists and forwarding services, which routinely modify messages in ways that break DKIM today.

Replay Defense - Binding Signatures to the SMTP Envelope

DKIM2 adds two new tags that bind each signature to the actual SMTP envelope:

mf= — binds to the MAIL FROM value at signing time
rt= — binds to the RCPT TO value at signing time

A message captured and resent to different recipients fails verification because the envelope values no longer match. This closes the replay attack vector where a valid signed message is intercepted and used to authenticate copies sent to other recipients.

DKIM2 also introduces four explicit signer intent flags:

donotexplode — the signer did not authorize forwarding or expansion
donotmodify — the signer did not authorize any modifications
exploded — the message was legitimately modified by an authorized intermediate
feedback — the signer wants to receive authentication result reports

These flags make the signer's intent explicit and machine-readable, replacing the informal signaling that currently happens through ad-hoc header additions.

Bounce Handling - Smarter DSN Routing

Current DKIM has no mechanism for routing bounces back through the actual chain of handlers that touched a message. This is a contributor to backscatter — bounce notifications sent to forged From addresses.

DKIM2 specifies that bounces trace back through the MTAs that actually handled the original message, using the chain of signatures as the path. Bounces go to the last legitimate signer rather than to a potentially forged From address.

Crypto - SHA-256 Required, Ed25519 Available

DKIM2 mandates SHA-256 as the hash algorithm. The original DKIM spec allowed SHA-1, which is now considered too weak.

Two signing algorithms are available:

RSA-SHA256 - the current standard, updated to require SHA-256
Ed25519-SHA256 - a modern elliptic curve algorithm producing much shorter signatures while maintaining strong security

There is no version tag in DKIM2. Verifiers are expected to recognize DKIM2 signatures by their structure rather than a version field.

What This Means for Your Current DKIM Setup

For most organizations, DKIM2 is a future consideration. Your existing DKIM setup will continue working. DKIM2 is backward-compatible in the sense that older receivers will see the additional DKIM2-specific headers and process the standard DKIM signature if present.

When DKIM2 becomes deployable, migration will involve:

Adding DKIM2 signing keys (Ed25519 is likely the practical choice for new deployments) alongside existing RSA keys
Updating signing systems to produce DKIM2-style chain-of-custody signatures for outbound mail
Verifying that receivers and filtering systems can handle the new header formats

The DNS infrastructure is similar enough to current DKIM that DKIM2 selectors can coexist with existing DKIM selector records - no immediate DNS changes required at sign-up.

When Is DKIM2 Expected to Arrive?

The IETF draft is still in active development. Current estimates place broad deployment no sooner than 2027–2028. Early implementation by large providers (Google, Microsoft, Fastmail) may come earlier, similar to how BIMI adoption preceded broad standardization.

For practical planning purposes, treat DKIM2 as something to evaluate in 2026–2027. Keep your existing DKIM setup healthy, and monitor your vendor's DKIM2 roadmap.

But, how do you actually know if your DKIM setup is healthy? Answere: your DMARC aggregate reports. Every receiver processing your mail sends back a report showing whether your messages passed DKIM alignment, which IP sent them, and whether the signing domain matched your From domain. These reports are machine-generated XML - reading them manually at any scale isn't realistic.

That gap between understanding DKIM and monitoring it is where tooling matters. DMARCFlow processes those aggregate reports and shows you your DKIM alignment pass rate by domain, flags cases where your sending platform is signing with its own domain rather than yours, and checks whether your DKIM selector is actually resolving correctly in DNS. If your DKIM setup has a problem today, that's where you'd see it, before it compounds when you're also managing a DKIM2 transition.

FAQ

Will DKIM2 replace DKIM? Eventually yes, but the transition will be gradual. DKIM2 signatures will coexist with DKIM signatures for years as senders and receivers update their systems. The core signing concept is the same; the main difference is the chain-of-custody model and replay defense.

Can I implement DKIM2 now? The spec is still in draft. No widely deployed DKIM2 verification systems exist yet. Implementing DKIM2 signing before receivers can verify it provides no authentication benefit and adds complexity to your mail flow.

What do I need to do to prepare for DKIM2? Nothing urgent. Keep your existing DKIM setup healthy. When your email platform or vendor adds DKIM2 support, evaluate it then. Your existing DNS records will not need immediate changes.

Does DKIM2 fix the mailing list problem with DKIM? Yes — this is the primary design goal. DKIM2's chain-of-custody model means a mailing list can add its signature without breaking the original sender's signature. Verifiers evaluate the full chain and assess each link independently.

Is DKIM2 related to BIMI or DMARC? DKIM2 is a revision of the DKIM signing layer. It works alongside DMARC (which defines how receivers act on authentication results) and does not directly affect BIMI (which uses DKIM for logo verification). DMARC reports will show DKIM2 results once the standard is in active use.