En 2016, des hackers ont compromis le système de messagerie d'une grande campagne politique. Mais la partie la plus dommageable n'était pas la brèche elle-même — c'est ce qui a suivi. Les attaquants ont modifié certains des e-mails volés avant de les publier, en ajoutant du contenu fabriqué à de vrais fils de discussion. Sans signatures cryptographiques, il était impossible de prouver quels e-mails étaient authentiques et lesquels avaient été altérés.
C'est le problème que DKIM résout. Non seulement prouver qu'un e-mail provient bien de l'expéditeur qu'il prétend être, mais aussi prouver qu'il n'a pas été modifié depuis son envoi.
DKIM — DomainKeys Identified Mail — ajoute une signature cryptographique à chaque e-mail que vous envoyez. Cette signature est liée mathématiquement au contenu de l'e-mail. Modifiez un seul caractère, et la signature devient invalide. C'est l'équivalent numérique d'un sceau témoin d'effraction.
La cryptographie derrière DKIM
DKIM utilise la cryptographie à clé publique, la même technologie qui sécurise les connexions HTTPS et les portefeuilles de cryptomonnaies. Si vous n'êtes pas familier avec son fonctionnement, voici l'idée essentielle.
Vous générez deux clés liées mathématiquement : une clé privée et une clé publique. Tout ce qui est chiffré avec la clé privée ne peut être déchiffré qu'avec la clé publique, et inversement. La clé privée reste secrète ; la clé publique est partagée avec le monde entier.
Lorsque vous envoyez un e-mail, votre serveur de messagerie prend certaines parties du message — généralement l'adresse From, Subject, Date et le corps — et crée un hachage (une empreinte de longueur fixe) de ce contenu. Il chiffre ensuite ce hachage en utilisant votre clé privée. Le hachage chiffré est votre signature DKIM.
La signature est ajoutée à l'e-mail sous forme d'en-tête. Quand l'e-mail arrive à destination, le serveur destinataire récupère votre clé publique depuis le DNS, déchiffre la signature pour obtenir le hachage original, puis crée son propre hachage du contenu de l'e-mail. Si les deux hachages correspondent, l'e-mail est authentique et non modifié. S'ils ne correspondent pas, quelque chose a changé.
La beauté de ce système est que seule une personne disposant de votre clé privée peut créer une signature valide. Et puisque la signature est liée au contenu de l'e-mail, toute modification — même l'ajout d'un espace — l'invalide.
Ce que DKIM signe réellement
Toutes les parties d'un e-mail ne sont pas signées. DKIM vous permet de spécifier quels en-têtes inclure dans la signature, et ce choix compte plus que vous ne le pensez.
L'en-tête 'From' est toujours signé — c'est tout l'objectif, prouver qui a envoyé l'e-mail. La plupart des implémentations signent aussi 'To', 'Subject', 'Date' et 'Message-ID'. Le corps de l'e-mail est signé séparément (son hachage figure dans le champ 'bh' de la signature).
Les en-têtes susceptibles de changer légitimement pendant le transit — comme les en-têtes 'Received' qui sont ajoutés par chaque serveur traversé par l'e-mail — ne sont généralement pas signés. S'ils l'étaient, la signature se briserait à chaque relais de l'e-mail.
Cette signature sélective est à la fois une fonctionnalité et une limitation. Elle permet aux e-mails de passer par plusieurs serveurs sans casser DKIM, mais elle signifie aussi que les en-têtes non signés peuvent être modifiés sans détection. Un attaquant sophistiqué pourrait potentiellement ajouter des en-têtes trompeurs à un e-mail légitimement signé.
Sélecteurs et rotation des clés
Lorsque vous cherchez une clé publique DKIM dans le DNS, vous n'interrogez pas seulement le domaine — vous interrogez un 'sélecteur' spécifique au sein de ce domaine. Ce détail en apparence mineur permet des capacités importantes.
Un sélecteur est simplement un nom qui identifie quelle clé utiliser. Votre signature DKIM inclut un champ 's=' qui spécifie le sélecteur, et le serveur destinataire consulte [selector]._domainkey.[yourdomain] pour trouver la clé publique.
Pourquoi est-ce important ? Parce que cela vous permet d'avoir plusieurs clés actives simultanément. Vous pouvez utiliser différents sélecteurs pour différents services d'e-mail — un pour votre plateforme marketing, un autre pour vos e-mails transactionnels. Chaque service a sa propre clé privée, et si l'une est compromise, vous pouvez la révoquer sans affecter les autres.
Les sélecteurs permettent aussi la rotation des clés. Les bonnes pratiques de sécurité recommandent de générer périodiquement de nouvelles clés, mais vous ne pouvez pas simplement les remplacer instantanément — les e-mails en transit signés avec l'ancienne clé échoueraient à la vérification. Avec les sélecteurs, vous pouvez publier une nouvelle clé sous un nouveau sélecteur, commencer à signer les nouveaux e-mails avec celle-ci, et garder l'ancienne clé active jusqu'à ce que tous les e-mails en transit soient livrés. Ensuite, vous retirez l'ancienne clé.
La plupart des services d'e-mail gèrent cela automatiquement, mais si vous administrez votre propre infrastructure de messagerie, la rotation des clés est un sujet à planifier.
La relation de DKIM avec SPF et DMARC
DKIM n'existe pas isolément. C'est une pièce d'un système d'authentification des e-mails en trois volets, et comprendre comment les pièces s'emboîtent est crucial.
SPF vérifie que le serveur d'envoi est autorisé à envoyer pour le domaine. DKIM vérifie que le contenu de l'e-mail est authentique et non modifié. Mais ni l'un ni l'autre, seuls, ne lient l'authentification à l'adresse 'From' que les destinataires voient réellement.
C'est là qu'intervient DMARC. DMARC exige que SPF ou DKIM (ou les deux) réussissent ET que le domaine authentifié soit aligné avec le domaine 'From' visible. Sans DMARC, un attaquant pourrait envoyer un e-mail qui passe SPF pour son propre domaine tout en affichant votre domaine dans l'en-tête 'From'.
DKIM a un avantage significatif sur SPF : il survit au transfert. Lorsque quelqu'un transfère votre e-mail, l'adresse IP du serveur de transfert ne figurera pas dans votre enregistrement SPF, donc SPF échoue. Mais la signature DKIM voyage avec le contenu de l'e-mail, donc elle reste valide même après transfert. C'est pourquoi avoir à la fois SPF et DKIM est important — ils couvrent les faiblesses l'un de l'autre.
Quand DKIM échoue
Les échecs DKIM se produisent, et ils ne sont pas toujours dus à des attaquants. Comprendre les causes courantes vous aide à résoudre les problèmes de délivrabilité.
La cause la plus fréquente est la modification du contenu par des serveurs intermédiaires. Certains passerelles de sécurité des e-mails ajoutent des pieds de page aux e-mails sortants, ou modifient les liens à des fins de suivi. Si ces modifications interviennent après la signature DKIM, la signature devient invalide. La solution consiste à s'assurer que la signature DKIM se fait en dernier, après toutes les modifications de contenu.
Les listes de diffusion sont un autre coupable fréquent. Beaucoup modifient la ligne Subject (en ajoutant des préfixes '[listname]') ou ajoutent des pieds de page. Comme Subject est généralement signé, ces modifications cassent DKIM. Certains logiciels modernes de listes de diffusion resignent les e-mails avec la clé DKIM de la liste, mais beaucoup ne le font pas.
Les incohérences de clé provoquent aussi des échecs. Si vous faites tourner votre clé DKIM mais n'actualisez pas le DNS, ou s'il y a une faute de frappe dans l'enregistrement DNS, la vérification échouera. Testez toujours après avoir apporté des changements.
Enfin, un décalage d'horloge peut poser problème. Les signatures DKIM incluent un horodatage, et certaines implémentations rejettent les signatures trop anciennes ou datées du futur. Si l'horloge de votre serveur de messagerie est significativement incorrecte, les signatures peuvent échouer à la vérification.
Bien configurer DKIM
Si vous utilisez un service de messagerie géré comme Google Workspace, Amazon SES, ou une API d'e-mail dédiée, la configuration de DKIM est généralement simple — ils génèrent les clés et vous indiquent quel enregistrement DNS ajouter. Mais il reste des décisions à prendre et des pièges à éviter.
La longueur de la clé compte. Le minimum est 1024 bits, mais 2048 bits est désormais la recommandation standard. Certains systèmes plus anciens ne gèrent pas les clés de 2048 bits dans le DNS (il existe des contournements impliquant de scinder la clé en plusieurs chaînes), mais cela devient de plus en plus rare. N'utilisez pas de clés 1024 bits pour de nouvelles configurations.
Testez minutieusement avant de compter sur DKIM. Envoyez des e-mails de test à Gmail, Outlook et Yahoo, puis vérifiez les en-têtes pour confirmer que DKIM passe. Cherchez 'dkim=pass' dans l'en-tête Authentication-Results. Si vous voyez 'dkim=fail' ou aucun résultat DKIM, quelque chose ne va pas.
Surveillez vos rapports DMARC. Ils vous montreront les taux de succès/échec DKIM sur l'ensemble de vos e-mails. Une augmentation soudaine des échecs peut indiquer un problème de configuration, une clé compromise, ou quelqu'un qui tente d'usurper votre domaine.
Planifiez la rotation des clés dès le départ. Même si vous ne faites pas tourner les clés aujourd'hui, configurez votre infrastructure pour pouvoir le faire. Utilisez des noms de sélecteur explicites qui incluent des dates ou des numéros de version, afin qu'il soit clair quelle clé est actuelle.
Frequently asked questions
DKIM chiffre-t-il mes e-mails ?
Non. DKIM signe les e-mails, il ne les chiffre pas. La signature prouve l'authenticité et l'intégrité, mais le contenu de l'e-mail reste lisible par quiconque l'intercepte. Pour le chiffrement, vous avez besoin de S/MIME ou de PGP, ou vous vous appuyez sur TLS pour le chiffrement du transport.
Puis-je utiliser la même clé DKIM pour plusieurs domaines ?
Techniquement oui, mais ce n'est pas recommandé. Si la clé est compromise, tous les domaines sont affectés. Chaque domaine devrait avoir sa propre paire de clés. La plupart des services de messagerie gèrent cela automatiquement.
Pourquoi certains de mes e-mails passent DKIM et d'autres échouent ?
Cela signifie généralement que quelque chose modifie certains e-mails après la signature. Vérifiez si vous avez des outils de sécurité des e-mails, des répondeurs automatiques ou des règles de transfert qui pourraient altérer le contenu. Vérifiez aussi que toutes vos sources d'envoi sont correctement configurées pour DKIM.
À quelle fréquence dois-je faire la rotation des clés DKIM ?
Il n'existe pas de norme universelle, mais une rotation annuelle constitue une base raisonnable. Une rotation plus fréquente (trimestrielle) est préférable si vous pouvez l'automatiser. L'important est d'avoir un processus de rotation en place, pas une fréquence spécifique.