# DKIM2 (travaux de l'IETF en cours)

> La refonte de DKIM par le groupe de travail DKIM de l'IETF : signatures chaînées à chaque saut et liées à l'enveloppe SMTP, modifications documentées (« recipes »), rebonds authentifiés, résistance au rejeu, avec l'état du groupe de travail en juillet 2026. Ce n'est PAS une norme publiée.

Source: emailmarketing.net — https://emailmarketing.net/fr/apprendre/authentification/dkim2

Si vous signez vos messages avec DKIM, une refonte appelée DKIM2 est en préparation. Elle doit corriger le rejeu et les dégâts que les services de transfert et les listes de diffusion causent aux signatures. Elle n'est pas prête à être déployée, mais elle mérite d'être suivie, afin que vos systèmes de signature puissent s'adapter le moment venu.

> **Avertissement sur le statut : il s'agit de travaux de normalisation en cours, et non d'une norme que vous pouvez déployer.** Tout ce qui suit est tiré d'Internet-Drafts actifs du groupe de travail **dkim** de l'IETF, qui a reçu une nouvelle charte, 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 leur signification **vont changer** d'une révision à l'autre, et le chantier peut aussi s'arrêter complètement. Ne construisez pas de systèmes de production qui dépendent de ces détails ; servez-vous-en pour suivre la direction des travaux. [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim) (RFC 6376, STD 76) reste la norme en vigueur.

## Pourquoi DKIM2 existe

DKIM v1 présente deux faiblesses de conception que l'écosystème de l'email contourne 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](https://emailmarketing.net/fr/apprendre/authentification/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, et DMARC sanctionne ensuite ces messages. [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc) consigne ce qu'un intermédiaire a vu, mais pas ce qu'il a modifié, et vous oblige à faire confiance à l'intermédiaire.

La réponse de DKIM2 est que chaque saut qui traite le message le signe, que chaque signature est **liée à l'enveloppe SMTP de ce saut**, et que les modifications sont **enregistrées de façon réversible**, afin que le serveur de réception final puisse reconstituer et vérifier le message tel qu'il a été signé à l'origine. Par effet secondaire, les rebonds deviennent entièrement **authentifiés**, ce qui élimine le [backscatter](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/backscatter-et-batv).

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

| Document | Version et date | État |
|---|---|---|
| draft-ietf-dkim-dkim2-spec | -04, 2026-07-05, 43 p. | Document du groupe de travail, destiné à la voie normative (Standards Track). Auteurs : R. Clayton (Yahoo), W. Chuang (Google), B. Gondwana (Fastmail). Expire le 2027-01-06. |
| draft-ietf-dkim-dkim2-bcp | -00, 2026-06-18, 16 p. | Document du groupe de travail. Auteur : T. Herr (GreenArrow). Remplace le draft individuel draft-herr-dkim2-bcp (-01, expiré). Expire le 2026-12-20. |
| draft-ietf-dkim-dkim2-dns | -00, 2026-07-20, 13 p. | Document du groupe de travail (la spécification DNS de DKIM2). Adopté à partir du draft individuel draft-chuang-dkim2-dns. |
| draft-moccia-dkim2-deployment-profile | -06, 2026-07-19 | **Contribution individuelle, non adoptée par le groupe de travail.** Un profil conçu pour être déployable sous forme de milter (voir plus bas). |
| draft-ietf-dkim-replay-problem | -00, 2023-07-28 | Énoncé du problème, expiré, qui a mené à la nouvelle charte. |

Les auteurs travaillent chez Yahoo, Google et Fastmail, ce qui montre l'adhésion des serveurs de réception, et c'est cette adhésion qui a fait aboutir ou échouer les normes de messagerie par le passé. Les archives de la liste de diffusion se trouvent sur 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, avec ces balises :
- `m=` le numéro de révision (la version de l'émetteur d'origine est 1, et tout saut qui modifie le message l'incrémente)
- `h=` les empreintes de cette instance, au format `sha256:<header-hash>:<body-hash>`
- `r=` des « recipes » JSON encodées en base64 pour reconstituer l'instance précédente (voir plus bas)

**`DKIM2-Signature`** : une par saut qui traite le message, avec ces balises :
- `i=` le numéro de séquence du saut (celui de l'émetteur d'origine est 1, et chaque signataire l'incrémente ; **un trou dans `i=` ou `m=` invalide la chaîne**)
- `m=` l'instance Message-Instance que ce saut a signée
- `t=` un horodatage Unix (rejeter les horodatages dans le futur ; PEUT ignorer les signatures datant de >14 jours)
- `mf=` le base64 du reverse-path `MAIL FROM` de la RFC 5321 utilisé à ce saut (`<>` pour les DSN)
- `rt=` le base64 des forward-paths `RCPT TO` de la RFC 5321 utilisés à ce saut
- `nd=` « next domain » (domaine suivant), qui relie des transmissions internes sans véritable transaction SMTP
- `n=` un nonce facultatif (≤64 caractères), et `f=` des indicateurs
- `d=` et `s=`, le domaine et le sélecteur comme dans DKIM1, avec la valeur de la signature écrite `<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é avec son `d=` (correspondance souple), et que le `rt=` du saut précédent (i−1) correspond au `mf=` du saut i.
- Le serveur du destinataire contrôle que le `RCPT TO` réel de la transaction qui livre le message correspond au dernier `rt=`. **Un message rejoué porte le destinataire d'origine dans le `rt=` signé, donc l'envoyer à de nouveaux RCPT TO casse la chaîne.** C'est la correction du rejeu que DKIM1 n'a aucun moyen d'exprimer.
- La diffusion légitime d'un expéditeur vers de nombreux destinataires doit être déclarée ouvertement. `f=exploded` signale une distribution délibérée à de nombreux destinataires (listes de diffusion), `f=donotexplode` demande une livraison à un seul destinataire, et `f=donotmodify` interdit toute modification du contenu (une violation entraîne un FAIL et bloque tout transfert ultérieur).

### Recipes : des enregistrements de modification réversibles

Un intermédiaire qui modifie un message (en ajoutant un pied de page de liste ou une balise dans l'objet) incrémente `m=` et publie dans `r=` une description JSON de la différence, afin que l'instance précédente puisse être reconstituée :

- `"h"` associe des noms d'en-têtes à des étapes, et `"b"` contient les étapes du corps.
- Les étapes sont soit `{"c":[start,end]}`, qui copie des plages (les en-têtes sont numérotés de bas en haut, et les lignes du corps de haut en bas à partir de 1), soit `{"d":[...]}`, qui insère des valeurs littérales.
- `"b": null` déclare une modification du corps qui ne peut pas être inversée.

Le vérificateur final remonte les recipes jusqu'à l'instance 1 et contrôle la signature de l'émetteur d'origine. Cela résout le problème des listes de diffusion face à DMARC sans la confiance aveugle qu'exige ARC.

Le BCP soulève une préoccupation de vie privée : les recipes peuvent réintégrer un contenu qu'un intermédiaire a délibérément retiré, comme des caviardages de prévention des pertes de données (DLP) ou des pièces jointes malveillantes supprimées. Les recipes nulles sont la porte de sortie, et les recommandations pour les juridictions soumises au RGPD restent une question ouverte.

### Cryptographie et canonicalisation simplifiées

- Empreinte : SHA-256 est obligatoire. Signature : `rsa-sha256` (PKCS#1 v1.5, e=65537, clés de ≥1024 bits ; les vérificateurs prennent en charge 1024–2048) et `ed25519-sha256` (PureEdDSA de la RFC 8032). Le BCP recommande de signer avec **les deux** algorithmes.
- Une canonicalisation unique remplace le choix de DKIM1 entre simple et relaxed. Pour l'entrée de la signature, les noms d'en-têtes sont mis en minuscules, les en-têtes sont dépliés, et **toutes les espaces sont supprimées**. 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 fonctionne comme la canonicalisation simple (les lignes vides de fin sont réduites à un seul CRLF). Le calcul se fait sur la forme transmise sur le fil (après l'encodage de transfert du contenu, avant le dot-stuffing).
- Ces en-têtes sont exclus de l'empreinte des en-têtes : `Received`, `Return-Path`, `Delivered-To`, `DKIM-Signature`, `ARC-*`, `Authentication-Results`, `X-*`, `Message-Instance`, `DKIM2-Signature`.
- Il n'y a pas de balise `v=`, car le nouveau nom d'en-tête identifie la version. Les enregistrements de clé se trouvent **au même emplacement**, `<selector>._domainkey.<domain>`, avec un `k=` qui correspond à l'algorithme. DKIM1 et DKIM2 peuvent donc 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

- Les résultats (compatibles avec la RFC 8601) sont PASS, FAIL, PERMERROR et TEMPERROR, avec des messages d'erreur normalisés que les personnes peuvent lire (par exemple `FAIL: Message Instance m=<x> body hash <value> mismatch`).
- **Les notifications d'état de livraison (DSN) sont envoyées au `mf=` de la DKIM2-Signature qui porte le 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 renvoie la DSN d'un saut en arrière, après avoir vérifié que le message intégré correspond à ce qu'il avait signé et avoir retiré ses propres en-têtes DKIM2.
- Par conséquent, les rebonds sont authentifiés de bout en bout, et le [backscatter](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/backscatter-et-batv) ne peut pas se produire pour les messages qui restent dans l'écosystème DKIM2. Les indicateurs `feedback` et `feedhere` esquissent un canal de retour sur la livraison (détails pas encore définis).

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

- **Expéditeurs :** signez à la fois avec DKIM1 et DKIM2 « jusqu'à ce que le déploiement soit effectivement généralisé » (« until deployment is effectively ubiquitous »), avec RSA et Ed25519. Ne signez qu'au point où les messages quittent vos systèmes, et faites tourner les clés selon les pratiques du M3AAWG.
- **Services de transfert :** vérifiez les messages à leur arrivée, et signez chaque message à sa sortie (modifié ou non) pour garder la chaîne intacte. N'ajoutez votre signature qu'aux 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 que vous les ajoutiez à votre chaîne.
- **Serveurs de réception :** pour les messages entièrement à l'intérieur de l'écosystème DKIM2, une chaîne rompue **peut être rejetée sans risque**, car il est prouvé que la DSN atteint une partie responsable. Pour les chaînes partielles ou absentes, revenez à DKIM1 et à la politique locale pendant la transition.
- Le draft liste lui-même des questions ouvertes : des limites au nombre d'en-têtes Message-Instance et de signatures, le rôle futur de DMARC et de SPF, et la signification 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)

Ce draft individuel, non adopté par le 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 se distingue parce qu'il utilise **d'autres dispositions d'en-têtes** (`DKIM2-Sig-mf`, `DKIM2-Sig-rt` et `DKIM2-Mod`) que la spécification du groupe de travail, ce qui montre à quel point le format sur le fil reste instable :

- **DKIM2-core** (le niveau obligatoire) : la liaison à l'enveloppe, la chaîne de responsabilité, les déclarations de modification des en-têtes et l'authentification des DSN. Le tout est sans état et peut être implémenté sous forme de **milter, sans modification du cœur de l'agent de transfert de courrier (MTA)**. Le coprésident du groupe de travail M. Kucherawy l'a confirmé, et un prototype fonctionnel a été publié. Limites : au plus `i≤20` sauts (~15–16 dans le pire cas réaliste), ≤500 destinataires par saut, et une correspondance souple de domaine limitée au retrait de 2 libellés.
- **DKIM2-extended** (facultatif) : les recipes complètes pour le corps et la reconstitution à partir des en-têtes Message-Instance. Il exige un état persistant, sera plus long à adopter, et implique une charge plus lourde en matière de vie privée.
- Règle en cas d'algorithmes multiples : si l'une des signatures d'un saut échoue, tout le saut est invalide (ce qui empêche les attaques par rétrogradation).

## Calendrier réaliste et ce qu'un ESP devrait faire

- Aucune RFC n'existe encore, et la spécification centrale en est à la version -04, avec d'importantes questions non résolues. Même après publication, DKIM2 n'apporte ses garanties que lorsque chaque saut d'un chemin y participe. Attendez-vous à une **transition de plusieurs années**, pendant laquelle signer à la fois avec DKIM1 et DKIM2 sera la norme, et DKIM1 avec DMARC restera ce qu'appliquent les fournisseurs de messagerie. Pour comparaison, ARC (RFC 8617, 2019) n'est encore que partiellement déployé.
- Ce qu'un fournisseur de services de messagerie (ESP) devrait faire maintenant : rien en production. Suivez les révisions du draft et la liste ietf-dkim. Assurez-vous que vos chaînes de signature peuvent ajouter un second type de signature et des données d'enveloppe pour chaque message, ce qui est la principale exigence d'architecture de DKIM2. Continuez d'appliquer les protections actuelles contre le rejeu ([sursignature, sélecteurs par flux](https://emailmarketing.net/fr/apprendre/authentification/attaques-par-rejeu-dkim)).
- Ce qu'il faut surveiller : le dernier appel du groupe de travail (WG last call) sur dkim2-spec, l'annonce de pilotes côté réception chez Gmail, Yahoo et Fastmail (les employeurs des coauteurs), et l'intégration ou non des simplifications du profil milter.

## Voir aussi

- [DKIM](https://emailmarketing.net/fr/apprendre/authentification/dkim), la norme actuelle à laquelle DKIM2 succéderait à terme
- [Attaques par rejeu DKIM](https://emailmarketing.net/fr/apprendre/authentification/attaques-par-rejeu-dkim)
- [ARC](https://emailmarketing.net/fr/apprendre/authentification/arc), le mécanisme provisoire pour les intermédiaires que DKIM2 vise à rendre obsolète
- [Backscatter et BATV](https://emailmarketing.net/fr/apprendre/gestion-des-rebonds/backscatter-et-batv)