DKIM2 Explained: What Email's New Chain of Custody Means for Senders

For almost twenty years, DKIM has answered one useful question about an email: did a domain sign this version of the message, and has the signed content changed?

DKIM2 wants to answer a larger question: who handled this message, who was it intended for, and what changed at each step of the journey?

That is a meaningful shift. Instead of relying on one signature to survive everything that happens between the sender and the inbox, DKIM2 creates a cryptographically verifiable chain of custody. Forwarders and other participating intermediaries can document their changes, re-sign the message, and pass that history to the next system.

The proposal is designed to address three long-running problems in email authentication:

• Legitimate forwarding and mailing-list changes can break DKIM.
• Attackers can copy and replay a validly signed message to new recipients.
• Forged return paths make delayed bounces difficult to trust and can create backscatter.

But DKIM2 is not a finished standard or a new sender requirement. The latest specification, draft-05, was published on 25 August 2026 and remains an active IETF Internet-Draft. There is nothing most senders need to switch on today.

Here is what DKIM2 proposes, why the industry is working on it, and how to prepare without getting ahead of the standard.

A quick refresher: what DKIM does today

When a system sends a DKIM-signed email, it calculates hashes from the message body and selected headers. It signs those values with a private key and places the resulting DKIM-Signature in the message headers.

The receiving system looks up the corresponding public key in DNS and verifies the signature. A successful check shows that the signing domain took responsibility for that version of the message and that the signed portions have not changed since it was signed.

That model remains extremely useful. DKIM is one of the foundations on which DMARC and modern domain reputation systems operate.

The limitation is that DKIM mostly describes a message, not its complete delivery path. It does not cryptographically bind the signature to the actual SMTP recipient. It also expects signed content to remain stable, even though legitimate systems frequently modify email in transit.

Problem one: legitimate changes break authentication

An email does not always travel directly from the sender’s platform to the recipient’s mailbox. It might pass through:

• A forwarding service
• A mailing list
• A security gateway that rewrites links
• A system that adds a subject prefix, disclaimer, or footer

Each change can alter a signed header or the body. Once that happens, the original DKIM signature may no longer validate.

The modification itself might be harmless, but the final receiver cannot determine that from the broken signature. It sees only that the content it received no longer matches what was signed.

ARC, or Authenticated Received Chain, attempted to preserve information about earlier authentication results. DKIM2 takes a different approach: a participating system can describe the actual changes it made, add a new representation of the message, and sign the updated state.

Problem two: a valid signature can be replayed

A DKIM replay attack starts with a legitimately signed message. An attacker might create an account with a reputable provider, send one message to an address they control, and capture the complete signed email.

They can then resend copies of that unchanged message to many other recipients. Because the content covered by DKIM is still identical, the original signature may continue to validate. The abusive traffic can temporarily benefit from the reputation of the original signing domain.

Classic DKIM cannot reliably say, “this signature was created for this recipient.” DKIM2 is designed to add that missing context.

Problem three: bounces can go to the wrong party

Email bounces and Delivery Status Notifications normally rely on the SMTP envelope sender, commonly called the return path. That value can be forged.

If a receiver accepts a message and later generates a bounce, it risks sending that notification to an innocent address that never transmitted the original email. At scale, those misdirected messages become backscatter.

Because DKIM2 records the handoff between participating systems, it can provide a verifiable route for a delivery notification to travel back through the entities that actually handled the message.

How DKIM2’s chain of custody works

The current draft introduces two important header fields: Message-Instance and DKIM2-Signature.

Message-Instance records versions of the message

A Message-Instance contains hashes representing a particular state of the email. When an intermediary changes signed content, it creates a new instance and can include a machine-readable “recipe” describing how to reconstruct the previous version.

For example, a mailing list might add [Community] to the subject and append a footer. Instead of simply breaking the original authentication, the list can document those modifications and create a new signed state.

A downstream verifier can work backwards through the recorded versions and check whether the earlier signatures were valid for the earlier content.

This does not declare every modification trustworthy. It makes the modification attributable and verifiable, giving the receiver better evidence for its filtering decision.

DKIM2-Signature records each participating handoff

The DKIM2-Signature links the message state to information about its SMTP journey. The current design includes the envelope sender (MAIL FROM) and recipient (RCPT TO) values used for a handoff.

When the next participating system receives the message, it can verify that the actual envelope matches the signed information. If that system forwards or revises the message, it can add the next signature in the chain.

This recipient binding is central to replay resistance. A message copied to an unrelated recipient no longer has a chain that matches the new delivery attempt.

Transparent forwarding that does not alter relevant message or envelope information may not need to create another signature. The important point is that meaningful DKIM2-aware handoffs and revisions can be documented rather than disappearing between the original sender and final receiver.

Timestamps limit the useful life of a captured signature

DKIM2 signatures contain timestamps. The current draft says verifiers should fail a chain when more than 14 days have passed since any signature in it was created.

Recipient binding is the primary protection against delivery-path replay; the time window adds another limit to how long a captured chain can remain useful. This value is part of a working draft and may change.

DKIM and DKIM2 are not interchangeable

The easiest way to understand the difference is by the evidence each protocol gives a receiver.

DKIM provides:

• A signature associated with a domain
• Integrity checks for selected headers and message content
• A stable signal that survives simple, non-modifying relays

DKIM2 proposes to add:

• A sequence of signatures documenting participating handlers
• Signed SMTP sender and recipient information
• Recorded message versions and documented modifications
• Better detection of replay outside the intended delivery path
• A verifiable path for Delivery Status Notifications
• Optional requests for downstream feedback

DKIM2 still uses public-key cryptography and DNS. In the current design, its keys occupy the same selector-based _domainkey namespace as DKIM keys. The major changes therefore sit in mail-signing, forwarding, and verification software rather than in a new policy record that every domain owner must immediately publish.

Will DKIM2 replace SPF, DKIM, DMARC, and ARC?

Not today—and there will not be a flag day when every mail system changes at once.

The IETF’s current DKIM2 best-practices draft recommends that participating senders sign outgoing messages with both DKIM and DKIM2 during the transition. Existing receivers can continue using DKIM, while DKIM2-aware systems evaluate the new chain.

SPF and DMARC remain part of the deployed email-authentication ecosystem. The relationship between mature DKIM2 deployment and those protocols will evolve through implementation experience and additional standards work.

DKIM2 also incorporates lessons from ARC, but it would be premature to remove ARC support simply because DKIM2 is being developed. Production decisions should follow stable specifications and real interoperability between major providers.

Is DKIM2 ready for production?

No—not as a general sender requirement.

As of 26 August 2026:

• The core DKIM2 specification is an active Internet-Draft, not an RFC.
• The draft can be updated, replaced, or abandoned through the standards process.
• Implementation and interoperability experiments exist.
• The current specification still contains unfinished sections.
• No universal mailbox-provider requirement tells ordinary senders to deploy it.

That makes DKIM2 important to follow, especially for ESPs, mailbox providers, forwarding services, mailing-list operators, and teams running their own MTAs. It does not make it a production checkbox for every marketing team.

What email senders should do now

Most senders should prepare their foundations rather than attempt an early rollout.

1. Keep today’s authentication healthy

DKIM2 will not rescue an unmanaged sending estate. Continue to maintain SPF, DKIM, and DMARC; monitor authentication results; rotate signing keys; and make sure every legitimate platform is correctly aligned.

2. Map systems that modify or forward mail

Identify mailing lists, gateways, help desks, inbound forwarding services, and security products that rewrite links, subjects, headers, or message bodies. These are the systems most likely to affect a future DKIM2 chain.

3. Review bounce processing

If you operate sending infrastructure, make sure asynchronous Delivery Status Notifications can be authenticated, correlated to the right message, and processed safely. DKIM2’s bounce model could make trustworthy delayed feedback more useful.

4. Ask providers about their roadmap

If an ESP or transactional provider sends on your behalf, it will likely handle most signing changes. Ask whether it is tracking the IETF work, planning dual signing, and testing verification—but do not treat an estimated launch date as a standardization deadline.

5. Experiment without depending on it

Infrastructure teams can evaluate reference implementations, inspect DKIM2 headers, and test modified-message validation in a lab. Keep experiments isolated from production acceptance policy while the draft is changing.

The bigger shift: from a signature to a journey

DKIM succeeded because it gave email a durable way for domains to take responsibility for messages. DKIM2 does not discard that idea. It extends responsibility across the path an email travels.

If the proposal matures and is widely adopted, a receiver will no longer have to choose between blindly trusting a forwarder and discarding all authentication when legitimate changes occur. It can examine a signed record of who handled the email, what changed, and whether the delivery matches the intended path.

For senders, the immediate advice is deliberately unexciting: keep DKIM, SPF, and DMARC working, understand your mail flow, and watch the standard develop. The interesting work is happening in the infrastructure underneath the campaign dashboard.

At Score, we will continue tracking DKIM2 as the specification changes and translate provider adoption into concrete guidance when there is something senders can safely act on.

Sources and further reading

• IETF — DomainKeys Identified Mail Signatures v2, draft-ietf-dkim-dkim2-spec
• IETF — DKIM2 Best Practices
• IETF — DKIM Working Group
• Word to the Wise — DKIM2: What it means for the future of email
• Valimail — DKIM2: What email senders need to know

DKIM2 is a work in progress. This article describes draft-05 as published on 25 August 2026; implementation details and operational recommendations may change before publication as an RFC.