DKIM2 : nouveautés, suppressions, modifications et dates clés

TL;DR — DKIM2 est une refonte en cours de standardisation (Internet‑Drafts) qui vise à signer la source et la destination de chaque saut SMTP, à chaîner les signatures (i=1, i=2, ...), à documenter les modifications faites par les intermédiaires, et à rendre les rebonds (DSN) traçables en remontant la chaîne. DKIM2 n'est pas encore un standard : il évolue rapidement, mais les briques principales sont là.

ℹ️ Les termes replay DKIM et backscatter sont définis dans le glossaire en fin d'article.

Pourquoi parler de DKIM2 maintenant ?

DKIM (STD 76, RFC 6376) est massivement déployé pour signer le contenu des e‑mails. Mais il montre ses limites face au replay DKIM, aux modifications opérées par des listes de diffusion/forwarders, et au backscatter (rebonds envoyés à des tiers). DKIM2 propose un modèle avec lequel chaque relais ajoute sa propre signature numérotée, et déclare explicitement le couple source → destination du saut suivant, ce qui permet :

• d'identifier et limiter les replays ;
• de transmettre des rebonds et rapports le long du chemin authentifié ;
• d'indiquer et, si possible, d'annuler les changements de corps/en‑têtes pour vérifier la signature d'origine.

Les grandes nouveautés (par rapport à DKIM "v1")

1. Nouvelle en‑tête DKIM2-Signature (sans champ de version)

   • Numérotation avec i= (1, 2, ...). Un trou dans la séquence invalide la chaîne.
   • Horodatage t= ; un vérificateur peut considérer une signature expirée au‑delà d'une fenêtre (ex. 14 jours).
   • Algorithmes : RSA‑SHA256 et Ed25519‑SHA256 sont ciblés, avec de l'agilité crypto prévue.
   • Clés dans le DNS : comme DKIM, sous selector._domainkey.domaine.

2. Chaînage et alignement avec l'enveloppe SMTP

   • mf= (MAIL FROM) et rt= (RCPT TO) décrivent l'enveloppe utilisée au saut signé.
   • Chaque nouveau saut doit correspondre à la destination précédente (ou être "proxy‑signé" via pp=).
   • Le vérificateur valide d'abord la signature la plus récente (i le plus élevé).

3. Modélisation des modifications

   • Le brouillon introduit un en‑tête MailVersion pour décrire comment revenir à la version précédente (recettes corps/en‑têtes).
   • La signature porte mv= pour la version du message couverte.
   • Un champ f= (flags) peut signaler modifiedbody, modifiedheader, exploded, donotmodify, feedback, etc.

4. Rebonds et retours d'information

   • Les DSN et feedback sont renvoyés en amont de la chaîne vers un acteur impliqué, limitant le backscatter.
   • Possibilité d'indiquer des préférences de feedback (selon les versions de brouillon).

5. Compatibilité et cohabitation

   • DKIM2 n'obsolète pas immédiatement DKIM (RFC 6376) : cohabitation attendue pendant une phase de transition.
   • Les enregistrements DNS restent sous _domainkey. La signature par procuration (pp=) est prévue, avec des contraintes d'alignement et des preuves d'autorisation via DNS (p. ex. enregistrement dédié ou relation MX), selon les brouillons.

Ce qui disparaît ou change sensiblement

• Pas de v= dans DKIM2-Signature (si une rupture majeure arrive, un futur "DKIM3‑Signature" serait créé, plutôt qu'un numéro de version interne).
• Liste d'en‑têtes signés simplifiée : un socle de champs obligatoires est fixé ; h= reste possible pour des cas spécifiques.
• Gestion d'expiration simplifiée : appui sur t= et recommandations côté vérifieurs plutôt qu'un champ dédié strictement normatif.
• Paramètres hérités de DKIM jugés trop complexes (ex. z=) délaissés dans les premiers brouillons.

⚠️ DKIM2 est en cours de rédaction : la syntaxe exacte (noms de tags, flags, délais) peut encore bouger. Vérifiez les versions de drafts citées ci‑dessous.

Exemple d'en‑têtes (brouillons actuels)

DKIM2-Signature: i=1; t=2025-10-24T08:01:02Z; d=example.com; s=sel2025;
  a=ed25519-sha256; bh=BASE64(...); b=BASE64(...);
  rt=user@dest.tld; mf=bounce@example.com; mv=2; f=modifiedheader,feedback

MailVersion: v=2; bh=BASE64(...);
  h.Subject=d:*,t:[Re] Offre spéciale;
  h.From=d:*,b:am9obi5kb2VAZXhhbXBsZS5jb20=

Impacts opérationnels (résumé)

• ESP / relais : devoir signer chaque saut, gérer mf=/rt=, enregistrer/annuler les modifs simples (recettes), et réémettre vers des domaines cibles alignés.
• Destinataires : vérifier d'abord la dernière signature (i=Max), puis remonter si nécessaire ; rejeter tôt en cas d'échec dur.
• DNS : sélecteurs et clés inchangés sous _domainkey, autorisations "proxy" à prévoir selon le mécanisme DNS retenu par les drafts.
• DMARC : tant que DMARCbis référence DKIM (RFC 6376), DMARC continue de s'appuyer sur DKIM. La bascule DMARC→DKIM2 n'est pas immédiate.

Chronologie : jalons récents

• 5 nov. 2024 : premiers articles d'analyse publique sur DKIM2 (ex. Red Sift).
• 20 nov. 2024 : billets d'annonce par des acteurs DMARC.
• 3 sept. 2025 : adoption du Motivation en document de groupe IETF (draft-ietf-dkim-dkim2-motivation-01).
• 17–20 oct. 2025 : publication des drafts -spec-02 (spécification), -dns-03 (DNS), -header-04 (en‑têtes) et -modification-algebra-04 (MailVersion).

Plan de préparation

1. Inventorier où vous signez/vérifiez déjà DKIM (flux, sauts, SRS/VERP, ML).
2. Prototyper côté relais : calcul mf=/rt=, ajout i=, choix des algo (Ed25519 recommandé), gestion t=.
3. Tracer les modifs courantes (footers ML, réécriture From:) et tester l'annulation via MailVersion.
4. DNS : normaliser le cycle de rotation de clés ; préparer le mécanisme d'autorisation "proxy" si nécessaire.
5. Vérification : implémenter la stratégie "dernier i= d'abord", rejets 5xx à l'échange SMTP si signature invalide, 4xx sur TEMPFAIL DNS.
6. Surveiller les drafts (ci‑dessous) et prévoir des feature flags pour suivre les changements de champ.

Glossaire

Replay DKIM

• Définition : ré‑utilisation (rejeu) d'un message déjà signé DKIM par un domaine légitime pour le réexpédier à grande échelle ou vers d'autres cibles, sans altérer ce qui est couvert par la signature. La signature reste valide car DKIM signe le contenu (corps/en‑têtes) mais pas l'enveloppe SMTP ni la route.
• Pourquoi ? : un attaquant obtient un exemplaire d'un e‑mail signé (p. ex. une newsletter) et le re‑diffuse tel quel ; DMARC peut continuer de passer si From: reste aligné.
• Symptômes : pics de volume sur une même signature (bh= identique), plaintes spam, réputation dégradée pour le domaine signataire.
• Mitigations : limitation de débit par sélecteur, rotation de clés, durées de vie courtes, durcissement DMARC (p=reject), filtrage comportemental côté réception.
• Ce que DKIM2 change : la signature inclut l'enveloppe par saut (mf=/rt=) et chaîne le chemin (numéro i=), ce qui rend le rejeu détectable (route non cohérente) et permet des sanctions ciblées.

Backscatter

• Définition : rebonds indésirables (NDR/DSN) ou auto‑réponses envoyés à un tiers innocent dont l'adresse a été usurpée en MAIL FROM/Return‑Path.
• Pourquoi ? : des serveurs acceptent d'abord le message, puis génèrent un rebond ultérieur ; avec une adresse usurpée, le rebond repart vers la victime.
• Symptômes : inondation de DSN/auto‑réponses sur une boîte légitime, réputation abîmée, blacklistages éventuels.
• Mitigations : rejeter pendant l'échange SMTP (pas après), SPF/DMARC stricts, SRS/VERP pour tracer les rebonds, règles anti‑auto‑réponses.
• Ce que DKIM2 change : les DSN/feedback sont routables en amont via la chaîne signée, ce qui réduit le backscatter et permet d'atteindre l'acteur réellement impliqué.

Sources et pour aller plus loin

• DKIM2 – spécification : draft‑clayton‑dkim2‑spec‑02 (20 octobre 2025, expire le 23 avril 2026).
• DKIM2 – DNS : draft‑chuang‑dkim2‑dns‑03 (20 octobre 2025).
• DKIM2 – en‑têtes : draft‑gondwana‑dkim2‑header‑04 (20 octobre 2025).
• DKIM2 – algebra des modifications / MailVersion : draft‑gondwana‑dkim2‑modification‑algebra‑04 (17 octobre 2025).
• Motivation (document de groupe IETF) : draft‑ietf‑dkim‑dkim2‑motivation‑01 (3 septembre 2025, remplace les versions individuelles).
• Rappels DKIM : RFC 6376 ; mises à jour : RFC 8301, RFC 8463.

DKIM2 reste "work in progress". Cette page sera mise à jour quand les drafts évolueront vers une RFC.