DKIM2 best practices draft: what email senders should do now

The June 18, 2026 working group draft points toward better handling of forwarding, mailing lists, replay, and message custody, but production senders still need healthy DKIM, SPF, and DMARC first.

The DKIM2 best practices draft published by the IETF DKIM working group on June 18, 2026 is a useful standards signal for email authentication teams, but it is not a migration deadline. As of June 21, 2026, draft-ietf-dkim-dkim2-bcp-00 is an active Internet-Draft, not an RFC, and not a current mailbox provider requirement. The practical move is still clear: keep DKIM signing reliable, use domains you control, verify selectors, monitor DMARC aggregate reports, and track DKIM2 as standards work.

That distinction matters because DKIM2 is about real operational pain. Forwarding can break SPF because the final receiver sees the forwarder’s IP address. Mailing lists and gateways can break DKIM by changing signed headers or body content. Replayed DKIM signatures can make valid signatures appear in delivery patterns the signer did not intend. These are not academic problems. They show up in DMARC reports, spam investigations, and deliverability reviews.

What changed on June 18, 2026

The change was process, not production. The DKIM working group now has its first working group draft describing recommended DKIM2 usage for sending hosts, intermediary hosts, and receiving hosts. That framing is important because email rarely travels in one clean hop from sender to receiver. Forwarders, mailing lists, security gateways, and routing systems often touch messages on the way.

Current DKIM, often called DKIM1 in this context, proves that a domain signed selected parts of a message and that the signed parts still match when the receiver checks them. DKIM2 is pointed at a broader custody model. The direction is that each organization handling the message can add a signed statement about its role, while receivers get more context about path, changes, and responsibility.

In practical terms, the draft is worth following if your team operates mail infrastructure, runs an ESP, manages a forwarding service, maintains mailing lists, or owns authentication policy for a large domain portfolio. A normal sender does not need to add DKIM2 to procurement checklists or production launch gates in June 2026.

Why DKIM2 matters for DMARC

DMARC depends on SPF or DKIM passing in alignment with the visible From domain. SPF alignment can fail after forwarding because the forwarder sends from its own infrastructure. DKIM alignment can fail when an intermediary changes signed content. When that happens, legitimate mail can look unauthenticated even when the original sender did the right thing.

DKIM2 tries to improve that middle part of the mail path. The draft direction includes signed custody records, documented intermediary changes, replay checks, and delivery status notification behavior tied to the actual transmission path. Those ideas could eventually help receivers make better decisions about forwarded and modified mail.

For now, DMARC remains the operational source of truth. A DMARC monitoring workflow still tells you which sources send mail for your domain, which ones pass SPF, which ones pass DKIM, and which ones align with your visible From domain. DKIM2 standardization does not remove that daily work.

What senders should not change

Do not rewrite production mail architecture because a first working group draft exists. Do not weaken a DMARC policy because DKIM2 might eventually help forwarded mail. Do not strengthen a DMARC policy because the draft sounds promising. Policy movement should be based on your own report data, sender inventory, and failure analysis.

• Production mail: keep DKIM signing in place and keep signing with domains you control.
• DMARC policy: base changes on aggregate report evidence, not on DKIM2 alone.
• Forwarders: do not assume mailbox providers are validating DKIM2 signatures in production.
• Compliance: do not treat DKIM2 as a current pass or fail vendor requirement.

The current DNS baseline is still SPF, DKIM, and DMARC hygiene. A simple example looks like this:

selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=BASE64PUBLICKEY"
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Make current DKIM boring

The best response to DKIM2 is not excitement or delay. It is making current authentication boring enough that future protocol changes can be evaluated cleanly. Start with selectors. A DKIM selector identifies the DNS record that contains the public key used to verify a signature. If the selector is missing, malformed, expired, or tied to the wrong sender, receivers cannot validate the signature as intended.

Use a DKIM checker to verify selectors, public keys, and syntax before assuming a source is healthy. Then review whether each sender signs with a domain you own or operate. Opaque shared signing domains make accountability harder and can hide which team owns the fix when authentication breaks.

Key management also matters. DKIM keys should be strong enough for the mail stack and rotated with a process that avoids downtime. If a team runs overlapping selectors during a change, understand double signing before interpreting results. If key length is the question, compare the operational tradeoffs of DKIM key length choices in the context of your providers.

Separate standards tracking from operational fixes

Security and deliverability teams should split the work into two lanes. One lane is standards tracking. Watch the DKIM2 draft, working group discussion, implementation signals, and mailbox provider guidance. The other lane is operational hygiene. Fix current DKIM, SPF, and DMARC failures, especially where forwarding, mailing lists, or unauthorized senders appear in reports.

1. Validate DKIM records for every important sender.
2. Review DMARC aggregate reports for SPF, DKIM, and alignment failures.
3. Identify failures caused by forwarding, mailing lists, or gateway modification.
4. Document sender ownership, selector ownership, and key rotation responsibility.
5. Track DKIM2 maturity without treating it as a deployed requirement.

A broad domain health checker scan is useful before a standards planning session because it catches basic DNS and authentication errors first. DKIM2 will not help if current records are malformed, if important vendors are not signing, or if DMARC reports show unknown sources sending as your domain.

Who should pay attention

Mailbox providers should watch verifier design because receiver behavior will determine whether DKIM2 becomes operationally meaningful. ESPs should keep DKIM reliable and understand how signing domains map to customer identities. Forwarders and mailing list operators should study how DKIM2 describes custody and content changes. Security teams should watch replay risk. Deliverability teams should keep using report data to separate real defects from standards noise.

Smaller sending teams can keep the plan simpler. Treat DKIM failures as production defects. Keep a clean sender inventory across corporate mail, marketing systems, billing tools, support platforms, product notifications, and infrastructure alerts. The smaller sources are often the ones that fail when a DMARC policy moves toward enforcement.

The practical position

The first DKIM2 best practices working group draft is worth attention because it shows where email authentication may be heading. It is not a trigger for emergency DNS changes or vendor pressure. Put DKIM2 on the standards watch list. Put current DKIM health, SPF alignment, DMARC report review, sender ownership, and key rotation on the operational work list.

Reference: Read the detailed Suped article.