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

Si votre domaine signe ses emails avec DKIM, un attaquant qui met la main sur un seul message que vous avez signé peut le renvoyer, sans le modifier, à des millions de nouveaux destinataires, et chaque copie porte toujours votre signature valide. Le rejeu DKIM est une attaque contre l’infrastructure des expéditeurs, et non une attaque qui falsifie des messages à l’encontre des destinataires.

DKIM (RFC 6376) authentifie le contenu d’un message, et non son chemin de transport ni son enveloppe. Le domaine d= se retrouve donc à « se porter garant » d’un spam qu’il n’a jamais envoyé à ces destinataires, et c’est sa réputation que l’attaquant dépense.

Le problème est décrit dans draft-ietf-dkim-replay-problem (Chuang/Google, Crocker, Robinson/Google, Gondwana/Fastmail). État en 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 la description du problème au travail sur une solution, DKIM2. Le draft reste la description 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, comme un fournisseur de messagerie gratuit ou un essai gratuit chez un ESP, et obtient un message signé par le domaine d= visé. Le contenu est la charge utile de l’attaquant (spam ou phishing), ou un message anodin dans lequel la charge utile pourra être insérée plus tard (voir l= plus bas).
L’attaquant récupère le message entièrement signé. C’est trivial, car l’attaquant en est le destinataire : il se l’envoie à lui-même.
L’attaquant réinjecte le message, par sa propre infrastructure, vers une nouvelle liste de destinataires de n’importe quelle taille. L’enveloppe RFC 5321 (MAIL FROM, RCPT TO) n’est pas signée, donc elle peut ê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 une réussite 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 de cela n’enfreint la RFC 6376. La RFC note d’ailleurs que le renvoi d’un message signé ne peut pas être distingué d’un transfert légitime. 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, est que les serveurs de réception ne peuvent pas distinguer le transfert légitime (transfert d’alias, listes de diffusion, « envoyer à un ami ») d’une attaque par rejeu. Toute correction simple qui arrête le rejeu arrête aussi le transfert.

Pourquoi les balises DKIM existantes ne règlent rien

Balise	Pourquoi elle échoue
`l=` (longueur du corps)	Sans intérêt au mieux, 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)	Elle limite la durée de 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 envoient leur volume dans les minutes qui suivent l’obtention du message signé, bien à l’intérieur de toute fenêtre `x=` assez longue pour les délais de livraison réels (nouvelles tentatives en file d’attente, 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, avec le 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), donc les serveurs de réception ne peuvent pas faire échouer les messages sur cette base.

Mesures de protection actuelles et compromis

DKIM tel qu’il est spécifié n’a pas de correction complète. Les mesures ci-dessous réduisent l’exposition et limitent les 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:` et `Cc:` dans `h=` une fois de plus qu’ils n’apparaissent. Un attaquant ne peut alors pas ajouter une autre instance (par exemple, un second Subject que certains clients de messagerie affichent) sans casser la signature.	Peu coûteuse, donc à appliquer systématiquement. Elle ne bloque que les variantes qui ajoutent des en-têtes. Le rejeu pur du message inchangé n’est pas affecté.
Expiration `x=` courte	Signer avec un `x=` fixé quelques heures après `t=`. Cela réduit la fenêtre de rejeu, et les anciennes copies rejouées é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=`, et les attaquants rejouent vite.
Sélecteurs et domaines `d=` distincts pour chaque flux ou client	Signer chaque client ou flux de messagerie avec son propre sélecteur ou sous-domaine, pour qu’un incident de rejeu n’endommage que l’identifiant d’un client, et non le domaine partagé de la plateforme.	N’empêche pas le rejeu. Limite les dégâts de réputation, et rend le client abusif identifiable et son sélecteur révocable (publiez un `p=` vide pour désactiver le sélecteur). La gestion des clés ajoute du travail à l’échelle d’un ESP.
Signature par destinataire	Calculer une signature distincte pour chaque RCPT TO, en liant le destinataire au contenu signé (par exemple, par un en-tête signé propre à chaque destinataire).	L’option la plus forte dans le protocole, mais elle exige une opération de signature et un ensemble distinct de corps et d’en-têtes pour chaque destinataire, ce qui supprime l’efficacité de la livraison à plusieurs destinataires à la fois. Elle casse le transfert légitime vers une autre adresse, et 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 une charge utile signée, donc 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 servent tous de protections contre le rejeu DKIM.	Une course sans fin. Les charges utiles d’apparence anodine (l’astuce `l=`, le contenu distant) échappent à l’analyse.
Surveillance des anomalies de volume	Surveiller les données de Google Postmaster Tools et des feedback loops (FBL) pour repérer des pics de taux de spam et de volume sur un domaine `d=` ou un sélecteur qui ne correspondent pas à vos propres journaux d’envoi. Cet écart est le signe d’un rejeu en cours.	Détecte, mais n’empêche pas. La réponse consiste à révoquer le sélecteur et à escalader auprès des fournisseurs.

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 anormalement grand de destinataires sans lien entre eux est l’empreinte d’un rejeu. Cela exige une visibilité à grande échelle, ce qui avantage les grands fournisseurs de messagerie, et une coordination entre systèmes.
Écarts entre enveloppe et en-têtes : le courrier rejoué présente généralement des domaines MAIL FROM et RCPT TO sans rapport avec le domaine signataire et avec le To: signé. Cela peut servir de signal de score, mais pas de règle stricte, car le transfert produit le même schéma.
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 une réussite qui garantit la confiance. Le rejeu exploite exactement le raccourci qui consiste à prendre une signature valide pour une preuve de confiance.

Conséquences pour les ESP

Les ESP sont une cible de choix pour obtenir des messages signés. Un essai gratuit donne aux attaquants un moyen de faire signer des messages par 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 domaine d= qui signe le message. Si tous les clients signent avec le domaine partagé 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 d’un domaine d= et de sélecteurs propres à chaque client (voir les meilleures pratiques M3AAWG pour les domaines d’envoi).
Réponse à incident : identifiez le message rejoué (à partir d’échantillons de FBL, ou d’un pic de taux de spam dans Postmaster Tools), révoquez le sélecteur (p= vide), suspendez le compte d’origine et passez le flux légitime sur un nouveau sélecteur. Gardez des clés distinctes par flux pour les anciens sélecteurs, afin de pouvoir révoquer avec précision.
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, notamment 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, pour 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 →