Attaques par rejeu DKIM

Le problème du rejeu DKIM (draft-ietf-dkim-replay-problem) : comment un message légitimement signé est renvoyé à des millions de destinataires, pourquoi l= et x= ne règlent rien, les mesures de protection actuelles et leurs compromis, et ce que cela implique pour l’infrastructure d’un ESP.

Fondamental8 min de lecture

À qui cela s’adresse Opérateurs ESP, Expéditeurs

S’applique aux expéditeurs, quelle que soit leur plateforme

Le rejeu DKIM est une attaque contre l’infrastructure des expéditeurs, et non une attaque par falsification de message visant les destinataires. Un attaquant obtient un seul message légitimement signé DKIM par un domaine réputé et le retransmet, à l’identique, à des millions de nouveaux destinataires. Comme DKIM (RFC 6376) authentifie le contenu, et non le chemin de transport ni l’enveloppe, chaque copie porte toujours une signature valide : le domaine d= « se porte garant » d’un spam qu’il n’a jamais envoyé à ces destinataires, et c’est sa réputation que l’attaquant consume.

Le problème est décrit dans draft-ietf-dkim-replay-problem (Chuang/Google, Crocker, Robinson/Google, Gondwana/Fastmail). État au moment de cette synthèse (2026-07) : la dernière révision du draft (-00) est datée du 2023-07-28 et a expiré ; le groupe de travail DKIM de l’IETF est depuis passé de l’énoncé du problème au travail sur une solution (voir DKIM2). Le draft reste la formulation de référence de l’attaque.

Mécanique de l’attaque

L’attaquant crée ou compromet un compte chez un expéditeur de haute réputation (un fournisseur de messagerie gratuit, ou un essai gratuit chez un ESP) et obtient un message signé par le domaine d= visé. Le contenu du message est la charge utile de l’attaquant (spam ou phishing), ou un message anodin dans lequel la charge utile peut être glissée (voir l= plus bas).
L’attaquant récupère le message entièrement signé (il en est le destinataire, c’est donc trivial : il se l’envoie à lui-même).
L’attaquant réinjecte le message par sa propre infrastructure vers une nouvelle liste de destinataires aussi longue qu’il le souhaite. L’enveloppe RFC 5321 (MAIL FROM, RCPT TO) n’est pas signée et peut donc être librement réécrite ; les en-têtes RFC 5322 et le corps sont intacts, si bien que bh= et b= sont toujours vérifiés.
Les serveurs de réception voient une signature DKIM valide, un d= aligné appartenant à un domaine de confiance, et un pass DMARC. Les systèmes de réputation attribuent le volume de courrier, puis les plaintes et les classements en spam qui suivent, au domaine signataire.

Rien dans la RFC 6376 n’est enfreint. La RFC note d’ailleurs explicitement que le renvoi d’un message signé est impossible à distinguer d’un transfert légitime, et c’est précisément cette propriété qui permet à DKIM de survivre au transfert là où SPF casse. La difficulté centrale, selon le draft : les serveurs de réception ne peuvent pas distinguer les flux de transfert légitimes (transfert d’alias, listes de diffusion, « envoyer à un ami ») d’une attaque par rejeu. Toute correction naïve qui supprime le rejeu supprime aussi le transfert.

Pourquoi les balises DKIM existantes ne règlent rien

Balise	Pourquoi elle échoue
`l=` (longueur du corps)	Sans rapport au mieux, franchement nuisible au pire : elle limite les octets du corps qui sont signés mais ne lie en rien les destinataires. Pire, `l=` permet à l’attaquant d’ajouter un contenu malveillant non signé qui s’affiche après la partie signée, tandis que la signature reste valide (exploité en conditions réelles en 2024). Ne signez jamais avec `l=`.
`x=` (expiration)	Limite dans le temps la validité de la signature, mais ne peut pas distinguer un délai de transfert légitime de 2 heures d’une campagne de rejeu de 2 heures. Les campagnes de rejeu écoulent leur volume dans les minutes qui suivent l’obtention du message signé, bien à l’intérieur de toute fenêtre `x=` assez généreuse pour absorber les délais de livraison réels (nouvelles tentatives, liste grise, digests de listes de diffusion). La RFC 6376 elle-même indique que `x=` n’est pas une défense contre le rejeu.
`t=` (horodatage)	Purement informatif ; même problème de fenêtre que `x=`.
Signer `To:`	L’en-tête `To:` est généralement signé, mais le rejeu ne le modifie pas. Le spam est livré aux destinataires du `RCPT TO`, qui n’apparaissent pas dans le `To:` signé. Un écart entre le `To:` signé et le destinataire réel est par ailleurs normal (Cci, alias, transfert, listes de diffusion), si bien que les serveurs de réception ne peuvent pas en faire un motif d’échec strict.

Mesures de protection actuelles et compromis

Aucune solution complète n’existe dans DKIM tel qu’il est spécifié ; les mesures ci-dessous réduisent l’exposition et l’étendue des dégâts. (La correction au niveau du protocole est le chantier DKIM2, qui lie les signatures à l’enveloppe SMTP à chaque saut.)

Côté expéditeur et ESP

Mesure	Mécanisme	Compromis
Sursignature	Lister `To:`, `Subject:`, `From:`, `Reply-To:`, `Cc:` dans `h=` une fois de plus qu’ils n’apparaissent, pour qu’un attaquant ne puisse pas ajouter une autre instance (par exemple un second Subject que certains MUA affichent) sans casser la signature.	Peu coûteuse, à appliquer systématiquement. Ne bloque que les variantes par ajout d’en-têtes ; le rejeu à l’identique n’est pas affecté.
Expiration `x=` courte	Signer avec un `x=` fixé quelques heures après `t=`. Réduit la fenêtre de rejeu ; les copies rejouées tardivement échouent.	La livraison légitimement retardée (nouvelles tentatives après un 4xx du serveur de réception, liste grise) échoue aussi à la vérification ; de nombreux vérificateurs ignorent complètement `x=` ; les attaquants rejouent vite.
Sélecteurs par flux ou par client et isolation du `d=`	Signer chaque client ou flux de messagerie avec son propre sélecteur ou sous-domaine, pour qu’un incident de rejeu ne consume que l’identifiant d’un client, et non le domaine partagé de la plateforme.	N’empêche pas le rejeu ; limite l’étendue des dégâts de réputation et rend le client abusif identifiable et révocable (publier un `p=` vide pour neutraliser le sélecteur). Charge de gestion des clés à l’échelle d’un ESP.
Signature par destinataire	Calculer une signature distincte pour chaque RCPT TO (destinataire lié au contenu signé, par exemple via un en-tête signé propre à chaque destinataire).	L’option la plus forte dans le protocole, mais : une opération de signature et un ensemble distinct de corps et d’en-têtes par destinataire (fin de l’efficacité des livraisons à plusieurs RCPT) ; casse le transfert légitime vers une autre adresse ; aucune norme ne dit comment les vérificateurs doivent contrôler ce lien.
Contrôle du contenu et des destinataires avant la première signature	L’attaque exige d’obtenir une charge utile signée : les contrôles d’abus sur les comptes d’essai, l’analyse du contenu sortant et la vérification de la réputation des URL au moment de la signature sont donc des protections contre le rejeu DKIM.	Course sans fin ; les charges utiles d’apparence anodine (l’astuce `l=`, le contenu distant) échappent à l’analyse.
Surveillance des anomalies de volume	Surveiller dans Google Postmaster Tools et les données de feedback loop les pics de taux de spam et de volume sur un `d=` ou un sélecteur qui ne correspondent pas à vos propres journaux d’envoi : c’est la signature d’un rejeu en cours.	Détection, pas prévention ; la réponse consiste à révoquer le sélecteur et à escalader auprès du fournisseur.

Côté serveur de réception (ce que discute le draft)

Comptage et observation des débits : la même signature (ou le même bh=) vue soudainement sur un ensemble de destinataires anormalement grand et sans lien entre eux est une empreinte de rejeu. Cela exige une visibilité à grande échelle (ce qui avantage les grands fournisseurs de messagerie) et une coordination entre systèmes.
Signaux d’écart entre enveloppe et en-têtes : le courrier rejoué présente généralement des domaines MAIL FROM/RCPT TO sans rapport avec le domaine signataire et avec le To: signé. Utilisable comme signal de score, pas comme règle stricte (le transfert produit la même forme).
Il est conseillé aux serveurs de réception de traiter une signature DKIM valide comme un identifiant auquel rattacher une réputation, et non comme un jeton de liste blanche : le rejeu consiste justement à exploiter les raccourcis du type « signature égale confiance ».

Conséquences pour les ESP

Les ESP sont une cible de choix pour la collecte de messages signés : les essais gratuits offrent aux attaquants un oracle de signature pour un domaine à la réputation déjà établie. Un seul message signé depuis un compte d’essai peut être rejoué à un volume supérieur à la totalité des envois légitimes quotidiens de l’ESP.
Les dégâts retombent sur le d= qui signe le message. Avec une signature sur domaine partagé (tous les clients sous le domaine de l’ESP), un seul incident dégrade la livraison de tous les clients : c’est l’argument d’architecture le plus fort en faveur de d= et de sélecteurs propres à chaque client (voir les meilleures pratiques M3AAWG pour les domaines d’envoi).
Réponse à incident : identifier le message rejoué (échantillons de feedback loop, pic de taux de spam dans Postmaster Tools), révoquer le sélecteur (p= vide), suspendre le compte d’origine et passer à un nouveau sélecteur pour le flux légitime. Gardez des clés distinctes par flux pour les anciens sélecteurs, afin que la révocation soit chirurgicale.
Ne répondez pas à un incident de rejeu en ajoutant l= ou en retirant To: de h= : les deux aggravent la situation.

Voir aussi

DKIM : protocole de base, détails sur la sursignature et l=
DKIM2 : la refonte du protocole en cours, dont la liaison à l’enveloppe est la véritable correction
Surveillance de la réputation : détecter le pic

Vérifier votre propre enregistrement

Le diagnostic gratuit lit ce que votre domaine publie dans le DNS.

Dans ce thème

Les 13 articles du thème Authentification →