DKIM2 (travaux de l’IETF en cours)

Avertissement sur le statut : il s’agit de travaux de normalisation EN COURS, pas d’une norme déployable. Tout ce qui suit est tiré d’Internet-Drafts actifs du groupe de travail dkim de l’IETF, dont la charte a été renouvelée, tels que récupérés le 2026-07-20. Les Internet-Drafts sont des documents de travail : les noms de balises, les noms d’en-têtes et la sémantique vont changer d’une révision à l’autre, et le chantier peut aussi s’arrêter complètement. Ne construisez aucune dépendance de production sur ces détails ; servez-vous-en pour suivre la direction prise. DKIM (RFC 6376, STD 76) reste la norme en vigueur.

Pourquoi DKIM2 existe

DKIM v1 présente deux défauts structurels que l’écosystème contourne à coups de correctifs depuis 15 ans :

1. Le rejeu : une signature est valide pour n’importe quel destinataire, indéfiniment (dans la limite de x=) ; voir Attaques par rejeu DKIM.
2. La casse par les intermédiaires : les services de transfert et les listes de diffusion qui modifient les messages détruisent les signatures, ce que DMARC sanctionne ensuite ; ARC atteste de ce qu’un intermédiaire a vu, mais pas de ce qu’il a modifié, et oblige à faire confiance à l’intermédiaire.

La réponse de DKIM2 : chaque saut qui traite le message le signe, chaque signature est liée à l’enveloppe SMTP de ce saut, et les modifications sont enregistrées de façon réversible pour que le serveur de réception final puisse reconstituer et vérifier le message signé à l’origine. Effet secondaire : des rebonds entièrement authentifiés, qui éliminent le backscatter.

État du groupe de travail (au 2026-07-20)

Les affiliations des auteurs (Yahoo, Google, Fastmail) signalent l’adhésion des serveurs de réception, ce qui a fait échouer ou aboutir les normes de messagerie par le passé. Archives de la liste de diffusion : mailarchive.ietf.org/arch/browse/ietf-dkim/.

Le mécanisme (selon draft-ietf-dkim-dkim2-spec-04)

Deux nouveaux en-têtes

Message-Instance : un par révision du message, balises :

• m= numéro de révision (émetteur d’origine = 1, incrémenté par tout saut qui modifie le message)
• h= empreintes de cette instance, au format sha256:<header-hash>:<body-hash>
• r= « recipes » JSON encodées en base64, qui permettent de reconstituer l’instance précédente (voir plus bas)

DKIM2-Signature : une par saut de traitement, balises :

• i= numéro de séquence du saut (émetteur d’origine = 1, incrémenté à chaque signataire ; un trou dans i= ou m= invalide la chaîne)
• m= l’instance Message-Instance que ce saut a signée
• t= horodatage Unix (rejeter les dates futures ; PEUT ignorer au-delà de 14 jours)
• mf= base64 du reverse-path MAIL FROM RFC 5321 utilisé à ce saut (<> pour les DSN)
• rt= base64 du ou des forward-paths RCPT TO RFC 5321 à ce saut
• nd= « next domain » (domaine suivant) : fait le lien entre des transmissions internes sans véritable transaction SMTP
• n= nonce facultatif (≤64 caractères), f= indicateurs
• d=, s= domaine et sélecteur comme dans DKIM1 ; valeur de signature au format <selector>:<alg>:<sig>

Chaîne de responsabilité et résistance au rejeu

• Chaque saut enregistre l’enveloppe qu’il a utilisée ; les vérificateurs contrôlent que le domaine mf= du saut i est aligné (correspondance souple) avec son d=, et que le rt= du saut i−1 correspond au mf= du saut i.
• Le serveur du destinataire contrôle que le RCPT TO réel de la transaction de livraison correspond au dernier rt=. Un message rejoué porte le destinataire d’origine dans le rt= signé ; l’envoyer en masse à de nouveaux RCPT TO casse la chaîne : c’est la correction du rejeu que DKIM1 ne peut pas exprimer.
• La diffusion légitime vers plusieurs destinataires est déclarée, et non dissimulée : f=exploded signale une distribution intentionnelle à plusieurs destinataires (listes de diffusion) ; f=donotexplode demande une livraison à un seul destinataire ; f=donotmodify interdit toute modification du contenu (une violation entraîne FAIL et bloque tout transfert ultérieur).

Recipes : des enregistrements de modification réversibles

Un intermédiaire qui modifie le message (pied de page de liste, balise dans l’objet) incrémente m= et publie dans r= un diff JSON permettant de reconstituer l’instance précédente : "h" associe des noms d’en-têtes à des étapes, "b" contient les étapes du corps ; les étapes sont {"c":[start,end]} (plages à copier : en-têtes numérotés de bas en haut, lignes du corps de haut en bas à partir de 1) ou {"d":[...]} (valeurs littérales insérées) ; "b": null déclare une modification irréversible du corps. Le vérificateur final déroule les recipes jusqu’à l’instance 1 et contrôle la signature de l’émetteur d’origine, ce qui résout le problème listes de diffusion/DMARC sans la confiance aveugle qu’exige ARC.

Point de vigilance sur la vie privée soulevé dans le BCP : les recipes peuvent réintégrer un contenu qu’un intermédiaire a délibérément retiré (caviardages DLP, pièces jointes malveillantes supprimées). Les recipes nulles sont la porte de sortie ; les recommandations pour les juridictions soumises au RGPD restent une question ouverte.

Cryptographie et canonicalisation simplifiées

• Empreinte : SHA-256 obligatoire. Signature : rsa-sha256 (PKCS#1 v1.5, e=65537, ≥1024 bits ; les vérificateurs prennent en charge de 1024 à 2048 bits) et ed25519-sha256 (PureEdDSA, RFC 8032). BCP : signer avec les deux algorithmes.
• Une seule canonicalisation remplace la matrice simple/relaxed de DKIM1 : pour l’entrée de la signature, noms d’en-têtes en minuscules, dépliage, suppression de tous les espaces blancs ; l’empreinte des en-têtes trie les en-têtes par ordre alphabétique (les en-têtes de même nom gardent leur ordre de bas en haut) ; l’empreinte du corps est de type simple (lignes vides finales réduites à un seul CRLF). Le calcul se fait sur la forme transmise (après l’encodage de transfert du contenu, avant le dot-stuffing).
• Exclus de l’empreinte des en-têtes : Received, Return-Path, Delivered-To, DKIM-Signature, ARC-*, Authentication-Results, X-*, Message-Instance, DKIM2-Signature.
• Pas de balise v= : le nouveau nom d’en-tête tient lieu de version. Les enregistrements de clé se trouvent au même emplacement <selector>._domainkey.<domain>, avec un k= correspondant à l’algorithme, si bien que DKIM1 et DKIM2 peuvent partager l’infrastructure de clés et coexister sur un même message, dans n’importe quel ordre.

Résultats de vérification et DSN authentifiées

• Résultats (compatibles RFC 8601) : PASS / FAIL / PERMERROR / TEMPERROR, avec des messages d’erreur lisibles normalisés (par exemple FAIL: Message Instance m=<x> body hash <value> mismatch).
• Les DSN sont envoyées au mf= de la DKIM2-Signature au numéro le plus élevé, c’est-à-dire au saut qui vous a réellement remis le message, jamais à un inconnu usurpé ; aucune DSN n’est envoyée quand mf=<>. Chaque service de transfert relaie la DSN d’un saut vers l’arrière, en vérifiant que le message intégré correspond à ce qu’il avait signé et en retirant ses propres en-têtes DKIM2. Résultat : les rebonds sont authentifiés de bout en bout et le backscatter devient structurellement impossible pour le courrier de l’écosystème DKIM2. Les indicateurs feedback/feedhere esquissent un canal de retour sur la livraison (détails à définir).

Recommandations du BCP (draft-ietf-dkim-dkim2-bcp-00)

• Expéditeurs : double signature DKIM1 + DKIM2 « jusqu’à ce que le déploiement soit effectivement généralisé » ; RSA et Ed25519 ; signer uniquement en sortie ; faire tourner les clés selon les pratiques du M3AAWG.
• Services de transfert : vérifier à l’arrivée ; signer chaque message en sortie (modifié ou non) pour garder la chaîne intacte ; ne signer pour transfert que les messages arrivés avec une chaîne DKIM2 valide ; les messages arrivés avec DKIM1 seulement doivent être examinés selon la politique locale avant de leur prêter votre chaîne.
• Serveurs de réception : pour le courrier entièrement à l’intérieur de l’écosystème DKIM2, une chaîne rompue peut être rejetée sans risque (la DSN atteint de façon prouvée une partie responsable) ; pour les chaînes partielles ou absentes, revenir à DKIM1 et à la politique locale pendant la transition.
• Questions ouvertes signalées dans le draft lui-même : plafonds sur le nombre de Message-Instance et de signatures, rôle futur de DMARC et de SPF, sémantique du feedback ; plusieurs sections contiennent littéralement « Need some text » (texte à rédiger).

Le débat sur le profil de déploiement (draft-moccia-dkim2-deployment-profile-06)

Un draft individuel (hors groupe de travail) soutient que la spécification complète est trop lourde pour les petits opérateurs et propose un profil à deux niveaux. Il est notable parce qu’il utilise d’autres dispositions d’en-têtes (DKIM2-Sig-mf/DKIM2-Sig-rt/DKIM2-Mod) que la spécification du groupe de travail, ce qui montre à quel point le format sur le fil est encore instable :

• DKIM2-core (niveau obligatoire) : liaison à l’enveloppe, chaîne de responsabilité, déclarations de modification des en-têtes, authentification des DSN ; le tout sans état et réalisable sous forme de milter, sans modification du cœur du MTA (avis partagé par le coprésident du groupe de travail M. Kucherawy ; un prototype fonctionnel a été publié). Limites : sauts i≤20 (environ 15 à 16 dans le pire cas réaliste), ≤500 destinataires par saut, correspondance souple de domaine limitée au retrait de 2 libellés.
• DKIM2-extended (facultatif) : recipes complètes pour le corps et reconstitution des Message-Instance ; exige un état persistant, des cycles d’adoption plus longs et une charge plus lourde en matière de vie privée.
• Règle en cas d’algorithmes multiples : l’échec de n’importe quelle signature à un saut invalide tout le saut (prévention des attaques par rétrogradation).

Calendrier réaliste et position d’un ESP

• Aucune RFC n’existe ; la spécification centrale en est à la version -04 avec des questions de fond non résolues. Même après publication, DKIM2 n’apporte ses garanties que si chaque saut d’un chemin participe : attendez-vous à une transition de plusieurs années pendant laquelle la double signature (DKIM1+DKIM2) sera la norme, et où DKIM1+DMARC resteront ce qu’appliquent les fournisseurs de messagerie. Pour se faire une idée : ARC (RFC 8617, 2019) n’est toujours que partiellement déployé.
• Ce qu’un ESP devrait faire maintenant : rien en production ; suivre les révisions du draft et la liste ietf-dkim ; s’assurer que les chaînes de signature peuvent ajouter un second type de signature et des données d’enveloppe par message (l’exigence d’architecture de DKIM2) ; continuer d’appliquer les protections actuelles contre le rejeu (sursignature, sélecteurs par flux).
• Ce qu’il faut surveiller : le dernier appel du groupe de travail (WG last call) sur dkim2-spec, l’annonce de pilotes côté serveur de réception chez Gmail, Yahoo ou Fastmail (les employeurs des coauteurs), et l’intégration ou non des simplifications du profil milter.

Voir aussi

• DKIM : la norme actuelle à laquelle DKIM2 succéderait à terme
• Attaques par rejeu DKIM : le problème qui motive la refonte
• ARC : le mécanisme intermédiaire provisoire que DKIM2 vise à rendre obsolète
• Backscatter et BATV : le problème de rebonds que résout la chaîne de DSN de DKIM2