Un score seedlist qui dégringole sans raison identifiable, quelques semaines après une mise à jour côté Gmail : la scène est familière pour qui surveille l’authentification au quotidien. Ce type de symptôme pourrait devenir routinier une fois DKIM2 déployé, le successeur de DKIM1 (RFC 6376, 2011) que le groupe de travail DKIM de l’IETF développe depuis fin 2024. Réponse courte : DKIM2 introduit une signature en chaîne posée à chaque saut SMTP et un rejet différé des messages classés spam, deux mécanismes qui changent la lecture des rapports postmaster bien plus qu’une simple mise à jour cryptographique.
Aucune documentation postmaster officielle ne couvre encore ce comportement. DKIM2 n’existe qu’à l’état de draft IETF, donc les guides déjà publiés sur DKIM et DMARC n’en disent rien pour l’instant. Ce qui suit vient directement des brouillons techniques et des retours de terrain de ceux qui les suivent depuis leur adoption par le groupe de travail.
Pourquoi DKIM1 craque après 15 ans d’usage
La norme actuelle, formalisée en RFC 6376 en 2011 pour remplacer le brouillon original RFC 4871 de 2007, prouve une seule chose : le domaine signataire a bien envoyé le message d’origine. Elle ne dit rien de son trajet ensuite. Un message intercepté puis rediffusé tel quel garde une signature valide, puisque rien dans son contenu n’a changé.
Bleeping Computer et Abnormal AI ont documenté en avril 2025 une campagne de phishing qui exploitait exactement cette faille : une alerte de sécurité Google légitime, rejouée sans modification vers des milliers de destinataires, avec une signature DKIM toujours valide et un lien malveillant glissé dans le nom de l’application OAuth plutôt que dans le corps du message. Aucun filtre d’authentification classique n’avait de raison de bloquer l’envoi. C’est précisément ce scénario de replay attack que la nouvelle spécification cible en premier.
Ce que change le DKIM2-Signature : chain of custody et binding destinataire
Le brouillon technique draft-ietf-dkim-dkim2-spec-04, mis à jour le 5 juillet 2026 par l’IETF (Internet Engineering Task Force, l’organisme qui pilote les standards du réseau), introduit un nouvel en-tête : DKIM2-Signature. Chaque serveur qui manipule le message au passage ajoute sa propre signature, ce qui construit une chain of custody, la séquence complète des en-têtes DKIM2-Signature accumulés à chaque saut SMTP. Le receveur final peut ainsi reconstituer quels domaines ont touché le message et dans quel ordre.
Fait nouveau et décisif : les signatures embarquent désormais les adresses MAIL FROM et RCPT TO portées par l’enveloppe SMTP. Ce binding destinataire complique fortement le rejeu d’un message vers une cible différente de celle prévue à l’origine, puisque toute divergence entre l’enveloppe signée et l’enveloppe réelle casse la vérification. Côté cryptographie, le brouillon retient deux algorithmes : RSA-SHA256 avec des clés de 1024 à 2048 bits et Ed25519-SHA256 pour les implémentations qui veulent une signature plus légère.
Ceux qui compulsent les en-têtes verront probablement une messagerie commerciale envoyée via un ESP porter quatre signatures distinctes : DKIM d=marque, DKIM d=ESP, DKIM2 d=marque, DKIM2 d=ESP. (Word to the Wise, avril 2026)
Les clés DKIM1 existantes continuent de fonctionner sans modification. La coexistence des deux en-têtes pendant la période de transition relève d’un choix de conception assumé, pensé pour rendre l’adoption possible dès le premier jour.
DKIM1 face à DKIM2 : ce qui bascule
Les deux versions coexistent déjà dans certains flux tests. Le tableau ci-dessous condense ce que couvre chacune, poste par poste.
| Critère | DKIM1 | DKIM2 |
|---|---|---|
| Statut | RFC publiée, déployée depuis 2011 | Draft IETF, spec-04 datée du 5 juillet 2026 |
| Portée de la signature | Domaine signataire uniquement | Chaîne complète, un en-tête par saut SMTP |
| Protection replay | Aucune, contenu inchangé = signature valide | Binding MAIL FROM / RCPT TO à la signature |
| Traitement du backscatter | Rebond immédiat, souvent déconnecté du message d’origine | Rejet différé rattaché explicitement au message signé |
| Algorithmes | RSA-SHA256 en pratique quasi exclusive | RSA-SHA256 (1024-2048 bits) et Ed25519-SHA256 |
| Compatibilité | Signature unique | Double signature DKIM + DKIM2 en coexistence |
Ce que DKIM2 change dans vos rapports de bounce
Le backscatter n’est pas un problème neuf. Selon Valimail, le terme désigne depuis 1997 les rebonds massifs envoyés à un innocent qui n’a jamais expédié le message d’origine, l’incident fondateur ayant même donné son nom au jargon du secteur sous l’appellation « joe job ». DKIM2 s’y attaque d’une façon qui va directement percuter les tableaux de bord des équipes deliverability : quand un fournisseur détermine, sur la base du retour destinataire, qu’un message est du spam, il peut désormais le rejeter vers l’expéditeur d’origine même 24 heures plus tard, grâce à la signature complète du message conservée dans la chaîne.
Ce délai casse un réflexe de lecture bien ancré. Un flux qui affiche 99% d’inbox placement un jour peut retomber à 95% le lendemain sans que la qualité de la liste ou le complaint rate n’aient bougé : des rejets différés de la veille remontent enfin dans le rapport. Les équipes qui pilotent la Suppression List à partir des codes 550 5.1.1 user unknown classiques devront apprendre à distinguer ces deux origines de rebond. Aucun outil équivalent à parsedmarc, la brique qui parse aujourd’hui les rapports agrégés DMARC, n’existe encore côté DKIM2 pour automatiser cette lecture. Les scores seedlist mesurés via Validity ou les postmaster API des grands webmails vont, eux, refléter ce décalage avant que la documentation officielle ne rattrape le sujet.
Signer à chaque saut : le prix opérationnel pour les MTA et les ESP
Le brouillon de motivation IETF le dit sans détour : DKIM2 s’appuie explicitement sur les leçons tirées de l’expérimentation ARC (ARC sealing, RFC 8617), qui avait déjà tenté de tracer le chemin d’un message à travers les intermédiaires sans jamais devenir un standard largement déployé. Le document est signé par Richard Clayton (Yahoo), Wei Chuang (Google) et, côté Fastmail, Bron Gondwana, trois profils qui pèsent sur l’infrastructure email mondiale et dont la présence conjointe renforce les chances d’adoption réelle du protocole.
Pour les opérateurs de MTA qui font tourner leur propre serveur, l’adoption passera par une bibliothèque à jour, rien de plus. Pour les ESP, la charge est différente : gérer des bounces asynchrones qui arrivent des heures après l’envoi suppose une capacité entrante que beaucoup n’ont, à ce jour, jamais dimensionnée. DKIM2 ne résout ni les problèmes de contenu ni l’hygiène de liste. Une base avec 20% d’adresses invalides continue de dégrader la réputation IP quel que soit le protocole de signature en place. Nettoyer la Suppression List avant l’arrivée de ces rebonds différés évite au moins de mélanger deux causes distinctes de rejet au moment du diagnostic.
Calendrier : ce qui se passe avant fin 2026
Le brouillon de motivation a été mis à jour pour la dernière fois le 2 novembre 2025. La spécification technique elle-même, révisée le 5 juillet 2026, porte une date d’expiration fixée au 6 janvier 2027, ce qui borne la fenêtre de discussion active au sein du groupe de travail. Sendmarc et Word to the Wise convergent sur une même échéance : les premiers déploiements fonctionnels chez les grands fournisseurs de boîtes aux lettres sont attendus pour la fin 2026, sans calendrier formel de publication en RFC à ce stade.
Les changements de février 2024 chez Google et Yahoo ont montré à quelle vitesse le marché peut basculer une fois l’incitation posée. Il n’y a, pour l’instant, aucune obligation équivalente annoncée pour DKIM2.
Le courrier électronique a mis 20 ans à apprendre à prouver qui l’a envoyé. Il commence tout juste à vouloir prouver par où il est passé.
