Le rejeu DKIM : quand une signature valide sert au spam

Les en-têtes non signés, un angle d'attaque

Le rejeu de base réexpédie le message à l'identique. Une variante plus fine exploite ce que la signature ne couvre pas. La balise h= liste précisément les en-têtes signés ; tout en-tête absent de cette liste échappe à la protection et peut donc être ajouté ou modifié sans invalider la signature.

Les conséquences sont concrètes. Si Subject ne figure pas dans le h=, l'objet du message se réécrit à volonté pour coller à chaque campagne, sans toucher à l'empreinte. Si To n'est pas signé, le destinataire affiché se maquille. Plus retors encore : l'injection d'un doublon d'en-tête. Beaucoup de logiciels de messagerie affichent la première — ou la dernière — occurrence d'un en-tête ; si le signataire n'en a signé qu'une seule, l'ajout d'un second Subject ou d'un second From passe sous le radar de la vérification tout en changeant ce que l'humain voit à l'écran. Le message rejoué se personnalise ainsi pour chaque victime, alors que la signature d'origine, elle, reste techniquement intacte : elle ne portait que sur ce que le signataire avait bien voulu inclure.

Les parades, surtout côté signataire

La difficulté tient à un déséquilibre : le destinataire ne voit qu'une signature valide, il ne dispose de presque aucun levier. Les vraies parades vivent chez celui qui signe — grand expéditeur, ESP, fournisseur de messagerie.

• Signer large. La première défense consiste à inclure dans h= tous les en-têtes qui portent du sens : From, To, Cc, Subject, Date, Message-ID, Reply-To, Content-Type… Plus la couverture est étendue, moins il reste de surface non signée à manipuler. Un h=from réduit au strict minimum laisse tout le reste ouvert au maquillage.
• L'en-tête surdéclaré (oversigning). La technique consiste à signer un en-tête plus de fois qu'il n'apparaît réellement dans le message — par exemple en déclarant h=from:from:to:to:subject:subject:…. L'ajout d'une occurrence supplémentaire de l'un de ces en-têtes rompt alors le compte attendu, et la vérification échoue. C'est la parade directe contre l'injection de doublons : elle interdit d'ajouter un second Subject ou un second From sans casser la signature.
• Des clés à courte durée de vie et une rotation régulière. Un message rejoué ne reste vérifiable que tant que la clé publique associée est publiée. Faire tourner les clés et retirer les anciens sélecteurs raccourcit la fenêtre pendant laquelle une signature capturée demeure valide — c'est un des bénéfices de la rotation des clés. La limite est nette : la rotation ne bloque pas un rejeu immédiat, car l'essentiel du dommage se produit dans les heures qui suivent la capture, bien avant toute rotation raisonnable.
• La balise x=, avec ses limites. DKIM permet de dater la péremption d'une signature via la balise x= (un horodatage). Passé ce délai, un vérificateur peut rejeter la signature. En théorie, une fenêtre courte réduit le temps utile au rejeu. En pratique, trois réserves : tous les vérificateurs n'appliquent pas x= ; une fenêtre trop serrée fait échouer le courrier légitime retardé (files d'attente, transferts, temporisation greylisting) ; et quelques minutes suffisent souvent à lancer une diffusion de masse. La balise réduit le risque, elle ne le supprime pas.
• Surveiller les pics anormaux. Côté domaine signataire, un rejeu laisse la trace décrite plus haut : une bouffée de messages « DKIM seul » depuis des adresses étrangères au parc d'envoi habituel. Un domaine légitime émet depuis un jeu d'IP stable ; un pic qui s'en écarte signale un rejeu en cours, et la lecture régulière des rapports est le seul moyen de le détecter tôt.

Un point mérite d'être posé clairement, car il prête à confusion : allonger la clé de 1024 à 2048 bits protège contre la falsification d'une signature, pas contre le rejeu. Ici, la clé n'est jamais cassée — une signature authentique est simplement réutilisée. Confondre les deux menaces conduit à renforcer la mauvaise serrure.

Ce que DMARCbis change (et ne change pas)

DMARCbis, le standard courant décrit par les RFC 9989, 9990 et 9991, modernise plusieurs mécanismes : la Public Suffix List cède la place au parcours de l'arbre DNS (DNS Tree Walk), la balise pct disparaît au profit d'un mode test porté par t=, et de nouvelles balises comme np ou psd affinent le traitement des sous-domaines. Aucune de ces évolutions ne touche au rejeu.

La raison est structurelle : DMARCbis raisonne toujours au niveau de l'alignement, et il continue de rendre pass sur une signature DKIM valide et alignée. Le rejeu opère une couche en dessous, au niveau de DKIM lui-même, où DMARCbis n'ajoute ni compteur ni notion de destinataire unique. Migrer vers le standard courant reste une bonne chose pour d'autres raisons, mais cela ne referme pas cette porte. La communauté IETF travaille de son côté sur des extensions destinées à rendre DKIM résistant au rejeu — lier une signature à un envoi, à un volume ou à une trajectoire —, mais ces travaux ne constituent pas encore un standard déployé à grande échelle en 2026. En l'état, la défense reste organisationnelle, pas protocolaire.

Qui est réellement concerné

Le rejeu vise avant tout les identités qui valent la peine d'être empruntées. Les grands expéditeurs, les plateformes d'emailing et les fournisseurs de messagerie qui offrent des comptes gratuits ou d'essai concentrent le problème : leur bonne réputation est l'actif convoité, et le compte d'essai est le vecteur de capture. Pour eux, l'enjeu est opérationnel et permanent — leur nom sert de véhicule au spam, et leur délivrabilité en pâtit. C'est là que se justifient la signature large, l'oversigning, la détection d'abus des comptes d'essai et la limitation de débit.

Le domaine d'une PME se situe dans une autre position. Sa réputation n'a en général pas assez de valeur pour faire de lui une cible de rejeu : un attaquant ne gagne rien à diffuser sous le nom d'un petit domaine inconnu. La PME est donc rarement la source d'un rejeu. Elle peut en revanche en être destinataire, et là, aucun réglage DMARC ne filtrera un message qui passe légitimement toutes les vérifications — seul le filtrage anti-spam classique reste en jeu. La leçon utile pour un petit domaine est plus large : signer proprement et surdéclarer les en-têtes clés reste une hygiène peu coûteuse, et surtout, une signature valide authentifie un domaine, jamais une intention. C'est le même socle qui sert à se prémunir de l'usurpation : l'authentification prouve l'origine, pas la bienveillance. Pour vérifier concrètement ce qu'une signature couvre et ce qu'elle laisse ouvert, lire une signature dans les en-têtes dans un message reçu est l'exercice de base.

En résumé

Le rejeu DKIM exploite une propriété voulue du protocole : une signature valide le reste tant que le corps et les en-têtes signés ne changent pas, sans lien avec l'envoi d'origine ni la liste des destinataires. Un message signé une fois par un domaine réputé — souvent via un compte d'essai — se rediffuse en masse et passe les filtres grâce à une réputation empruntée. DMARC n'y voit rien, car tout est techniquement correct ; les en-têtes non signés ajoutent un angle de maquillage. Les parades vivent côté signataire : h= large, oversigning, rotation des clés, balise x= aux effets partiels, surveillance des pics. DMARCbis ne referme pas cette porte, et le risque pèse surtout sur les grands expéditeurs, bien plus que sur le domaine d'une PME.

Un premier diagnostic ne coûte rien : l'analyse DMARC gratuite révèle l'état des signatures d'un domaine, la stabilité de ses sources d'envoi et les alignements en place. Pour suivre dans la durée la couverture des en-têtes signés et l'apparition de pics anormaux dans les rapports — le signal discret d'un rejeu —, créer un compte ouvre le suivi continu que cette menace, silencieuse par nature, rend nécessaire.