DKIM2: The Future of Email Authentication Is Taking Shape

What DKIM Still Can't Prove

DKIM today can prove that a domain signed some version of a message, but it still cannot establish three critical things:

• Who the message was for. A valid signature carries no proof that you were an intended recipient. A correctly signed message can be captured and replayed to millions of other addresses, still passing authentication and riding on the original signer's reputation.
• Where the bounces go. A message's return path can name a domain that never handled it, so bounces, abuse reports, and delivery notifications cannot be trusted or traced back.
• What changed in transit. When a forwarder or mailing list edits a message, the signature simply breaks, with no way to tell an innocuous subject or footer tweak from wholesale replacement by a bad actor.

A New Approach: Accountability at Every Hop

DKIM2, currently being developed within the IETF DKIM working group, addresses these gaps. Rather than relying solely on a single signature created by the original sender, DKIM2 makes every hop on the delivery path accountable, adding its own authenticated contribution to the message's history and creating a verifiable chain that records how the message was processed and which systems handled it along the way.

This matters because modern email frequently passes through multiple systems (forwarding services, mailing lists, security gateways, content-processing infrastructure) and DKIM2 is designed so that authentication information stays meaningful throughout that journey, rather than treating any modification as an immediate failure of the original signature.

The Mechanics: MI Headers and Chained Signatures

Two mechanisms make the chain-of-custody model work:

• Message-Instance (MI) headers: a hash snapshot of the message at each hop.
• Chained DKIM2-Signature headers: each hop signs the current snapshot and every prior signature, forming a tamper-evident chain from author to recipient.

What Each Hop Guarantees

At every hop on the delivery path, DKIM2:

• Binds the message to where it is going. The next hop and recipient are inside the hop's own signature, so a signed message cannot be replayed somewhere else. (Solves: who it was for.)
• Records what it changed, as a reversible recipe, so the next hop can undo the change and re-check every earlier signature. This also makes it possible to distinguish legitimate processing by trusted intermediaries from malicious tampering, which breaks the chain. (Solves: what changed.)
• Promises to carry control messages back to the previous hop for a reasonable time, giving bounces and abuse reports a trustworthy return channel. (Solves: where the bounces go.)

Together, these guarantees also strengthen replay protection: a message signed for one destination cannot simply be reused for another.

Rethinking Trust, Not Just Signing

The goal is not simply to replace DKIM with a new signing algorithm, but to rethink how trust is established across an increasingly complex email ecosystem. Instead of asking only whether a message matches the signature applied by the original sender, the broader objective is to give receiving systems a complete, verifiable picture of a message's provenance and handling history.

Where DKIM2 Stands Today

DKIM2 remains in the standardization process. It is an active Internet-Draft, not yet a finished standard and details may still change. It is not a protocol that senders should deploy or rely on at this time.

Existing DKIM implementations remain the industry standard. Organizations should continue focusing on:

• Strong DKIM key management
• Using 2048-bit keys where possible
• Maintaining alignment with DMARC
• Monitoring authentication results

For now, DKIM2 should be viewed as a promising next step: a potential solution to some of email authentication's oldest challenges, still being shaped by the industry and the IETF standardization process.

For more details, visit dkim2.com.