Résumé

  • La révision 01 de la draft de bonnes pratiques DKIM2 du groupe DKIM est disponible depuis le 9 septembre 2026. C’est une Internet-Draft active, et non une BCP publiée ni une décision de retrait de protocoles existants.
  • Le texte recommande aux expéditeurs de signer avec DKIM1 et DKIM2 jusqu’à ce que DKIM2 soit « effectivement omniprésent », sans définir de seuil, dénominateur, période ou responsable de cette appréciation.
  • Les pourcentages quotidiens observés par un destinataire éclairent sa propre politique. Ils ne décrivent pas, à eux seuls, les expéditeurs, relais et destinataires qui composent l’ensemble du courrier électronique.
  • Un relevé de sortie agrégé peut documenter le périmètre, les exceptions, la décision et son retour arrière sans imposer un seuil mondial. Ce mécanisme relève de l’analyse de Daniel Kade et ne figure pas dans les obligations du draft.

La date de fin est remplacée par un adjectif

La révision 01 a été publiée le 9 septembre. Son historique des changements annonce une réorganisation, de nouveaux intitulés et de nombreuses réécritures depuis la révision 00. Le Datatracker la classe comme document du groupe de travail DKIM, avec l’état IESG I-D Exists. L’en-tête vise le statut Best Current Practice, alors que la fiche Datatracker n’affiche actuellement aucun statut RFC prévu. Ce décalage de métadonnées doit être conservé tel quel : le document n’est ni une BCP ni un RFC.

La consigne de transition tient dans une formule. Les expéditeurs devraient apposer DKIM1 et DKIM2 jusqu’à une diffusion « effectivement omniprésente » de DKIM2. Le mot laisse aux opérateurs une marge utile, car aucun centre de commande ne pilote tous les systèmes de messagerie. Mais il ne dit pas ce qui sera compté. S’agit-il des messages, des domaines, du volume des grands expéditeurs, des relais ou des destinataires capables de vérifier une chaîne complète ?

La draft ne fixe pas davantage la fenêtre temporelle. Une journée très chargée, une moyenne sur plusieurs mois et une mesure limitée aux partenaires directs peuvent aboutir à trois verdicts incompatibles. Elle ne désigne pas non plus l’auteur du constat : expéditeur, prestataire de transfert, grand récepteur, groupe de travail ou communauté d’interconnexion.

Cette absence n’invalide pas l’orientation. Elle empêche seulement de comparer deux décisions de sortie. Un opérateur peut dire que son périmètre est prêt ; il ne peut déduire de son seul trafic que l’écosystème entier l’est.

Le tableau de bord du destinataire répond à une question locale

Pour un message dépourvu de signature DKIM2, la révision 01 recommande au destinataire qui sait vérifier DKIM1 de conserver sa politique de traitement existante. Cette politique peut évoluer en fonction de la part quotidienne des messages avec ou sans DKIM2 et de la manière dont les titulaires de boîtes interagissent avec ces catégories. Pendant la transition, l’absence seule ne devrait pas justifier un rejet.

Le conseil est prudent. Il évite de punir automatiquement les non-adoptants et les chemins partiellement équipés. Il fait aussi de l’absence un signal équivoque. Elle peut provenir d’un expéditeur non migré, d’un relais extérieur au dispositif, d’une exception légitime, d’une signature retirée ou d’un défaut d’observation.

Un grand webmail, une passerelle d’entreprise, une liste de diffusion et un opérateur régional n’ont pas le même échantillon. Mesurer les messages donne un poids énorme aux expéditeurs de masse. Mesurer les domaines masque leur volume. Mesurer seulement les connexions acceptées retire déjà du champ ce que l’antispam a bloqué. Les données peuvent être exactes tout en ne portant pas sur le même dénominateur.

La bonne conclusion est donc modeste : les pourcentages locaux permettent de modifier une politique locale. Pour soutenir une prétention plus large, il faut rendre visibles la population, les exclusions, la pondération et la période.

Une chaîne complète dépend également des intermédiaires

Le texte distingue trois états de chemin. « Never Left » signifie que chaque domaine administratif participant a signé à la sortie. « In and Out » décrit une participation discontinue. « Never Entered » couvre l’absence totale de signature DKIM2 à l’arrivée. Cette taxonomie décrit un trajet de message, pas le degré d’équipement du monde.

Le rôle des relais explique pourquoi. Un relais participant doit tenter de vérifier les signatures DKIM2 et DKIM1 déjà présentes, puis ajouter sa propre signature DKIM2 à tout message traité, même s’il n’en modifie pas le contenu. Les signatures sont appliquées au dernier saut avant que le message ne quitte l’infrastructure du signataire. L’origine et la destination ne suffisent donc pas à prouver que les segments intermédiaires sont prêts.

La section 7.1 prévoit qu’avec la maturité du déploiement les destinataires s’appuieront principalement sur DKIM2, ce qui évitera d’entretenir indéfiniment deux chemins de vérification. Mais cette maturité n’est pas définie. La draft indique une direction ; elle ne livre pas le test qui ferme la transition.

Il faut enfin isoler les paragraphes entourés de points d’interrogation au sujet de DMARC et de SPF. L’introduction les présente comme des questions non résolues et leur contenu comme spéculatif. Ils ne constituent pas un consensus du groupe de travail sur l’abandon de DMARC, SPF ou DKIM1.

L’absence devient plus sensible lorsqu’un domaine est déjà connu

La partie sécurité décrit un risque propre à la coexistence. Un acteur capable de retirer une signature DKIM2 pourrait conduire un destinataire qui ne l’exige pas encore à retomber sur un traitement DKIM1 moins fort. La draft recommande une attention accrue lorsqu’un domaine habituellement observé avec DKIM2 arrive soudain avec un DKIM1 plausible mais sans DKIM2.

Ce scénario n’est pas la preuve d’une attaque en cours. Aucune fréquence n’est fournie. Il montre néanmoins pourquoi la colonne « sans DKIM2 » est insuffisante. Il faut distinguer les domaines sans historique, les exceptions déclarées, les chaînes incomplètes et les domaines déjà connus pour signer. C’est dans ce dernier groupe qu’une disparition soudaine peut devenir un indicateur de dégradation ou de retrait malveillant.

Une sortie doit donc rester réversible. Le déclencheur du retour arrière doit être fixé avant l’incident : hausse des domaines connus arrivant en DKIM1 seul, dégradation de livraison pour une cohorte d’exception, ou baisse de chaînes complètes au-delà d’une limite déclarée.

Un relevé de sortie, pas un certificat mondial

Je propose un objet beaucoup plus petit qu’une déclaration d’omniprésence. Chaque acteur qui réduit la double signature ou la double vérification publierait, à un niveau d’agrégation respectueux de la vie privée :

  1. son identité, son rôle et la décision qu’il contrôle ;
  2. les cohortes d’expéditeurs, de relais et de destinataires évaluées ;
  3. le dénominateur, la pondération, les exclusions et la fenêtre ;
  4. les taux de présence, de chaîne complète, de chaîne partielle et d’absence ;
  5. les résultats de vérification et les indicateurs de livraison ou d’usage réellement employés ;
  6. les domaines connus pour DKIM2 mais arrivés sans DKIM2 ;
  7. les exceptions qui dépendent encore de DKIM1 ;
  8. le seuil et la version de politique appliqués ;
  9. la date de décision, le déclencheur de retour arrière et la prochaine revue.

Ce relevé peut distinguer disponibilité locale, disponibilité d’un groupe d’interconnexion nommé et éléments plus larges rassemblés par une communauté. Il n’a pas à révéler les destinataires ou le contenu des messages. Surtout, il ne transforme pas un seuil choisi localement en règle universelle.

Cette méthode reprend la logique de spécification initiale minimale exposée par Heng Lu : partager le minimum de preuve nécessaire à la coordination et laisser la décision aux acteurs qui en assument les effets.

Limite de la preuve

L’historique du document établit les dates et l’adoption par le groupe ; le différentiel 00–01 montre l’ampleur de la révision. La spécification DKIM2 et son document DNS sont eux aussi des travaux en cours.

Les RFC actuels établissent le contexte de DKIM, SPF, Authentication-Results et DMARC ; ils ne mesurent pas l’adoption de DKIM2. Les sources ne contiennent ni recensement représentatif, ni coût total, ni incident mesuré. Cet article ne donne donc aucun taux actuel, aucune date de bascule et aucune prévision de retrait.

Sources