IETF DKIM working group publishes first DKIM2 best practices draft
News
Matthew Whittaker
Co-founder & CTO, Suped
Published 19 Jun 2026
Updated 19 Jun 2026
9 min read
Summarize with
On 18 June 2026, the IETF DKIM working group published draft-ietf-dkim-dkim2-bcp-00, the first working group draft for DKIM2 best practices. The IETF Datatracker page lists it as an active Internet-Draft, a DKIM working group document, and a document last updated on 18 June 2026.
On 19 June 2026, this is standards work in progress. It is not an RFC, not a deployed mailbox provider requirement, and not a reason to change production mail systems today. I am treating it as a useful signal about where DKIM2 guidance is going, not as a migration deadline.
- What changed: The DKIM working group now has its first working group draft for recommended DKIM2 usage by sending hosts, intermediary hosts, and receiving hosts.
- What did not change: Current production requirements still rely on healthy DKIM, SPF, and DMARC. DKIM2 is not a compliance checkbox.
- Why it matters: DKIM2 is aimed at forwarding, mailing list changes, changed message paths, changed content, replayed DKIM signatures, and safer delivery status notifications.
- Who should track it: Mailbox providers, ESPs, forwarders, mailing list operators, security teams, and deliverability teams should follow the work.
- What to do now: Keep normal DKIM healthy, sign mail with domains you control, monitor DMARC reports, rotate keys where appropriate, and watch DKIM2 standardization.
Draft status
Internet-Drafts are working documents. This draft can change, be replaced, or expire before any RFC outcome. The Datatracker entry lists the draft as active and in working group state, with no telechat date and no responsible Area Director shown on the page.
What changed on 18 June 2026
The change is not that DKIM2 suddenly became mandatory. The change is that the DKIM working group now has a first working group draft that describes recommended DKIM2 behavior for the main parties that handle email. That matters because best practice drafts are where operational expectations start to become concrete.
The draft separates the mail flow into sending hosts, intermediary hosts, and receiving hosts. That is the right framing. DKIM2 is not only about the original sender proving domain control. It is also about what happens after a message leaves the sender's domain, especially when a forwarder or mailing list changes headers, changes body content, or sends the message through a different path.
|
|
|
|---|---|---|
Sending hosts | Sign outgoing mail | Use controlled domains and maintain keys. |
Intermediaries | Document handling | Record forwarding and revision behavior. |
Receivers | Validate chains | Assess signatures, changes, and paths. |
Domain owners | Monitor results | Keep current authentication clean. |
Scope of the first DKIM2 best practices working group draft.
That scope is bigger than current DKIM. DKIM1 verifies that a domain signed selected parts of a message and that the signed parts still match. DKIM2 is being designed around a longer custody model, where each organization that handles a message can add its own signed statement and where receivers can reason about the path a message took.
Flowchart showing a DKIM2 path through sender, forwarder, change recording, receiver validation, and reporting.
Why DKIM2 matters for DKIM and DMARC
DKIM2 matters because current authentication has several known failure modes that show up in real mail. SPF breaks when mail is forwarded through a server that is not authorized by the original sender. DKIM breaks when a mailing list or gateway changes signed content. DMARC depends on SPF or DKIM domain matching, so forwarding and content changes can turn legitimate mail into failed authentication.
ARC tried to preserve upstream authentication results through intermediaries, but DKIM2 is a larger protocol direction. It aims to let intermediaries document what they changed, let receivers validate those changes, reduce replay abuse of valid DKIM signatures, and route delivery status notifications only to parties involved in a message's transmission.
Current pain
- Forwarding: SPF often fails because the final receiver sees the forwarder's IP, not the original sender's IP.
- Mailing lists: Subject tags, footers, and rewritten headers can invalidate DKIM signatures.
- Replay: A valid DKIM signature can be reused in abusive delivery patterns that the signer did not intend.
- Bounces: Delivery notifications can go to a party that did not participate in the final path.
DKIM2 direction
- Custody: Each handling domain can add a signed record of its role in the message path.
- Revision: Intermediaries that change content can document changes for downstream validation.
- Replay checks: Receivers get more information to detect unexpected reuse of signed messages.
- Safer DSNs: Delivery status notifications can be tied to the message custody path.
For DMARC, the important point is continuity. DMARC monitoring remains the source of truth for how your current mail authenticates today. DKIM2 standardization does not remove the need to watch authentication results, identify senders, fix broken DKIM signatures, and move policies carefully.
What not to change today
Do not rewrite your production mail architecture because this draft exists. The draft is important, but it has not created a new operational requirement for senders, mailbox providers, or intermediaries.
No immediate migration
- Production mail: Keep DKIM1 signing in place and keep signing with domains you control.
- DMARC policy: Do not weaken or strengthen policy because of DKIM2 alone. Base policy changes on your own reports.
- Forwarders: Do not assume mailbox providers are validating DKIM2 signatures in production.
- Compliance: Do not add DKIM2 to vendor questionnaires as a current pass or fail requirement.
The production baseline is still straightforward: publish valid SPF, sign mail with DKIM, collect DMARC aggregate reports, investigate unauthenticated sources, and move enforcement only after legitimate mail is accounted for.
Current production DNS baselinedns
selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=BASE64PUBLICKEY" _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
The draft also has open-looking areas, including discussion placeholders and privacy concerns around content change records. That is another reason to avoid production assumptions. Standards work is useful because it exposes hard operational questions before they become requirements.
Practical next steps for senders
The right response is to make your current authentication boring and observable. DKIM2 is future work, but it is pointing at problems that already appear in reports today: broken signatures, forwarding failures, unauthorized senders, and inconsistent domain matching.
- Controlled domains: Sign production mail with domains you own or operate, not with opaque shared domains that hide accountability.
- Record validation: Check selectors, public keys, and syntax with a DKIM checker before assuming a sender is healthy.
- Report review: Review aggregate reports so you know which sources pass SPF, DKIM, and DMARC domain matching.
- Key rotation: Rotate DKIM keys where appropriate and use sensible DKIM key length choices for your mail stack.
- Selector planning: Understand double signing before running overlapping selectors or staged key changes.
- Standards watch: Track DKIM2 drafts, implementation signals, and mailbox provider guidance, but keep production changes tied to deployed behavior.
A broad check is useful before a standards-driven planning session. Run the domain through a domain health checker and fix plain DKIM, SPF, and DMARC errors first. DKIM2 does not help if today's DNS records are already malformed or if important sources are not authenticated.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
I would also make a clean inventory of mail sources. Include corporate mail, ESPs, billing systems, support tools, product notifications, marketing sends, and infrastructure alerts. The sources that feel small are often the ones that fail when a DMARC policy moves toward enforcement.
How to watch DKIM2 without overreacting
There are two different workstreams here. One is operational hygiene for current mail. The other is standards tracking for DKIM2. Mixing them creates churn. Keeping them separate gives security and deliverability teams a clear plan.
DKIM2 action priority
A practical way to separate today's work from future standards tracking.
Do now
Production
Fix current DKIM, SPF, and DMARC failures.
Track now
Standards
Watch DKIM2 drafts and working group progress.
Test later
Pilot
Evaluate implementations only after real support exists.
Do not do
Premature
Treat DKIM2 as a current provider requirement.
Suped's product fits the operational side of that split. For most teams, Suped is the strongest practical DMARC platform because it brings DMARC, SPF, DKIM monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, real-time alerts, blocklist and blacklist monitoring, and deliverability signals into one workflow with fix steps.
That matters during a standards transition because the useful question is not whether a future protocol is interesting. The useful question is whether your current mail is signed, domain-matched, monitored, and explainable.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
In practice, a dashboard like this helps separate real production defects from standards noise. If a source is failing DKIM today, fix the selector, signing configuration, or sender authorization. If a forwarded path breaks domain matching, document it and watch the reports. If DKIM2 moves toward broader implementation, the same inventory will tell you where pilots make sense.
Who should pay attention
This draft is most relevant to organizations that operate mail infrastructure or are affected by forwarding and message modification at scale. A normal domain owner does not need to implement DKIM2 today, but the domain owner still benefits from understanding the direction of travel.
|
|
|
|---|---|---|
Mailbox providers | Receiver validation | Track verifier design. |
ESPs | Sender signing | Keep DKIM reliable. |
Forwarders | Path changes | Review handling rules. |
Mailing lists | Content edits | Document modifications. |
Security teams | Replay risk | Watch abuse patterns. |
Deliverability | Authentication failures | Use report data. |
Teams affected by the DKIM2 best practices draft.
For smaller sending teams, the action is simpler: keep a clean source inventory and treat DKIM failures as production defects. If a vendor sends mail for your domain, make sure it signs with a domain that matches your visible From domain or is properly authorized by your authentication plan.
What to do now
The first DKIM2 best practices working group draft is worth tracking because it shows where email authentication standards are heading. It is not a trigger for emergency DNS changes, procurement changes, or production mail changes.
I would put DKIM2 on the standards watch list and put current DKIM health on the operational work list. That means verified selectors, working signatures, controlled signing domains, regular key rotation, clean DMARC reports, and a documented sender inventory.
- Today: Audit existing DKIM records and make sure every important source signs mail correctly.
- This week: Review DMARC aggregate reports and isolate failures caused by forwarding, mailing lists, or unauthorized sources.
- This quarter: Confirm key rotation practices and document which teams own each selector.
- Later: Revisit DKIM2 when the drafts mature and real receiver or sender implementations appear.
