DKIM2: the DKIM overhaul under way at the IETF

DKIM2 is a set of documents being written in the IETF DKIM working group, rechartered for that purpose in 2025. The goal is to eventually replace DKIM, ARC and part of what SPF and DMARC do with a single chained-signature mechanism. These are drafts (draft-ietf-dkim-dkim2-*): a motivation document and the technical documents that go with it. Nothing is adopted, header names, tags and exact formats may still change, and no mailbox provider requires DKIM2 today. This page describes the direction of the work as it appears in the drafts, not a stable specification.

Why revisit DKIM#

DKIM was designed in 2007 around a simple assumption: a valid signature proves that the d= domain emitted this message. Twenty years of operation have exposed several limits:

• Replay: a DKIM signature remains valid whatever the recipient and, without an x= tag, whatever the date. A message signed by a reputable domain can be re-sent in bulk to other recipients with its signature intact, and the signing domain pays the price.
• In-transit modifications: a mailing list adding a footer or a subject prefix breaks the signature. ARC was bolted on to work around this, at the cost of a trust chain that every provider has to evaluate on its own.
• Bounces: non-delivery notifications go back to MAIL FROM with no cryptographic link to the path the message took, which enables backscatter.
• Layering: SPF, DKIM, DMARC and ARC check different identities with distinct alignment rules, which makes diagnosis hard.

The direction of the drafts#

The documents under discussion converge on the following principles, subject to how the working group evolves them:

• One numbered signature per relay: every server handling the message adds its own signature with a sequence number, much like ARC's i= instance. The full path becomes verifiable, and a relay cannot strip a previous signature without invalidating the chain.
• Binding to the envelope: the signature covers the SMTP session's MAIL FROM and RCPT TO, plus a short-lived timestamp. A message signed for one recipient can no longer be replayed to another, which addresses replay at the root.
• Declared, reversible modifications: a relay that changes the message (footer, subject prefix) must describe the change in its signature so that the recipient can reconstruct the original content and verify the previous signature. Mailing lists would no longer need to rewrite From:.
• Bounces travelling back up the chain: a delivery failure is returned to the previous relay, which returns it to its own predecessor, each checking that it really handled the message. Backscatter becomes impossible without a valid signature.
• Keys published as in DKIM: the public key stays in DNS under _domainkey, which would allow a transition without new key infrastructure.

What a record would look like#

The drafts plan to reuse DKIM's key publication format. The record below is therefore an ordinary DKIM record that DKIM2 could reference as is; DKIM2-specific tags are not settled:

s2026b._domainkey.example.com.  IN TXT  "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="

The signature header itself, named DKIM2-Signature: in the drafts, would carry among other things the sequence number, the envelope identities, the timestamp, the description of modifications and the signature. Its exact format must be read in the current version of the documents.

What to do today#

Nothing specific. Current DKIM good practice prepares the ground: 2048-bit or Ed25519 keys, dated selectors, regular rotation, signing of sensitive headers, an x= tag to bound validity, and monitoring of accounts that could be used for replay. A domain that already publishes its keys under _domainkey and controls its mail streams would, if DKIM2 succeeds, only need to update its signing and verification software.

To follow the work: the DKIM working group's mailing list and documents are public, and every draft version is archived on the IETF Datatracker.

Open questions#

• Timing: adoption as an RFC and then support by mailbox providers will take years.
• Coexistence with DKIM, ARC and DMARC during the transition, and how DMARC will account for a DKIM2 chain.
• Handling of relays that do not participate and break the chain.
• The cost for mailing list operators, who would have to describe their modifications rather than simply apply them.

What SenderRadar shows#

SenderRadar displays no DKIM2 indicator, since the mechanism is not deployed. The elements relevant to a future transition, namely published selectors, key types and sizes, and the consistency of DKIM signatures with the DMARC policy, are presented in the domain's profile. SenderRadar relies on its own analysis base to track how these elements evolve.

References#

• IETF DKIM working group – documents
• DKIM working group charter
• RFC 6376 – DKIM
• RFC 8617 – ARC