DKIM2 : la refonte de DKIM en cours à l'IETF

DKIM2 est un ensemble de documents en cours de rédaction au sein du groupe de travail DKIM de l'IETF, rechargé pour cela en 2025. L'objectif est de remplacer, à terme, le trio DKIM, ARC et une partie de ce que font SPF et DMARC, par un mécanisme unique de signature chaînée. Il s'agit de drafts (draft-ietf-dkim-dkim2-*), dont le document de motivation et les documents techniques qui l'accompagnent : rien n'est adopté, les noms d'en-têtes, les étiquettes et le format exact peuvent encore changer, et aucun routeur n'exige DKIM2 aujourd'hui. Cette page décrit l'orientation des travaux telle qu'elle ressort des drafts, pas une spécification stable.

Pourquoi reprendre DKIM#

DKIM a été conçu en 2007 avec une hypothèse simple : une signature valide prouve que le domaine d= a émis ce message. Vingt ans d'exploitation ont mis en évidence plusieurs limites :

• Le rejeu : une signature DKIM reste valide quel que soit le destinataire et, en l'absence d'étiquette x=, quelle que soit la date. Un message signé par un domaine réputé peut être réexpédié en masse à d'autres destinataires avec sa signature intacte, et le domaine signataire en subit les conséquences.
• Les modifications en transit : une liste de diffusion qui ajoute un pied de page ou un préfixe de sujet casse la signature. ARC a été ajouté pour contourner le problème, au prix d'une chaîne de confiance que chaque routeur doit évaluer seul.
• Les bounces : les notifications de non-remise remontent vers le MAIL FROM sans lien cryptographique avec le chemin suivi par le message, ce qui permet le backscatter.
• L'empilement : SPF, DKIM, DMARC et ARC vérifient des identités différentes avec des règles d'alignement distinctes, ce qui rend le diagnostic difficile.

Les orientations des drafts#

Les documents en discussion convergent vers les principes suivants, sous réserve des évolutions du groupe de travail :

• Une signature par relais, numérotée : chaque serveur qui traite le message ajoute sa propre signature avec un numéro de séquence, à la manière de l'instance i= d'ARC. Le chemin complet du message devient vérifiable, et un relais ne peut pas retirer une signature précédente sans invalider la chaîne.
• Liaison à l'enveloppe : la signature couvre le MAIL FROM et le destinataire RCPT TO de la session SMTP, ainsi qu'un horodatage à durée de vie courte. Un message signé pour un destinataire ne peut plus être rejoué vers un autre, ce qui traite le rejeu à la racine.
• Modifications déclarées et réversibles : un relais qui modifie le message (pied de page, préfixe de sujet) doit décrire la modification dans sa signature, de façon que le destinataire puisse reconstituer le contenu d'origine et vérifier la signature précédente. Les listes de diffusion n'ont plus besoin de réécrire le From:.
• Bounces remontant la chaîne : un échec de livraison est renvoyé au relais précédent, qui le renvoie à son prédécesseur, chacun vérifiant qu'il a bien transmis ce message. Le backscatter devient impossible sans signature valide.
• Clés publiées comme en DKIM : la clé publique reste dans le DNS sous _domainkey, ce qui permettrait une transition sans nouvelle infrastructure de clés.

À quoi ressemblerait un enregistrement#

Les drafts prévoient de réutiliser le format de publication de clé de DKIM. L'enregistrement ci-dessous est donc un enregistrement DKIM classique, que DKIM2 pourrait référencer tel quel ; les étiquettes propres à DKIM2 ne sont pas figées :

s2026b._domainkey.example.com.  IN TXT  "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="

L'en-tête de signature lui-même, nommé DKIM2-Signature: dans les drafts, porterait notamment le numéro de séquence, les identités d'enveloppe, l'horodatage, la description des modifications et la signature. Son format exact doit être lu dans la version courante des documents.

Ce qu'il faut faire aujourd'hui#

Rien de spécifique. Les bonnes pratiques DKIM actuelles préparent la transition : clés de 2048 bits ou Ed25519, sélecteurs datés, rotation régulière, signature des en-têtes sensibles, étiquette x= pour borner la validité, et surveillance des comptes susceptibles de servir au rejeu. Un domaine qui a déjà publié ses clés sous _domainkey et qui maîtrise ses flux n'aura, si DKIM2 aboutit, qu'à mettre à jour ses logiciels de signature et de vérification.

Pour suivre les travaux : la liste de diffusion et les documents du groupe DKIM sont publics, et chaque version de draft est archivée sur le Datatracker de l'IETF.

Points d'incertitude#

• Le calendrier : l'adoption en RFC puis la prise en charge par les routeurs se compteront en années.
• La cohabitation avec DKIM, ARC et DMARC pendant la transition, et la manière dont DMARC tiendra compte d'une chaîne DKIM2.
• Le traitement des relais qui ne participent pas et cassent la chaîne.
• Le coût pour les opérateurs de listes de diffusion, qui devront décrire leurs modifications au lieu de simplement les appliquer.

Ce que SenderRadar en montre#

SenderRadar n'affiche aucun indicateur DKIM2, le mécanisme n'étant pas déployé. Les éléments pertinents pour une future transition, à savoir les sélecteurs publiés, les types et tailles de clés et la cohérence des signatures DKIM avec la politique DMARC, sont présentés dans la fiche du domaine. SenderRadar s'appuie sur sa propre base d'analyse pour suivre l'évolution de ces éléments.

Références#

• Groupe de travail DKIM de l'IETF – documents
• Charte du groupe de travail DKIM
• RFC 6376 – DKIM
• RFC 8617 – ARC