Mise à jour de la spécification DKIM2 : les nouveautés du projet de l'IETF de mai 2026
par
Dernière mise à jour :
4 Temps de lecture : 4 min
Le groupe de travail DKIM de l'IETF a publié une nouvelle version de la spécification DKIM2 le 17 mai 2026. Il s'agit de la troisième révision du document du groupe de travail, qui poursuit ainsi ses progrès constants en vue d'une future RFC. Pour tous ceux qui suivent l'évolution de DKIM2 depuis les premières ébauches, c'est le signe le plus clair à ce jour que le groupe de travail est sur le point de proposer une version prête à être utilisée en pratique.
Vous avez besoin d'un petit rappel avant de poursuivre votre lecture ? Consultez notre guide détaillé intitulé « Qu'est-ce que DKIM2 ? » pour en savoir plus.
Quelles sont les nouveautés de cette mise à jour ?
La nouvelle version s'intitule draft-ietf-dkim-dkim2-spec-02. Elle a été rédigée par Richard Clayton (Yahoo), Wei Chuang (Google) et Bron Gondwana (Fastmail), l'équipe qui a travaillé sur ce document depuis le début. Le premier projet officiel du groupe de travail de l'IETF était le draft-ietf-dkim-dkim2-spec-00, publié le 24 mars 2026, qui a remplacé le projet individuel précédent (draft-clayton-dkim2-spec). Depuis lors, le document a fait l'objet de révisions : -01 en avril et -02 en mai, la spécification ayant été élaborée par l'ensemble du groupe de travail plutôt que par ses auteurs d'origine seuls.
La révision du 17 mai est une mise à jour progressive qui continue d'affiner les détails techniques de la spécification. Les changements les plus notables sont les suivants :
- En-têtes « Authentication-Results » exclus de la signature: ces en-têtes changent souvent lorsque le courrier électronique traverse les limites du système ; les exclure de la signature permet d'éviter des échecs de vérification inutiles.
- Des règles plus claires concernant les indicateurs « donotmodify » et « donotexplode »: les expéditeurs peuvent désormais indiquer plus clairement qu'un message ne doit pas être modifié ni transmis à plusieurs destinataires, et les vérificateurs disposent désormais de contrôles explicites et de messages d'erreur lorsque ces demandes sont ignorées.
- Suppression de la recette « z body » : initialement incluse pour les messages de rebond tronqués, elle s'est avérée inutile dans la pratique. Sa suppression simplifie la spécification sans compromettre la fonctionnalité.
- Des règles techniques plus strictes: les précisions apportées concernant le remplissage Base64, les séparateurs par point-virgule dans les champs d'en-tête et le formatage JSON réduisent les ambiguïtés et facilitent la mise au point d'implémentations compatibles.
Les lecteurs qui suivent de près l'évolution de la spécification peuvent comparer directement les différentes versions via l'outil IETF Datatracker.
Les deux problèmes que résout DKIM2
Cette refonte a été motivée par deux problèmes de longue date liés à DKIM1.
Le premier est le attaque par rejeu DKIM. Dans ce cas, un attaquant s'empare d'un message légitime signé et le renvoie vers d'autres boîtes de réception, abusant ainsi de la bonne réputation du domaine d'origine. DKIM2 résout ce problème en enregistrant les coordonnées du destinataire dans le contenu signé et en établissant une chaîne de traçabilité à chaque étape du parcours du message. Les messages réutilisés n'apparaissent plus comme authentiques aux yeux d'un vérificateur.
Le deuxième problème concerne les signatures corrompues lors du transfert. Les listes de diffusion et les outils de transfert modifient souvent les en-têtes ou le corps du message d'une manière qui corrompt la signature DKIM d'origine. C'est pourquoi les messages envoyés via des outils tels que Mailman échouent souvent aux vérifications DMARC pour le domaine de l'expéditeur. DKIM2 gère ce problème de manière native. Chaque système qui traite le message enregistre ses modifications et ajoute sa propre signature à la chaîne. Les vérificateurs peuvent alors remonter jusqu'à l'expéditeur d'origine sans que la chaîne ne soit rompue.
Pour en savoir plus sur le problème du transfert de messages, consultez notre article consacré au DMARC et aux listes de diffusion.
ARC est en cours de suppression
La correction relative au transfert aborde également une mise à jour connexe qu'il est utile de connaître. Le 22 avril 2026, Trent Adams (Proofpoint) et John Levine (Taughannock Networks) ont soumis draft-ietf-dmarc-arc-to-historic-00 au groupe de travail DMARC de l'IETF. Ce document propose que l'Authenticated Received Chain (ARC) soit reclassée en norme historique.
Le projet justifie la fin de l'expérience ARC en expliquant que l'expérience opérationnelle acquise grâce à ARC est intégrée dans les travaux proposés sur DKIM2, qui succédera à DKIM. En d'autres termes, les enseignements tirés d'ARC ne sont pas mis de côté. Ils sont intégrés dans une solution plus aboutie.
Si vous souhaitez en savoir plus sur l'ARC et son fonctionnement, vous pouvez consulter notre guide intitulé « Qu'est-ce que l'ARC? ».
Ce que les propriétaires de noms de domaine doivent faire dès maintenant
Pour la plupart des expéditeurs, la réponse est : rien d'urgent.
Les clés DKIM2 utilisent la même structure d'enregistrements DNS que les clés DKIM actuelles ; votre configuration DNS existante reste donc inchangée. La spécification prévoit une longue période pendant laquelle DKIM1 et DKIM2 fonctionneront en parallèle ; il n'y a donc pas de passage obligatoire à la nouvelle version. Les premiers déploiements chez les principaux fournisseurs de messagerie sont attendus fin 2026, et le déploiement à plus grande échelle se poursuivra en 2027 et au-delà.
Ce qui importe aujourd’hui, c’est de vous assurer que votre configuration DKIM actuelle est en bon état. Cela implique des clés correctement publiées, une rotation raisonnable et l’absence de sélecteurs obsolètes. Tout problème que vous rencontrez aujourd’hui vous suivra dans l’ère DKIM2. Si vous avez besoin de revoir les bases, commencez par découvrir ce qu’est le DKIM.
Si vous préférez ne pas gérer vous-même les clés de signature lorsque la transition commencera, le service DKIM hébergé de PowerDMARC se charge de la publication, de la rotation et de la surveillance, afin que vous soyez prêt dès le déploiement de DKIM2.
Expert en sécurité des domaines et des courriels chez PowerDMARC
Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.
Derniers messages de Yunes Tarada (voir tous)
