En mars 2026, lors d’un test de routage interne, une équipe deliverability d’un ESP européen constate que ses emails vers des listes de diffusion Mailman échouent systématiquement à la vérification DKIM, malgré des clés correctement configurées. Le message est légitime, le domaine est propre, la liste est opt-in. Mais Mailman a réécrit le From header et la signature DKIM1 est morte à ce moment précis. DKIM2 vise à corriger ce type de cassure. Le groupe de travail IETF dkim a adopté les premiers brouillons du protocole en mars 2026 : pas encore un RFC, zéro déploiement en production, mais une architecture qui répartit la vérification sur l’ensemble du chemin de livraison.
Pourquoi DKIM1 atteint ses limites en 2026
DKIM1, formalisé dans la RFC 6376 en 2011, couvre un périmètre précis : il prouve que le domaine signataire a bien émis le message à l’origine. La spécification ne survit pas aux intermédiaires. Chaque serveur qui touche le message peut invalider la signature : une mailing list qui ajoute un pied de page, un gateway sécurité qui réécrit les URLs, un forwarder qui modifie l’enveloppe SMTP. Avec une adoption DKIM proche des 90% sur les emails directs en 2026, on pourrait croire le problème résolu. Mais ce taux mesure la réussite sur les emails qui arrivent directement, pas ceux qui transitent par des mailing lists ou des forwarders.
Le draft IETF draft-ietf-dkim-dkim2-motivation documente trois failles structurelles que DKIM1 ne peut pas corriger. Première : un email validement signé peut être reçu sans aucune preuve que le destinataire était bien l’intended recipient. Deuxième : l’adresse de rebond peut référencer des domaines qui n’ont joué aucun rôle dans le transit du message. Troisième : aucun mécanisme n’existe pour documenter les modifications légitimes des forwarders ou des mailing lists. Ces lacunes tiennent à la conception même du protocole original, pas à des erreurs de configuration.
Depuis 2024, Google et Yahoo ont rendu obligatoires SPF, DKIM et DMARC pour les envois en masse. Cette pression a accéléré l’adoption sans résoudre les problèmes architecturaux. Le travail a été délégué au WG IETF dkim, qui opère sur plusieurs brouillons complémentaires : spécification principale, document de motivation, profil de déploiement via interface Milter et guide de bonnes pratiques.
La chain of signatures : survivre aux intermédiaires
Le mécanisme central de DKIM2 s’appelle la chaîne de signatures. Plutôt que de demander à chaque serveur de valider une signature unique émise à l’origine, le protocole demande à chaque intermédiaire de documenter les modifications qu’il a apportées et de signer cette documentation. Le destinataire final reconstitue ainsi la séquence complète des transformations et vérifie la légitimité de chacune.
Richard Clayton, co-auteur de la spécification DKIM2, décrit l’approche comme une « modification algebra » : les intermédiaires précisent la nature exacte de leurs modifications au lieu d’apposer un simple tampon d’acceptation. Une mailing list qui ajoute un footer le déclare dans sa signature. Un gateway de sécurité qui réécrit des URLs en fait autant. Le destinataire évalue alors si chaque transformation était attendue et autorisée.
Sur le terrain, les faux positifs liés aux listes de diffusion, aujourd’hui source fréquente d’invalidation DKIM1, sortent du périmètre de responsabilité de l’expéditeur. Clayton a indiqué en avril 2026 que du code fonctionnel existe déjà et que des tests chez des mailbox providers sont attendus dans les prochains mois. La spécification technique principale (draft-ietf-dkim-dkim2-spec-01) est datée du 20 avril 2026.
DSN asynchrones et VERP : en finir avec le backscatter
Le deuxième angle technique de DKIM2 touche à un problème moins visible mais coûteux pour la réputation des expéditeurs : le backscatter. Quand un spammeur forge l’adresse de retour avec le domaine d’un tiers innocent, les bounces générés par des serveurs légitimes tombent dans la boîte de cet innocent. Des IP et des domaines propres se retrouvent en liste noire à cause de trafic qu’ils n’ont jamais émis.
Steve Atkins de Word to the Wise, qui suit le dossier depuis plusieurs semaines, note que DKIM2 résout ce problème via deux mécanismes combinés. Les Delivery Status Notifications (DSN) asynchrones autorisent un serveur à accepter un message en SMTP puis à notifier l’échec ultérieurement, après analyse complète. VERP (Variable Envelope Return Path) encode les métadonnées nécessaires directement dans l’adresse de retour, ce qui évite de parser le corps du bounce. La combinaison des deux, selon Word to the Wise du 27 avril 2026, permet d' »enregistrer le bounce immédiatement et d’ignorer le DSN asynchrone sans aucun traitement ni stockage supplémentaire. »
Pour les deliverability managers, les bounces dans DKIM2 empruntent un chemin cryptographiquement signé, retournant vers le serveur précédent dans la chaîne plutôt que vers une adresse forgée. Le backscatter perd sa principale surface d’attaque. Atkins prévient que les volumes de bounces asynchrones pourraient augmenter de plusieurs ordres de grandeur lors du déploiement initial. Une augmentation de capacité inbound sera nécessaire côté ESP.
Anti-replay : timestamps et recipient binding
DKIM1 présente une vulnérabilité connue mais sous-estimée : le replay attack. Une signature DKIM valide peut être réutilisée pour envoyer le même message à des destinataires non prévus. L’attaquant récupère un email légitime, conserve sa signature intacte et le redistribue à grande échelle. Les filtres anti-spam voient une signature valide et laissent passer.
DKIM2 ferme cette fenêtre via deux mécanismes complémentaires. Les signatures incluent désormais les données de l’enveloppe SMTP : expéditeur et destinataire. Un message signé pour alice@example.com ne peut pas être renvoyé à bob@example.com sans invalider la signature. Des flags contrôlent également la distribution autorisée du message. Ce mécanisme de recipient binding, comme le souligne Al Iverson de SpamResource (qui suit les travaux du WG IETF DKIM), pourrait modifier la surface d’attaque des campagnes de spam les plus sophistiquées.
Les timestamps complètent le dispositif. Une signature DKIM2 a une validité temporelle explicite, ce qui empêche la réutilisation d’un message légitime vieux de plusieurs semaines dans une campagne malveillante. Iverson note que les clés DKIM elles-mêmes ne changent pas nécessairement avec DKIM2. Les expéditeurs pourraient n’avoir aucune modification significative à faire côté DNS. Ce sont l’infrastructure de vérification et la chaîne de signatures qui évoluent, pas la configuration des expéditeurs.
Ce que DKIM2 ne remplace pas : la qualité de liste
DKIM2 sécurise le chemin de livraison, sans rien changer à la qualité des destinataires. Une signature qui survit aux intermédiaires, des bounces routés cryptographiquement et une protection contre le replay supposent que les adresses de destination sont valides et engagées. Sur une liste contenant 20% d’adresses invalides ou dormantes, DKIM2 n’améliore pas le taux d’inbox. Il authentifie mieux des emails que les filtres continueront de rejeter pour d’autres raisons.
Les benchmarks publics de délivrabilité publiés par les routeurs majeurs convergent sur ce point : les taux d’inbox varient davantage en fonction de la qualité d’engagement de la liste que des seuls paramètres d’authentification. DKIM2 renforce la couche d’authentification sans compenser une liste mal entretenue. La vérification d’adresses avant envoi reste le prérequis de tout pipeline délivrabilité. Le protocole sécurise le chemin une fois les destinataires validés, jamais en amont.
Comparaison DKIM1 et DKIM2 sur les critères clés
| Critère | DKIM1 (RFC 6376) | DKIM2 (draft IETF 2026) |
|---|---|---|
| Résistance aux intermédiaires | Aucune : toute modification invalide la signature | Chain of signatures : chaque intermédiaire documente ses changements |
| Protection anti-replay | Absente : une signature valide est réutilisable | Recipient binding + timestamps : signature liée au destinataire et à une fenêtre temporelle |
| Gestion des bounces | Bounces asynchrones non cryptographiques, backscatter possible | DSN async + VERP signé : retour vers le serveur précédent dans la chaîne |
| Mailing lists et forwarders | Casse systématique de signature | Modifications documentées via modification algebra, signature maintenue |
| Visibilité RSSI | Limitée : pas de traçabilité des modifications de transit | Audit complet de la chaîne de transit documentée |
| Statut | RFC publiée, déployée depuis 2011 | Draft adopté par le WG IETF en mars 2026, pas encore RFC |
Ce qu’il faut surveiller avant le déploiement
Quatre documents ont été adoptés par le WG IETF dkim : la spécification principale, un document de motivation (draft-ietf-dkim-dkim2-motivation), un profil de déploiement via interface Milter et un guide de bonnes pratiques. Tous sont préfixés draft-ietf-dkim, ce qui indique qu’ils sont officiellement dans le pipeline du working group, pas des propositions individuelles.
- Suivi de la spécification principale : le draft-ietf-dkim-dkim2-spec expire en octobre 2026. Son renouvellement ou son avancement vers le statut de Proposed Standard sera le premier signal concret d’une trajectoire vers RFC.
- Tests chez les mailbox providers : Richard Clayton a évoqué des déploiements chez des mailbox providers dans les prochains mois. Gmail, Yahoo ou Outlook qui annonceraient du support DKIM2 changeraient immédiatement les priorités côté ESP.
- Infrastructure inbound des ESP : l’augmentation attendue des volumes de bounces asynchrones lors du déploiement exige une capacité inbound renforcée. Les ESP qui prépareront leur infrastructure en avance auront moins de pression opérationnelle.
- Politique de suppression d’adresses : les bounces asynchrones DKIM2 peuvent arriver 24 heures ou plus après l’envoi initial. Les règles de suppression automatique devront être revues pour intégrer ce délai sans générer de faux positifs dans les listes de désabonnement.
Al Iverson rappelle en avril 2026 que la spécification n’est pas encore finalisée et que les détails sont susceptibles de changer. Le WG IETF a organisé des sessions interim en 2026 pour accélérer les travaux. L’agenda du meeting interim du 29 avril 2026 documente les brouillons en cours de revue.
Pour suivre l’avancement en temps réel : abonnez-vous à la liste de diffusion ietf-dkim@ietf.org et vérifiez l’état des drafts sur datatracker.ietf.org/group/dkim, l’enceinte où se décide le calendrier effectif de DKIM2.
