DKIM2 explained: what changes and what stays the same
DKIM2 does not make current DKIM obsolete. Normal DKIM records, selectors, public keys, private keys, DKIM-Signature headers, and DMARC alignment still matter for real email delivery today. I would not remove, replace, or invent DNS records because DKIM2 exists in draft discussions.
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 forwarding, mailing lists, replay, and delayed bounces get involved.
- Keep DKIM: Your existing DKIM TXT records are still used by receiving mail systems.
- Avoid draft DNS: Do not publish a homemade DKIM2 record copied from draft examples.
- Watch reports: DMARC aggregate data still shows which senders pass DKIM and which ones need work.
- Prepare calmly: Good current authentication hygiene gives you the cleanest path for future standards.
What DKIM2 is
DKIM2 is proposed work for a new email accountability mechanism. It builds on lessons from DKIM, ARC, forwarding behavior, mailing-list changes, replay abuse, and delivery failure handling. The idea is not just to prove that one domain signed one message at one point in time. It tries to make each handling step more accountable for the message path.
The original IETF motivation draft describes DKIM2 as a way to add stronger authentication to the delivery path and support an asynchronous return channel. In plain terms, that means receivers and intermediaries get better information about who handled the message, where it was meant to go next, and where failure or feedback 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 a DKIM2 TXT record unless a finished standard and their mail provider's documentation require it.
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. The right preparation is to make current DKIM reliable before worrying about future header formats.
What problem DKIM2 tries to solve
DKIM works well when the message is signed by a legitimate sender and arrives without changes. The harder cases appear when another system forwards the message, a mailing list edits the subject or body, a security gateway rewrites content, or a signed message gets replayed at scale. Current DKIM often tells the receiver whether a signature still verifies, but it gives less help when the message path itself needs accountability.
Infographic showing DKIM2 path accountability across email hops.
The main shift is path accountability. A DKIM2-style design asks every hop to sign what it received, declare where it is sending the message next, and preserve enough information for later systems to reason about changes. That is different from a single origin signature that breaks when a mailing list modifies content.
- Forwarding changes: DKIM2 work tries to describe message modifications so earlier signatures can still be assessed.
- Replay control: The design adds timestamps and destination context to reduce the value of copied signed mail.
- Bounce handling: Delivery failures can travel back through the authenticated path instead of surprising an unrelated address.
- Feedback routing: Senders and intermediaries get a cleaner way to request and receive quality signals.
- Header consistency: The proposal reduces optional signing choices that make DKIM verification harder to reason about.
What stays the same today
Normal DKIM remains the thing receivers check today. A receiving server still 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 into authentication results. DMARC then cares whether that passing DKIM domain has alignment with the visible From domain.
DKIM today
- DNS lookup: Receivers find the sender's public key under the selector.
- Private key: The sending service signs mail and keeps the private key secret.
- DMARC result: A DKIM pass helps DMARC only when domain alignment is right.
- Operational need: Every legitimate sender still needs correct signing.
DKIM2 direction
- Path proof: Each handling step signs more context about the route.
- Change detail: Intermediaries describe changes instead of silently breaking trust.
- Return channel: Failure and feedback can follow the authenticated handling path.
- Deployment state: This is not a replacement you can turn on through DNS today.
If you want a current operational check, use a DKIM checker to confirm that your selector, public key, and DNS syntax are valid. That is the work that affects deliverability now.
|
|
|
|
|---|---|---|---|
Status | Deployed | Draft work | Track |
DNS | TXT key | No DIY | Keep |
Selector | s tag | Key id | Rotate |
DMARC | Uses pass | No change | Monitor |
Compact view of current DKIM versus DKIM2 direction.
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 signing system, usually an email platform, MTA, or gateway. If that private key leaks, rotate the selector, publish a new public key, and remove the old record after traffic has moved. DKIM2 does not remove that basic 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 a made-up DKIM2 TXT record 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 not to invent new records. It 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 signature needs domain alignment with the visible From domain, unless SPF passes with alignment instead. This is where many teams get tripped up: their email platform signs with its own domain, DKIM passes, and DMARC still fails.
I would review DKIM alignment before treating DKIM2 as an action item. DKIM2 discussions do not change the way receivers enforce current DMARC policy today. If a sender cannot produce aligned DKIM now, it still creates enforcement risk when you move to quarantine or reject.
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
- Source inventory: List every system that sends mail using your domain.
- Selector ownership: Map each selector to the service and team that owns it.
- Policy staging: Move DMARC policy only after legitimate mail is passing.
- Failure review: 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.
I also 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. The safest operating model is clear ownership, clear selector naming, and regular review of live authentication results.
Where Suped fits
Suped is the best overall DMARC platform for most teams that need day-to-day authentication operations, because the work is not just publishing one record. The work is finding every sender, seeing failures early, understanding the fix, and moving policy without blocking real mail.
In Suped's product, DKIM remains part of the live authentication workflow. You can monitor DMARC, SPF, and DKIM together, review verified and unverified sources, receive real-time alerts, and use issue detection that explains what to fix instead of leaving raw aggregate XML for the team to decode.
That is the right posture while DKIM2 develops. Track the standard, but operate the deployed system. Hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, and multi-tenant reporting help teams manage authentication without turning every DNS change into a manual project.
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 still to find the broken source and repair the current configuration.
A practical rollout posture
The safest way to think about DKIM2 is as a future compatibility track, not a reason to freeze current authentication work. Current DKIM is part of your sender reputation, DMARC policy outcome, and abuse resistance. 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, source gaps, and DMARC alignment issues.
Watch
Standards
Track drafts, provider announcements, and mailing-list behavior.
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, the eventual DKIM2 story will likely involve software updates, signing behavior, header verification, and feedback handling. It will not be just one DNS change by a marketing admin. The deployment profile draft is useful for understanding why rollout will need mail-server integration rather than a quick DNS paste.
For domain owners and marketers, the best preparation is less exotic: know who sends mail, keep DKIM pass rates high, enforce DMARC gradually, and keep vendors accountable for aligned DKIM. When a future standard becomes deployable, a clean sender inventory and healthy current authentication will make adoption less disruptive.
What to do next
I would treat DKIM2 as a signal that email authentication is becoming more accountable, not as a signal that current DKIM is dead. Existing DKIM records remain important. Existing private keys still need protection. Existing selectors still need ownership. Existing DMARC alignment still decides whether DKIM helps your policy result.
- Today: Audit every sending source and confirm aligned DKIM for legitimate mail.
- This quarter: Rotate weak or abandoned selectors 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.
That gives domain owners, IT admins, marketers, and deliverability teams the right balance: stay informed about DKIM2, but spend current effort on the authentication controls receivers already enforce.
