What is DKIM2 and how does it fix DKIM replay and forwarding breakage?
In brief
DKIM2 is an in-progress IETF standard in which each server that handles a message adds its own signature. That chain stops DKIM replay and forwarding loss.

DKIM2 (DomainKeys Identified Mail Signatures v2) is a next-generation email authentication protocol being developed by the IETF's DKIM working group. It builds on DKIM but records the full handling chain of a message, so every server that touches an email adds its own signature. That signed "chain of custody" is designed to close the DKIM replay gap and to keep authentication intact through forwarding and mailing lists, the cases where DKIM and DMARC break down today. DKIM2 is still a draft standard, not a protocol you deploy right now.
At a glance
Quick takeaways
- DKIM2 is an IETF Internet-Draft (
draft-ietf-dkim-dkim2-spec), not a finished standard, expect standardization over roughly the next 12–18 months and first mailbox-provider deployments toward the end of 2026. - Its main goal is fixing DKIM replay and the forwarding/mailing-list breakage that SPF, DKIM, and DMARC handle poorly.
- Each hop that processes a message adds a
DKIM2-Signatureheader, so receivers can verify the whole path, not just the origin. - DKIM2 is crypto-agile (it can carry different algorithms), which is not the same as being "quantum-proof" today.
- You cannot turn DKIM2 on yet; the right action now is to get SPF, DKIM, and DMARC clean so the transition is easy.
What problem does DKIM2 solve?
DKIM2 solves two well-known weaknesses in classic DKIM. Classic DKIM proves that a message was signed by a domain and was not altered in transit, which is valuable but leaves two gaps.
The first is DKIM replay. Because a DKIM signature stays valid as long as the signed content is unchanged, an attacker can take one legitimately signed message and re-send ("replay") it to millions of unintended recipients. The signature still verifies, so the sending domain's reputation absorbs the damage from mail it never meant to send.
The second is fragility across forwarding and mailing lists. When an intermediary modifies a message (a mailing list appends a footer, a forwarder rewrites headers) the original DKIM signature can break, causing DMARC to fail for legitimate mail. ARC exists to patch this today, but it is an add-on rather than part of the core signature.
DKIM2 addresses both by treating email as a chain of hops and signing each one.
How does DKIM2 work?
DKIM2 works by signing a message at every hop rather than only at its origin. Each server that handles the message adds its own DKIM2-Signature header, and the receiver walks the resulting chain instead of checking a single signature.

- Signing at origin: The sending mail server (MTA) uses a private key to sign the message, storing the result in a
DKIM2-Signatureheader rather than the originalDKIM-Signaturefield. - Publishing the public key: The domain owner publishes the matching public key in a DNS TXT record (for example,
selector._domainkey.example.com) so any receiver can retrieve it. - Signing each hop: Every server that handles the message (forwarders and mailing lists included) adds its own
DKIM2-Signature. Taken together, these headers form a verifiable chain of custody from origin to delivery. - Verification and policy: The receiver walks the chain, confirming each step and checking that the authenticated domain aligns with the visible
Fromdomain. A broken or missing link is evidence of replay or tampering.
How DKIM2 differs from DKIM
DKIM signs once, at the origin. DKIM2 signs at every hop and carries policy and alignment information along the chain, with the long-term aim of consolidating the roles that SPF, DKIM, DMARC, and ARC play separately today. The alignment concept from DMARC carries forward: the authenticated identity still has to match the domain a recipient sees in the From field.
For domain owners, the mental model shifts from "did my one signature survive?" to "is the whole delivery path accounted for?" That is what makes replay detection and clean forwarding possible in the same mechanism.
Cryptographic agility, not a quantum cure
DKIM2 is designed to support multiple signing algorithms: RSA, elliptic-curve algorithms such as Ed25519, and, in the future, post-quantum algorithms as they are standardized. The benefit is crypto-agility: moving from an older algorithm to a newer one without breaking mail flow.
It is worth being precise here, because it is a common misconception. Ed25519 is already available in classic DKIM (RFC 8463) and is not quantum-resistant. DKIM2 does not make your email "quantum-proof" today. What it does is make it easier to adopt stronger algorithms, including post-quantum ones, when they arrive, rather than being locked to one cipher.
What DKIM2 means for you today

Because DKIM2 is still a draft, there is nothing to switch on. The most useful preparation is to make your current authentication solid so the eventual transition is boring:
- Get DKIM right first. Publish valid keys, rotate them on a schedule, and protect the private keys. See setting up a DKIM record.
- Align SPF, DKIM, and DMARC. DKIM2 keeps DMARC's alignment idea, so an aligned setup now maps cleanly onto it later.
- Know every sender. Use DMARC reports, RUA and RUF, to inventory the services sending as your domain, so no source is a surprise during migration.
- Watch the standard. DKIM2 is progressing through the IETF; the header names and rules can still change before it is final.
Evidence
Sources and further reading
- draft-ietf-dkim-dkim2-spec: DomainKeys Identified Mail Signatures v2 (DKIM2): the IETF DKIM working group Internet-Draft that defines the per-hop signature chain and its replay protection.
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures: the classic DKIM standard DKIM2 builds on.
- RFC 8463: A New Cryptographic Signature Method for DKIM: adds Ed25519 signing to classic DKIM.
- RFC 7960: Interoperability Issues between DMARC and Indirect Email Flows: the forwarding and mailing-list breakage DKIM2 is designed to address.
Wrapping up
DKIM2 is the DKIM working group's attempt to fix email authentication's structural weaknesses, replay and forwarding breakage, by signing the entire handling chain instead of a single origin signature, while making it easier to adopt stronger cryptography over time. It is not deployable yet, and it is not a quantum-proofing feature. The best preparation is unglamorous: get SPF, DKIM, and DMARC clean and aligned now, so when DKIM2 lands you are already most of the way there.
Questions readers ask
Frequently asked questions
Can I implement DKIM2 today?
Not yet. DKIM2 is an IETF Internet-Draft under active revision, so there is no stable specification to deploy and no mailbox provider enforcing it in production. The productive work now is clean SPF, DKIM, and DMARC.
Does DKIM2 replace DKIM, SPF, and DMARC?
That is the long-term aim (folding replay resistance, per-hop signing, and alignment into one mechanism) but during the transition DKIM2 is expected to run alongside the existing protocols, not flip them off overnight.
Is DKIM2 quantum-resistant?
No, not inherently. DKIM2 is crypto-agile, meaning it can carry post-quantum algorithms once they are standardized. The algorithms shipping in early drafts (RSA, Ed25519) are not quantum-resistant.
How does DKIM2 stop replay attacks?
DKIM2 stops replay attacks by making the delivery path part of what is signed. Every server that handles a message adds a DKIM2-Signature, creating a chain of custody. A replayed message sent to recipients outside its original path produces a chain that does not add up, which receivers can detect and act on.
Will DKIM2 fix DMARC failures on mailing lists?
That is one of its goals. By signing each hop, DKIM2 lets legitimate intermediary changes remain verifiable, which is the problem ARC currently patches for forwarded and list mail.

Written by
Samuel ChenardCEO & Co-Founder, Palisade
Samuel Chenard is the CEO and co-founder of Palisade, agentic DMARC software for IT teams and MSPs, from one domain to thousands.
More from Samuel →


