Summary

  • Revision 01 of the DKIM working group’s Best Practices draft became available on 9 September 2026. It is an active Internet-Draft, not a BCP, RFC, deployment census or IETF retirement decision.
  • The draft says signers should apply both DKIM1 and DKIM2 until DKIM2 is “effectively ubiquitous”. It does not define a threshold, denominator, observation period, cohort or authority for declaring that state.
  • Receivers may watch their own daily mix of mail with and without DKIM2 and mailbox-holder engagement. Those local observations can guide local policy, but no receiver’s traffic view measures the whole mail ecosystem.
  • A privacy-safe transition-exit record could state which population was measured, what exceptions remain, what decision was taken and what would trigger rollback. This is Daniel Kade’s proposal, not a requirement in the draft.

One phrase carries the whole migration clock

Revision 01 of draft-ietf-dkim-dkim2-bcp appeared on 9 September. Its change log describes substantial reorganisation and wholesale changes since revision 00, reflecting both the continuing development of DKIM2 and the interval since the first working-group version. The Datatracker record places it in the DKIM working group with state WG Document and IESG state I-D Exists. The document header says Intended status: Best Current Practice, while Datatracker currently shows no intended RFC status. None of those labels turns the draft into an approved BCP.

The operational recommendation is easy to repeat: senders should sign outgoing mail with both DKIM1 and DKIM2 until DKIM2 deployment is “effectively ubiquitous”. The phrase appears twice. It is not accompanied by a percentage, a date, a measurement window or a list of populations that must be represented. The draft does not say whether the declaration belongs to a sender, a receiving network, a forwarding service, the working group or some wider community.

That flexibility may be deliberate. Mail does not have one deployment controller, and a single worldwide cutover threshold could be both impractical and misleading. Yet flexibility does not remove the need for a record. If one operator stops DKIM1 signing while another stops verifying it and a third still depends on the fallback, the phrase alone cannot explain whether each decision used comparable evidence.

There is also a second recommendation that should not be folded into the first. Section 3.2 recommends multiple DKIM2 signatures using different cryptographic algorithms. That is algorithm redundancy inside DKIM2. Section 3.3 concerns coexistence between DKIM1 and DKIM2. An operator may be ready for one transition and not the other; a declaration that merely says “DKIM2 ready” would blur the two.

Receiver percentages are views, not a global denominator

The draft gives receivers a sensible local input. When a message arrives without DKIM2, a DKIM1-capable receiver should use its existing DKIM1 disposition policy. That policy can change as the receiver observes the daily percentage of traffic with and without DKIM2 signatures and how mailbox holders engage with the two classes. During the transition, however, receivers should not reject a message merely because DKIM2 is absent.

Those instructions avoid pretending that partial deployment is failure. They also make absence ambiguous. It may describe a sender that has not adopted, a path that left and re-entered DKIM2 participation, a legitimate exception, a stripped signature or a measurement defect. The same percentage can therefore mean different things at two providers.

A large consumer mailbox service sees a different sender population from a corporate relay, a mailing-list operator or a small regional provider. Volume weighting can let a few bulk senders dominate the numerator. Counting domains gives a tiny sender the same weight as a vast platform. Counting messages says little about the forwarders through which those messages travelled. Geography, language, customer class and anti-abuse filtering can all change the observed mix before it reaches the denominator.

The draft does not claim otherwise. Its percentage is explicitly part of a receiver’s own policy evolution. The governance error would be to promote one local dashboard into proof of ecosystem ubiquity without publishing the population, exclusions and window behind it.

Three path states still describe individual paths

Section 6 offers a useful vocabulary. “Never Left” describes a path in which every participating administrative management domain signed at egress. “In and Out” describes partial participation. “Never Entered” describes a message arriving with no DKIM2 signatures. These are observations about a message’s path, not votes in a global readiness ballot.

That distinction matters because DKIM2 makes forwarders active participants. A participating forwarder verifies existing DKIM2 and DKIM1 signatures and adds a DKIM2 signature to every message it handles, even when it makes no content revision. Signatures are applied at the last hop before mail exits the signer’s infrastructure. Readiness therefore depends on more than origin senders and final receivers; intermediate handling domains can determine whether a chain remains complete.

Section 7.1 anticipates that receivers will rely primarily on DKIM2 as deployment matures, avoiding permanent operation of parallel verification paths. But “matures” is no more measurable there than “effectively ubiquitous” is in the signing advice. The text establishes a direction of travel, not a common exit test.

The question-marked sections on DMARC and SPF should remain outside any retirement claim. The introduction identifies such sections as unresolved working-group questions and their text as speculative. Revision 01 explores whether effective DKIM2 ubiquity could make parts of DMARC redundant and notes continued SPF value where mail never entered DKIM2. It does not announce the retirement of either protocol.

Coexistence makes a missing signature a weak signal

The security discussion identifies a sharper transition problem. An actor capable of stripping a DKIM2 signature might cause a receiver that has not made DKIM2 mandatory to fall back to weaker DKIM1-only handling. The draft advises scrutiny when a domain otherwise known to sign with DKIM2 arrives with plausible DKIM1 but no DKIM2.

This is a risk analysis, not evidence of a live incident or a measured attack rate. It nevertheless shows why an exit record needs more than an adoption percentage. An operator should distinguish mail from domains observed to use DKIM2, mail for which a complete or partial chain arrived, and mail with no DKIM2 history. Otherwise the population most relevant to downgrade detection disappears inside the general “without DKIM2” bucket.

It also explains why a retirement decision cannot be irreversible by default. If a policy change suddenly increases known-DKIM2 domains arriving DKIM1-only, or degrades delivery for a documented exception cohort, the operator needs a rollback trigger that existed before the anomaly appeared.

A small transition-exit record

The common object need not be a central certificate of Internet-wide ubiquity. A narrower and more honest object is an operator’s transition-exit record. I would include:

  1. the declaring operator, its role and the decision it controls;
  2. the sender, forwarder and receiver cohorts evaluated;
  3. the denominator, weighting method and explicit exclusions;
  4. the observation window and measurement coverage;
  5. DKIM2-present, complete-chain, partial-chain and absent rates;
  6. verification outcomes and the delivery or user-engagement indicators actually used;
  7. known-DKIM2 domains arriving without DKIM2 and the treatment of suspected downgrade anomalies;
  8. exception populations and the remaining DKIM1 dependency;
  9. the threshold and policy version applied to the decision;
  10. the decision time, rollback trigger and next review date.

Public reporting can aggregate these fields. It need not expose recipient addresses, individual behaviour or message content. It should also label the scope: local readiness, a named interconnection cohort or broader evidence assembled by a community. Three bounded claims are more useful than one unsupported “ubiquitous” badge.

This follows the minimum-initial-specification logic in Heng Lu’s essay: standardise only the evidence needed for coordination, while leaving adoption and policy choices with the actors that bear them. No universal exit percentage is proposed here.

Evidence boundary

The document history establishes the revision dates and working-group transition. The 00-to-01 diff shows how extensively the text moved. The active DKIM2 base specification and DNS document remain drafts too.

RFC 6376, RFC 6377, RFC 7208, RFC 8601 and RFC 8617 establish the current DKIM, DKIM deployment, SPF, Authentication-Results and DMARC contexts. They do not report DKIM2 adoption. The source set contains no representative deployment census, cost total or attack measurement. This article therefore makes no forecast for ubiquity and no claim that DKIM1, DMARC or SPF now has an end date.

Sources