DKIM2 : où en est la normalisation et comment s'y préparer

⚡TL;DR

• DKIM2 n'est pas un standard : aucune RFC, aucun document en dernier appel, et un calendrier de charte IETF en retard d'environ sept mois.
• Le travail se fait dans le groupe de travail dkim historique, rechartré en février 2025. Il n'existe pas de groupe « dkim2 ».
• La spécification actuelle (draft-ietf-dkim-dkim2-spec-04, 5 juillet 2026) repose sur deux en-têtes : DKIM2-Signature par saut, et Message-Instance pour décrire les modifications sous forme de recettes JSON.
• Presque toute la syntaxe de 2025 a disparu : mv=, pp=, a=, b=, bh=, l'en-tête Mail-Version:.
• Trois implémentations (Rust, Python, Go) ont démontré leur interopérabilité en juillet 2026, et une quatrième, en C, a été annoncée ensuite : le changement d'état le plus concret depuis un an.
• Propriétaire de domaine : rien à faire. Vos clés et vos enregistrements _domainkey restent valables tels quels.

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

DKIM2 traîne une réputation contradictoire. On lit qu'il remplacera DKIM « bientôt », qu'il rendra DMARC caduc, ou au contraire qu'il n'existe que sur le papier. La réalité de juillet 2026 est plus simple : le protocole n'est toujours pas normalisé, mais il a cessé d'être théorique, puisque trois implémentations indépendantes signent, vérifient et reconstruisent des messages ensemble.

Pourquoi DKIM2 existe-t-il ?

DKIM (STD 76, RFC 6376) signe le contenu d'un message. C'est sa force et, au bout de vingt ans d'exploitation, sa limite : la signature ne dit rien du chemin emprunté ni des adresses réellement utilisées à chaque saut SMTP.

Le replay que DKIM ne ferme pas

Un attaquant qui récupère un message légitimement signé peut le réexpédier massivement sans toucher à ce que couvre la signature : elle reste valide, DMARC continue de passer, et c'est le domaine signataire qui encaisse la dégradation de réputation. C'est le replay DKIM, qu'aucune rotation de clé n'élimine vraiment.

Le transfert qui casse la signature

Le hash signé est invalidé dès qu'une liste de diffusion ajoute un pied de page, préfixe le sujet ou insère un en-tête de désabonnement. DKIM n'offre aucun moyen de décrire la modification, donc aucun moyen de revenir en arrière pour vérifier la signature d'origine.

Les rebonds qui repartent vers un tiers

Quand un serveur accepte un message puis génère un rebond après coup, ce rebond part vers l'adresse d'enveloppe, éventuellement usurpée. C'est le backscatter : une victime innocente reçoit des rapports de non-remise pour du courrier qu'elle n'a jamais envoyé.

DKIM2 s'attaque aux trois à la fois : chaque saut appose sa propre signature numérotée, déclare l'enveloppe qu'il a utilisée, et documente ce qu'il a modifié. Le chemin devient vérifiable et les modifications réversibles.

Où en est la normalisation ?

Un groupe rechartré, trois documents

Il n'existe pas de groupe de travail « dkim2 » à l'IETF, et c'est la première source d'erreur. Le travail se déroule dans le groupe dkim historique, dont la charte révisée a été approuvée par l'IESG le 20 février 2025, sous la présidence de Murray Kucherawy et Pete Resnick.

Trois documents de groupe sont actifs :

• draft-ietf-dkim-dkim2-spec-04 (5 juillet 2026), Standards Track, 43 pages, expire le 6 janvier 2027. Auteurs : Richard Clayton (Yahoo), Wei Chuang (Google), Bron Gondwana (Fastmail).
• draft-ietf-dkim-dkim2-bcp-00 (18 juin 2026), Todd Herr. Adopté, mais délibérément mis en attente tant que le groupe n'a pas accumulé d'expérience opérationnelle.
• draft-ietf-dkim-dkim2-dns-00 (20 juillet 2026), Wei Chuang.

Ce que dit le calendrier

Aucun de ces documents n'est en dernier appel de groupe (WG Last Call), aucun n'a été soumis à l'IESG, aucune RFC n'existe. Or les jalons de la charte visaient « tous les documents soumis à l'IESG au 31 décembre 2025 » : le retard est d'environ sept mois, et le calendrier n'a pas été révisé.

Les jalons réels de la période écoulée sont peu nombreux. Novembre 2025 : les brouillons motivation, header et mailversion cessent d'être maintenus. 20 mars 2026, à l'IETF 125 : la spécification de Richard Clayton devient le document principal et le format JSON est retenu pour décrire les modifications. 24 mars 2026 : premier brouillon de groupe de la spécification. 24 juin 2026 : spec-03 introduit le tag nd=. 24 juillet 2026 : session DKIM à l'IETF 126, à Vienne.

Les documents morts

Tout contenu rédigé en 2025 sur DKIM2 renvoie à des brouillons aujourd'hui abandonnés ou remplacés : vérifiez toujours les noms et les révisions cités. draft-ietf-dkim-dkim2-motivation-02 a expiré ; draft-ietf-dkim-dkim2-header-00 et draft-gondwana-dkim2-mailversion-00 sont marqués « Dead WG Document ». Leur contenu a été absorbé, réécrit ou abandonné.

Autre erreur qui circule : plusieurs publications affirment que le groupe aurait adopté un « profil de déploiement via milter ». C'est faux. Le 8 mai 2026, le président du groupe a écrit que « the working group does not wish to pursue adoption at this time ».

Ce que DKIM2 change concrètement

La mécanique repose sur deux en-têtes distincts.

L'en-tête DKIM2-Signature

Chaque saut ajoute une ligne. Le paragraphe 8 de la spécification fixe les obligations : « The i=, m=, t=, d= and s= tags MUST be present. There MUST be either an nd= tag or both mf= and rt= tags. The other tags are optional. »

Tag	Obligatoire	Rôle
i=	oui	Numéro de séquence du saut. L'émetteur d'origine signe avec i=1, chaque saut suivant incrémente. Si la numérotation présente un trou, le message entier est considéré comme non signé.
m=	oui	Numéro du Message-Instance le plus élevé au moment de la signature.
t=	oui	Horodatage, exprimé en secondes epoch UTC (un entier, pas une date formatée).
d=	oui	Domaine signataire. C'est lui qui sert à construire la requête DNS de récupération de clé.
s=	oui	Triplet sélecteur:algorithme:signature-base64.
mf=	conditionnel	MAIL FROM utilisé à l'émission, encodé en base64, chevrons compris.
rt=	conditionnel	RCPT TO, base64, chevrons compris. Plusieurs destinataires peuvent être listés.
nd=	conditionnel	Domaine qui signera le saut suivant. Exclusif de mf= et rt=.
n=	non	Nonce libre, 64 caractères au maximum.
f=	non	Drapeaux.

Le tag s= suit l'ABNF sig-set = selector ":" sig-name ":" message-sig, où sig-name vaut rsa-sha256 ou ed25519-sha256 ; plusieurs signatures d'algorithmes différents peuvent coexister, mais « a different selector MUST necessarily be used for each signature ». Le d=, lui, doit correspondre exactement aux labels les plus à droite du domaine porté par mf= : autrement dit, d= est soit identique à ce domaine, soit l'un de ses domaines parents. Un mf=<user@mail.example.com> va donc avec d=example.com, alors que l'inverse, mf=<user@example.com> avec d=mail.example.com, est refusé. Seul un mf= vide (<>), le cas des rapports de non-remise, dispense de cette correspondance.

Côté cryptographie, la spécification impose du RSA d'au moins 1024 bits en signature et exige des vérificateurs qu'ils acceptent de 1024 à 2048 bits, la prise en charge de clés plus grandes restant facultative. L'exposant public est 65537, le remplissage PKCS#1 v1.5, le hash non tronqué, SHA256 obligatoire, et Ed25519 en variante PureEdDSA (RFC 8032, paragraphe 5.1) : « Signers SHOULD implement both RSA-SHA256 and Ed25519-SHA256, Verifiers MUST implement both ». Une signature vieille de plus de 14 jours peut être ignorée, mais c'est un MAY, pas une obligation.

Les drapeaux f= ont été refondus. exploded indique que le message part vers plus d'une adresse ; son absence autorise un MTA à supposer qu'une seule copie existe, et c'est précisément le levier anti-replay. donotexplode et donotmodify sont des interdictions adressées aux intermédiaires. feedback demande un retour, son absence signifie que ce retour n'est pas souhaité, et feedhere permet à un intermédiaire de relayer ce retour sans révéler la destination finale. Tout drapeau inconnu doit être ignoré.

Un vérificateur produit l'un des quatre états PASS, FAIL, PERMERROR ou TEMPERROR, alignés sur la RFC 8601.

Le Message-Instance

Le second en-tête décrit l'état du message et le moyen de revenir au précédent : « The m= and h= tags MUST be present. The r= tag is optional. »

Le tag m= est le numéro de révision : 1 à l'origine, incrémenté à chaque nouvelle instance ; un trou rend le message invérifiable. Le tag h= prend la forme sha256:<hash des en-têtes>:<hash du corps>, les deux en base64, et plusieurs jeux peuvent coexister. Le tag r= contient « the base64 encoded version of the JSON object that contains the recipes that allow the previous instance of the message to be recreated ».

Point important pour les opérateurs : si vous ne modifiez rien, vous n'ajoutez pas de Message-Instance ; un relais qui transmet le message tel quel n'a rien à décrire.

Les recettes forment un objet JSON, identifié par le schéma https://dkim2.org/schemas/recipe-v1, avec une clé "h" pour les en-têtes et/ou "b" pour le corps. Chaque recette est un tableau d'étapes portant exactement une clé : {"c": [début, fin]} copie une plage de lignes ou d'occurrences, {"d": ["..."]} émet des données littérales. Un "b": null signale un corps précédent non reconstructible ; un tableau vide associé à un nom de champ signifie « supprime toutes ses occurrences ». Piège classique : les en-têtes sont numérotés de bas en haut, les lignes de corps de haut en bas.

Vos clés DNS ne changent pas

La clé publique se récupère sous <sélecteur>._domainkey.<d=>, exactement comme aujourd'hui : « these keys are no different, and are stored in the same locations as those for DKIM1 ». Aucun nouveau type d'enregistrement, aucune migration DNS à préparer.

nd= ou mf=/rt= : la chaîne de garde

Une séquence de plusieurs DKIM2-Signature portant nd= est permise, mais elle « MUST end with a DKIM2-Signature that contains mf= and rt= tags », et le domaine déclaré dans nd= doit correspondre exactement au d= de la signature suivante dans l'ordre des i=.

Le paragraphe 9.3 présente cette variante comme une chaîne de garde pour des sauts fictifs. Prenez un système qui reçoit du courrier sur un domaine et le réexpédie depuis un autre : la continuité entre le rt= du saut précédent et le mf= du saut suivant est rompue. Plutôt que de fabriquer une signature avec des mf= et rt= inventés, qui pollueraient la chaîne d'adresses fictives, ce système annonce avec nd= quel sera le prochain signataire. C'est l'option que la spécification encourage.

Exemple d'en-têtes

spec-04 ne contient aucun exemple de message ou d'en-tête : le brouillon qui devait les fournir, draft-robinson-dkim2-message-examples-00, a expiré en 2025. L'exemple ci-dessous est donc reconstruit à partir de la grammaire ABNF du document, et n'a aucune valeur normative.

Scénario à deux sauts : un expéditeur écrit à une liste de diffusion, la liste ajoute un en-tête List-Unsubscribe et réexpédie.

DKIM2-Signature: i=2; m=2; t=1740001000; d=test2.dkim2.com;
  mf=PGJvdW5jZUB0ZXN0Mi5ka2ltMi5jb20+; rt=PHJlY2lwaWVudEBleGFtcGxlLmNvbT4=;
  s=ed25519:ed25519-sha256:FDYZopU8W+c7...;
DKIM2-Signature: i=1; m=1; t=1740000000; d=test1.dkim2.com;
  mf=PHNlbmRlckB0ZXN0MS5ka2ltMi5jb20+; rt=PGxpc3RAdGVzdDIuZGtpbTIuY29tPg==;
  s=ed25519:ed25519-sha256:oKZmf7rabJv4...;
Message-Instance: m=2; h=sha256:u4RFAizDeEqt...:SgG5fNGEg1x2...;
  r=eyJoIjp7Imxpc3QtdW5zdWJzY3JpYmUiOltdfX0=;
Message-Instance: m=1; h=sha256:SLtzk6LO68CC...:SgG5fNGEg1x2...;
Received: from test1.dkim2.com by relay.example.com; ...
List-Unsubscribe: <mailto:unsub@relay.example.com>
From: sender@test1.dkim2.com
To: list@test2.dkim2.com
Subject: ...

Décodons. Les valeurs d'enveloppe sont en base64, chevrons compris, comme l'exige la spécification. Au premier saut, mf= vaut <sender@test1.dkim2.com> et rt= vaut <list@test2.dkim2.com>. Au second, la liste réexpédie : mf= vaut <bounce@test2.dkim2.com> et rt= vaut <recipient@example.com>. La continuité de la chaîne est visible à l'œil nu, et c'est tout l'intérêt du mécanisme.

Le passage le plus instructif est le r= du Message-Instance numéro 2. Décodé depuis le base64, il donne :

{"h":{"list-unsubscribe":[]}}

Traduction en français : « pour revenir à l'instance précédente, supprime toutes les occurrences du champ List-Unsubscribe ». Un vérificateur qui veut valider la signature i=1 applique cette recette, retrouve le message tel que l'expéditeur l'a émis, recalcule le hash et compare. La modification n'a pas cassé la chaîne : elle a été déclarée et rendue réversible.

Les valeurs de s= et les hachages du h= sont tronqués : ils dépendraient de clés privées et d'un message réel, et ne sont donc pas recalculables par le lecteur. L'exemple sert à montrer la structure des en-têtes, pas à être vérifié.

Ce qui a changé depuis les brouillons de 2025

Si vous avez lu un guide DKIM2 publié fin 2025, à peu près toute la syntaxe qu'il décrivait a disparu.

Élément de 2025	Statut dans spec-04
En-tête unique DKIM2: (Active/Historical)	Supprimé, remplacé par le couple DKIM2-Signature et Message-Instance
En-tête Mail-Version:	Supprimé, refondu en Message-Instance ; les recettes compactes cèdent la place à du JSON encodé en base64
mv=	Renommé m=
v=	N'existe pas et n'existera pas
pp= (procuration)	Supprimé ; nd= occupe cette place depuis spec-03 (24 juin 2026)
a=	Supprimé, fusionné dans s=
b=	Supprimé, absorbé par s=
bh=	Déplacé dans le h= du Message-Instance
h= (liste des champs signés)	Sens inversé : DKIM2 signe tout sauf une liste d'exclusion
t=	Passe d'une date formatée à un entier epoch
f=modifiedbody, f=modifiedheader	Supprimés, jugés redondants avec les données de version
f=donotforward	Supprimé
f=feedhere	Nouveau, apparu en spec-03

L'absence de v= est délibérée

Le paragraphe 8 le justifie : « Experience from IMF onwards shows that it is essentially impossible to change version numbers. If it becomes necessary to change DKIM2 in the sort of incompatible way that a v=2 / v=3 version number would support, it is expected that header fields will be labelled as DKIM3 instead. » Une rupture majeure produirait donc un en-tête DKIM3-Signature, pas un numéro de version interne.

L'inversion du h=

DKIM énumère les champs qu'il signe. DKIM2 fait l'inverse : il signe tout, sauf sept familles de champs listées au paragraphe 4.1, à savoir ARC-*, Authentication-Results, Delivered-To, DKIM-Signature, Received, Return-Path et X-*. Exactement les champs qu'un intermédiaire est légitimement amené à ajouter ou modifier en transit.

ARC part à la retraite

ARC répondait au même symptôme : le transfert casse SPF et DKIM. Mais il se contentait de transporter un témoignage scellé des résultats d'authentification constatés avant le relais, sans jamais fermer la faille de replay. C'est de la traçabilité, pas de l'intégrité de bout en bout. L'IETF le reclasse aujourd'hui en statut « Historic » et concentre l'effort sur DKIM2, qui traite la cause plutôt que le symptôme. Le détail de cette reclassification et ses conséquences pratiques font l'objet d'un article dédié.

Où en sont les implémentations ?

C'est ici que l'année a été décisive : on est passé de zéro implémentation à trois qui se comprennent, et une quatrième a été annoncée depuis.

Le 4 juillet 2026, une démonstration d'interopérabilité a réuni trois implémentations indépendantes : mail-auth en Rust (Stalwart Labs), l'implémentation Python de Bron Gondwana, et l'implémentation Go de Steve Atkins. Signature, vérification et reconstruction par recettes ont été testées dans les deux sens, y compris sur des chaînes multi-sauts. Résultat annoncé : avec le repliement des en-têtes désactivé, toutes les combinaisons passent. Deux bugs de repliement ont été identifiés au passage, l'un côté Go (base64 strict, sans retrait des espaces), l'autre côté Python (découpage sur : sans dépliage préalable).

Le 8 juillet 2026, Bron Gondwana a centralisé la suite de tests dans l'organisation GitHub dkim2wg et mentionné une quatrième implémentation, en C (PhoenixDKIM).

Sur le calendrier, les pronostics existent, datés et attribués. Laura Atkins (Word to the Wise, 23 avril 2026) s'attend à voir du DKIM2 fonctionnel chez les grands fournisseurs d'ici fin 2026. Al Iverson (Spam Resource, 21 avril 2026) rappelle que la spécification n'est pas encore finalisée et que les choses peuvent bouger, et souligne que les clés, elles, ne changent pas à ce stade. Aucune source primaire n'annonce de date d'obligation pour les expéditeurs, et les calendriers qui circulent ne s'appuient sur rien de tel.

Ce qui n'est pas encore tranché

Le groupe s'est réuni à l'IETF 126, à Vienne, le 24 juillet 2026. Les points suivants y ont été posés, pas tranchés ; les comptes rendus de la session ne sont pas encore publiés.

1. Recettes nulles pour les en-têtes : faut-il les supprimer, faute de cas d'usage identifié ?
2. Message-Instance fallacieux : les MUST NOT actuels sont trop stricts et ont provoqué des rejets de messages pendant les essais d'interopérabilité.
3. Algorithme post-quantique : le groupe cherche l'avis d'experts, la difficulté identifiée étant que des clés très longues passent mal dans le DNS sur UDP.
4. Casse des noms de champs : faut-il imposer les minuscules dans les recettes JSON ?
5. Rapports de non-remise : faut-il prévoir un drapeau dédié et omettre le Message-Instance ?
6. Alignement et DMARC : « The DKIM2 spec deliberately stays away from saying anything about DMARC », le sujet est renvoyé au document de bonnes pratiques. L'attente exprimée est un alignement entre le From: d'origine, le MAIL FROM initial et le d= de la première DKIM2-Signature, alors que DKIM2 n'exige aujourd'hui que l'alignement des deux derniers.
7. Messages relayés en DKIM1 seul : faut-il les signer en DKIM2 ?
8. Boucles de retour : faut-il en standardiser le format ?

Cette liste est la meilleure mesure de la maturité réelle du protocole, et la raison pour laquelle le document de bonnes pratiques reste en attente.

Impacts opérationnels

Les conséquences ne sont pas les mêmes selon votre rôle, et la répartition est déséquilibrée.

Propriétaire de domaine : rien à faire

Aucune action à mener aujourd'hui. La seule chose utile est de garder un DKIM1 sain avec une rotation de clés maîtrisée, et un DMARC en place : c'est le socle sur lequel DKIM2 s'appuiera.

Précision qui revient souvent : DMARC ne disparaît pas. Il conserve une valeur propre, notamment les rapports agrégés au niveau du domaine et la détection de l'usurpation du domaine du From:, que DKIM2 ne réplique pas.

ESP, relais et listes de diffusion : le vrai chantier

Signer à chaque saut, tracer les modifications sous forme de recettes, et surtout anticiper un effet de bord sous-estimé : l'afflux de rebonds asynchrones entrants. DKIM2 renvoie le message au saut précédent, ce qui change le volume et la nature des retours à traiter, un point que Laura Atkins souligne particulièrement.

Autre point d'attention : la double signature (celle de la marque et celle de la plateforme), telle qu'elle se pratique aujourd'hui en DKIM, ne se transpose pas directement. Al Iverson estimait le 9 mai 2026 qu'il n'existe pas, à proprement parler, de signatures multiples directes.

Vérificateurs : commencer par le haut

La vérification est inversée par rapport à l'intuition : on part du i= le plus élevé, la signature la plus récente, puis on remonte la chaîne en appliquant les recettes pour reconstruire les instances précédentes.

Plan de préparation

1. Inventoriez vos flux : où signez-vous, où vérifiez-vous, quels sauts intermédiaires existent, quels mécanismes de réécriture d'enveloppe (SRS, VERP) sont en place.
2. Assainissez DKIM1 : sélecteurs à jour, clés d'une taille correcte, rotation documentée.
3. Prototypez côté relais si vous en opérez un : mf= et rt= en base64 chevrons compris, numérotation i=, horodatage epoch, choix des algorithmes.
4. Modélisez vos modifications courantes en recettes JSON : pied de page, préfixe de sujet, List-Unsubscribe. C'est l'exercice qui révèle les cas difficiles.
5. Dimensionnez le traitement des rebonds asynchrones entrants, le point le plus souvent oublié.
6. Ne touchez pas à votre DNS pour DKIM2 : il n'y a rien de nouveau à publier.
7. Mettez en place une veille sur draft-ietf-dkim-dkim2-spec et prévoyez des interrupteurs de fonctionnalité : quatre révisions en un peu plus de trois mois, la syntaxe bouge encore.

FAQ

DKIM2 est-il un standard en 2026 ?

Non. Au 25 juillet 2026, il n'existe aucune RFC DKIM2 : la spécification en est au stade draft-ietf-dkim-dkim2-spec-04, publiée le 5 juillet 2026, et aucun document du groupe n'est en dernier appel ni soumis à l'IESG. Les jalons de la charte visaient une soumission au 31 décembre 2025, soit un retard d'environ sept mois.

Dois-je modifier mes enregistrements DNS pour DKIM2 ?

Non. La spécification précise que les clés DKIM2 ne sont pas différentes et sont stockées aux mêmes emplacements que celles de DKIM1, sous sélecteur._domainkey.votredomaine. Aucun nouveau type d'enregistrement, aucune migration DNS à prévoir.

Quelle est la différence entre DKIM2-Signature et Message-Instance ?

DKIM2-Signature est ajouté par chaque saut SMTP : numéro de séquence i=, horodatage, domaine signataire, signature et enveloppe utilisée. Message-Instance décrit l'état du message et le moyen de revenir au précédent, via des recettes JSON encodées en base64 dans le tag r=. Un intermédiaire qui ne modifie rien ajoute une signature, mais pas de Message-Instance.

DKIM2 remplace-t-il DMARC ?

Non. DMARC conserve une valeur propre que DKIM2 ne réplique pas : rapports agrégés au niveau du domaine et détection de l'usurpation du domaine du From:. La spécification évite d'ailleurs délibérément de parler de DMARC et renvoie la question de l'alignement au document de bonnes pratiques.

Existe-t-il des implémentations de DKIM2 qui fonctionnent ?

Oui : trois implémentations ont démontré leur interopérabilité, et une quatrième a été annoncée depuis sans avoir participé à la démonstration. Le 4 juillet 2026, une démonstration d'interopérabilité a réuni mail-auth en Rust (Stalwart Labs), une implémentation Python de Bron Gondwana et une implémentation Go de Steve Atkins, y compris sur des chaînes multi-sauts. Une quatrième implémentation en C, PhoenixDKIM, a été mentionnée après coup, le 8 juillet 2026, quand la suite de tests a été centralisée dans l'organisation GitHub dkim2wg.

Que dois-je faire aujourd'hui si je gère simplement un domaine d'entreprise ?

Rien de spécifique à DKIM2 : vérifiez que votre DKIM actuel est correctement publié et signé, que votre DMARC est en place et surveillé, et que votre rotation de clés est documentée. Le travail réel de migration concerne les ESP, les relais et les listes de diffusion, pas les propriétaires de domaine.

📖 Glossaire

Replay DKIM

Réexpédition massive, ou vers d'autres cibles, d'un message déjà signé par un domaine légitime, sans altérer ce que couvre la signature : celle-ci reste valide, car DKIM signe le contenu, mais pas l'enveloppe SMTP ni la route. Le domaine signataire voit sa réputation se dégrader pour du courrier qu'il n'a pas envoyé, et aucune parade DKIM1 (débit par sélecteur, rotation de clés, durcissement DMARC) ne ferme la faille. En DKIM2, la signature inclut l'enveloppe du saut et chaîne le chemin par le numéro i=.

Backscatter

Rebonds indésirables (NDR, DSN) ou réponses automatiques envoyés à un tiers innocent dont l'adresse a été usurpée en MAIL FROM ou en Return-Path : sa boîte est inondée de rapports de non-remise. En DKIM1, on rejette pendant l'échange SMTP plutôt qu'après, avec SRS ou VERP pour tracer les rebonds ; en DKIM2, les retours remontent la chaîne signée jusqu'au saut précédent, donc vers un acteur réellement impliqué.

Message-Instance

En-tête DKIM2 décrivant l'état d'un message à un moment de son parcours : m= (numéro de révision) et h= (hash des en-têtes et du corps) obligatoires, r= (recettes) facultatif.

Recette

Description JSON, encodée en base64 dans le tag r= d'un Message-Instance, permettant de reconstruire l'instance précédente du message.

Sources

• draft-ietf-dkim-dkim2-spec, la spécification
• draft-ietf-dkim-dkim2-bcp, les bonnes pratiques
• draft-ietf-dkim-dkim2-dns, le volet DNS
• Documents du groupe de travail dkim de l'IETF
• Compte rendu de la session DKIM à l'IETF 125
• RFC 6376 : DomainKeys Identified Mail (DKIM) Signatures
• RFC 8463 : une nouvelle méthode de signature pour DKIM (Ed25519)
• Laura Atkins, « DKIM2: What it means for the future of email »
• Al Iverson, « What is DKIM2? »
• Al Iverson, « More on DKIM2: VERP, async bounces, signatures and hops »

DKIM2 reste un travail en cours. Cette page sera mise à jour au fil des révisions du brouillon de spécification.

Vérifiez votre DKIM actuel

C'est votre configuration DKIM (RFC 6376) actuelle qui sera réutilisée. Inspectez vos sélecteurs en direct avec le DKIM Record Checker et validez la syntaxe de chaque enregistrement publié avec le DKIM Syntax Validator.

Guides authentification email connexes

• ARC passe en statut « Historic » à l'IETF - Ce que la reclassification change vraiment, et ce qu'elle ne change pas
• DMARCbis : les nouveautés du futur standard - Les évolutions de DMARC avec DMARCbis
• Qu'est-ce que ARC (Authenticated Received Chain) ? - Comprendre la chaîne d'authentification ARC
• BIMI, VMC et CMC : compatibilité DNS - Guide complet sur BIMI et les certificats de marque
• Gmail Bulk Sender : les nouvelles exigences - Conformité aux règles d'envoi en masse de Gmail