DKIM2 explained: what changes and what stays the same
Updated on 9 Sep 2026: We updated this guide for DKIM2 specification draft 06 and RFC 9989.
DKIM2 has not made current DKIM obsolete. It is an active IETF working-group draft, while normal DKIM records, selectors, public keys, private keys, DKIM-Signature headers, and DMARC alignment still matter for real email delivery. Do not remove, replace, or invent DNS records because DKIM2 exists in draft form.
The practical move is simple: keep current DKIM healthy, make sure DKIM passes for every legitimate sender, and use DMARC reporting to spot sources that fail authentication. DKIM2 is worth tracking because it tries to improve how email systems prove the path a message took, especially when message changes, forwarding, mailing lists, replay, and delayed bounces get involved.
- Keep your existing DKIM TXT records because receiving mail systems still use them.
- Do not publish data copied from Internet-Draft examples unless your provider supports an intentional DKIM2 test.
- Use DMARC aggregate data to find senders that fail DKIM.
- Maintain current authentication so future standards are easier to adopt.
What DKIM2 is
DKIM2 is active IETF work on a new email accountability mechanism. It builds on lessons from DKIM, ARC, forwarding behavior, mailing-list changes, replay abuse, and delivery failure handling. The aim goes beyond proving that one domain signed one version of a message. It makes each handling step accountable for the message path.
An early IETF motivation draft described stronger authentication for the delivery path and an asynchronous return channel. The current working-group specification turns that goal into Message-Instance and DKIM2-Signature header fields. Receivers and intermediaries would get better evidence about who handled the message, where it was sent next, what changed, and where a delivery failure should travel.
Work in progress
Treat DKIM2 as standards work, not as a deployment checklist for ordinary domains. Internet-Drafts can change, expire, or be replaced before any final RFC exists. A domain owner should not create draft-based records or headers unless a controlled interoperability test and the mail provider's documentation require them.
That distinction matters because current DKIM is already deployed across real mail infrastructure. If your sender has bad selectors, stale public keys, missing private keys, or unsigned mail, DKIM2 will not fix that today. Make current DKIM reliable before planning around draft header formats.
What problem DKIM2 tries to solve
DKIM survives ordinary forwarding when the signed content remains intact. Harder cases appear when a mailing list or security gateway alters signed content. Replay is another limitation because a captured message can retain a valid signature when it is sent to new recipients. Current DKIM tells the receiver whether a signature verifies, but it gives less help when the message path itself needs accountability.
ARC remains deployed for intermediary authentication evidence while the IETF considers moving the ARC experiment in RFC 8617 to Historic status. DKIM2 uses lessons from ARC but takes a different approach: each transfer adds to a verifiable chain, and a system that changes content can record how to reconstruct the earlier message state.
DKIM2 path accountability across the origin, forwarder, message changes, return path, and final verification.
The main shift is path accountability. The current DKIM2 design asks each participating hop to sign the message state and handling context, declare where it is sending the message next, and preserve information that lets later systems assess changes. That differs from relying on a single origin signature that fails after a mailing list changes signed content.
- DKIM2 records message modifications so earlier message states and signatures can be checked.
- Timestamps, nonces, recipient addresses, and next-domain context make copied signed mail easier to detect.
- Delivery failures can travel back through the authenticated path instead of reaching an unrelated address.
- A participating system can request feedback through the authenticated handling chain.
- Message-Instance hashes cover the body and header fields, apart from a defined set of fields with local or transit meaning.
How the current DKIM2 draft works
The IETF working-group specification reached draft-ietf-dkim-dkim2-spec-06 on 28 August 2026. It is an active Internet-Draft, not an RFC. The separate header draft has been folded into the main specification, and the DNS specification is now a working-group draft. These milestones show active protocol work, but they do not create a production requirement for domain owners.
The design uses two new header fields. Message-Instance carries hashes of the message body and header fields. If a reviser changes signed content, the next Message-Instance can include a base64-encoded JSON Recipe that lets a verifier reconstruct the prior message state. DKIM2-Signature signs the Message-Instance chain and earlier DKIM2 signatures, along with handling data that binds each transfer to its path.
- Message-Instance hashes record the current body and header-field state.
- Recipes describe changes so a verifier can reconstruct and check an earlier message state.
- DKIM2-Signature headers add an ordered sequence, nonce, timestamp, SMTP envelope data, next-domain data, and cryptographic signatures.
- The current draft retains selectors and the selector._domainkey.domain DNS namespace used by DKIM.
A selector literally named "dkim2" or "selector2" is only a selector label. It does not mean the IETF DKIM2 protocol is active. Keep provider-issued selector records in place, but do not infer protocol support from the label.
What stays the same for domain owners
Normal DKIM remains the mechanism receivers check in production. A receiving server reads the DKIM-Signature header, takes the selector and signing domain, looks up the public key in DNS, verifies the cryptographic signature, and reports pass or fail in Authentication-Results. DMARC then checks whether that passing DKIM domain is aligned with the visible From domain.
DKIM today
- Receivers find the sender's public key under the selector.
- The sending service signs mail and keeps the private key secret.
- A DKIM pass helps DMARC only when domain alignment is right.
- Every legitimate sender still needs correct signing.
DKIM2 direction
- Each participating step signs context about the transfer.
- Intermediaries document changes so earlier message states can be checked.
- Delivery failures and feedback can follow the authenticated handling path.
- Production mail cannot turn this draft protocol on through DNS today.
For a current operational check, use a DKIM checker to confirm that your selector resolves to a valid public-key record. That work affects deliverability now.
|
|
|
|
|---|---|---|---|
Status | Deployed | Active IETF draft | Track |
DNS | TXT public key | Same _domainkey namespace | Do not improvise |
Selector | s= tag | Selector remains | Keep rotating |
DMARC | Uses aligned pass | No production input | Monitor |
Current DKIM compared with the active DKIM2 draft.
Selectors, keys, and signatures
A DKIM selector is a label that lets one domain publish more than one public key. If the DKIM-Signature header says the selector is selector1 and the signing domain is example.com, the receiver queries selector1._domainkey.example.com. That DNS TXT record contains the public key. The sending system uses the matching private key to create the signature.
Current DKIM TXT record exampleDNS
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."
The private key never belongs in DNS. It belongs in the sender's email platform or MTA. If that private key leaks, rotate the selector, publish a new public key, and remove the old record after traffic has moved. The current DKIM2 drafts retain selectors, public keys, private keys, and the _domainkey namespace, so DKIM2 does not remove that key-management discipline.
Current DKIM-Signature header shapetext
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; t=1783555200; h=from:to:subject:date:mime-version; bh=base64-body-hash; b=base64-signature
Do not publish draft fields
Draft DKIM2 field names are not a DNS recipe. Publishing made-up DKIM2 data will not make receivers trust your mail. At best it gets ignored. At worst it adds confusion during troubleshooting and gives teams a false sense that future authentication is already handled.
The useful lesson from DKIM2 is to tighten the current system: give every sender its own selector where possible, document which service owns each private key, remove abandoned selectors, and keep DKIM signing tied to the domain that DMARC expects.
DMARC alignment still decides policy results
DMARC does not pass just because a message has any valid DKIM signature. The passing DKIM signing domain needs alignment with the visible From domain, called the Author Domain in RFC 9989, unless SPF passes with alignment instead. Many teams get tripped up when an email platform signs with its own domain, DKIM passes, and DMARC still fails.
Review DKIM alignment before treating DKIM2 as an action item. RFC 9989 now defines the core DMARC protocol, but the operational rule remains the same: at least one authenticated identifier must pass with alignment to the Author Domain. DKIM2 is not an input to production DMARC evaluation today.
DMARC record that checks aligned DKIMDNS
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"
For live domains, DMARC monitoring is the control loop. It tells you which sources are authenticating correctly, which ones are passing only SPF, which ones have broken DKIM, and which ones are pretending to use your domain.
Practical best practice
- List every system that sends mail using your domain.
- Map each selector to the service and team that owns it.
- Move DMARC policy only after legitimate mail is passing.
- Investigate DKIM failures before blaming new standards work.
What to check now
Before spending time on DKIM2 planning, check the basics that affect mail now. Confirm that each sender signs mail, the selector resolves, the public key is valid, the signing domain matches your DMARC expectations, and the message survives any forwarding or gateway path your organization actually uses.
A broader domain health check is useful because DKIM rarely fails in isolation. SPF lookup limits, missing DMARC reporting, weak policy, DNS typos, and sender misconfiguration often appear together.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Send a real test message through each important system, then inspect the received headers. DNS can look correct while the sender still signs with the wrong domain, uses a stale selector, or skips DKIM on one message stream.
If you use double signing or multiple signatures, document why each signature exists. Multiple signatures are valid, but they make troubleshooting harder when one passes and another fails. Clear ownership and scheduled review of live authentication results make those signatures easier to manage.
Where Suped fits
Suped is our DMARC reporting and email authentication platform. Its role here is operational: build a sending-source inventory, find current DKIM and alignment failures, and stage DMARC policy changes without treating a draft protocol as a production control.
In Suped's product, DMARC reports group authentication results by source so a team can locate broken DKIM or alignment and confirm the result after a DNS or platform change. Alerts bring new failures into that workflow without requiring the team to decode raw aggregate XML.
While DKIM2 develops, use Suped for evidence about the deployed authentication system. Suped does not verify a DKIM2 chain or indicate that a provider supports the draft protocol. Provider guidance and a finished standard will determine when production deployment work starts.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
The screenshot workflow matters because DKIM2 will not remove the need for clear diagnostics. If a selector is missing, a public key is malformed, or a sender is failing DMARC alignment, the immediate task is to find the broken source and repair the current configuration.
A practical rollout posture
Treat DKIM2 as a future compatibility track, not a reason to freeze current authentication work. Current DKIM contributes to sender reputation and DMARC policy results. It also helps receivers resist domain abuse. Waiting for DKIM2 while ignoring broken current DKIM is the wrong tradeoff.
DKIM2 readiness posture
Use these thresholds to decide what action makes sense today.
Do now
Operational
Fix current DKIM failures and DMARC alignment issues.
Watch
Standards
Track working-group drafts and provider announcements.
Avoid
Risk
Do not create unofficial DKIM2 DNS records or custom headers.
Plan
Process
Keep selector ownership and key rotation records easy to audit.
For technical teams that run MTAs, DKIM2 deployment will require mail-server support for signing, header verification, recipes, and feedback handling. This work extends beyond a DNS update. The deployment profile draft helps explain why rollout needs mail-server integration.
For domain owners and marketers, preparation is less technical: know who sends mail, keep DKIM pass rates high, enforce DMARC gradually, and require vendors to use aligned DKIM. A clean sender inventory and healthy current authentication will reduce disruption when a future standard becomes deployable.
What to do next
Treat DKIM2 as a sign that email authentication work is moving toward per-hop accountability. Current DKIM records remain important, private keys still need protection, selectors still need owners, and aligned DKIM still contributes to DMARC.
- Audit every sending source now and confirm aligned DKIM for legitimate mail.
- Rotate weak or abandoned selectors this quarter and document private-key ownership.
- Before enforcement, use DMARC reporting to verify that real mail survives policy tightening.
- While DKIM2 evolves, follow provider guidance and avoid custom draft-based DNS changes.
Domain owners and email teams should track DKIM2 while spending current effort on the authentication controls that receivers already enforce.
