Qu'est-ce que DKIM, et comment prouve-t-il qu'un email n'a pas été falsifié ?

Quand tu reçois un email, rien dans le protocole d'origine ne te garantit qu'il vient bien de qui il prétend, ni qu'il n'a pas été bricolé en chemin. DKIM referme une partie de cette faille en attachant à chaque message une signature cryptographique vérifiable. Le serveur d'envoi signe le message avec une clé privée ; le destinataire récupère la clé publique dans ton DNS et vérifie que rien n'a bougé. Ce guide t'explique ce qu'est DKIM, comment fonctionne la signature, comment publier ton enregistrement, comment gérer sélecteurs et rotation — et pourquoi DKIM seul ne suffit pas sans DMARC.

Ce qu'est vraiment DKIM

DKIM (DomainKeys Identified Mail), défini par la RFC 6376, est un mécanisme d'authentification qui prouve deux choses à la fois : que le message a bien été autorisé par le domaine signataire, et qu'il n'a pas été altéré entre l'envoi et la réception. Il repose sur la cryptographie asymétrique, exactement comme HTTPS : une paire de clés, une privée que tu gardes secrète sur ton infrastructure d'envoi, et une publique que tu publies ouvertement dans le DNS.

À l'envoi, ton serveur calcule une signature à partir de certains en-têtes du message (typiquement From, Subject, Date…) et du corps, en utilisant la clé privée. Cette signature voyage avec le message, dans un en-tête dédié. À la réception, le serveur destinataire va chercher la clé publique correspondante dans ton DNS et recalcule la signature. Si le résultat correspond, deux certitudes : le message vient bien d'une source qui détient ta clé privée, et il est intègre — pas un octet du contenu signé n'a été modifié en route.

C'est une différence fondamentale avec SPF, qui se contente de vérifier quelle IP a émis le message. SPF ne regarde pas le contenu ; DKIM, lui, scelle le message. Les deux sont complémentaires, et tu as besoin des deux.

Comment fonctionne la signature, étape par étape

Le mécanisme tient en trois temps. Une fois que tu le visualises, tout le reste devient limpide.

1. À l'envoi — le serveur signe. Ton serveur d'envoi (ou ta plateforme : Google Workspace, Microsoft 365, ton routeur marketing…) prend le message, sélectionne une liste d'en-têtes à protéger et le corps, puis calcule une signature cryptographique avec la clé privée. Il insère alors un en-tête DKIM-Signature dans le message. Cet en-tête contient trois informations décisives : le domaine signataire (d=), le sélecteur (s=) et la signature elle-même (b=), plus la liste des en-têtes couverts (h=).

2. À la réception — le serveur récupère la clé publique. Le destinataire lit l'en-tête DKIM-Signature, y trouve d=ton-domaine.fr et s=s1, et en déduit exactement où chercher la clé publique : à l'adresse DNS s1._domainkey.ton-domaine.fr. Il fait une simple requête DNS de type TXT et récupère la clé.

3. Vérification — le destinataire recalcule. Avec la clé publique, le serveur destinataire recalcule la signature sur les mêmes en-têtes et le même corps. Si elle correspond, le message est déclaré intègre et authentifié pour le domaine signataire. Sinon, DKIM échoue : soit le message a été modifié, soit la clé ne correspond pas, soit la signature était absente.

Tout ce ballet est automatique et invisible pour l'humain qui lit son courrier. Il se joue en quelques millisecondes, en tâche de fond, à chaque email.

À quoi ressemble ton enregistrement DKIM

La clé publique se publie dans le DNS sous un nom très précis : <sélecteur>._domainkey.ton-domaine.fr. Voici un exemple concret d'enregistrement TXT :

s1._domainkey.ton-domaine.fr.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

Décortiquons les balises qui comptent :

• s= (le sélecteur) — ce n'est pas une balise dans l'enregistrement, mais le préfixe du nom DNS. Le sélecteur te permet de publier plusieurs clés en parallèle : une par prestataire d'envoi, ou une ancienne et une nouvelle pendant une rotation. C'est le pivot de toute la gestion DKIM. On l'explore en détail dans le rôle du sélecteur DKIM.
• p= (la clé publique) — la clé publique encodée en base64. C'est le cœur de l'enregistrement. Détail crucial : supprimer p= ou vider sa valeur révoque le sélecteur — les destinataires considèrent alors la clé comme retirée. C'est le mécanisme propre pour désactiver une clé compromise.
• k= (l'algorithme) — l'algorithme de clé, rsa étant de loin le plus courant. Certaines infrastructures modernes acceptent aussi ed25519, plus compact, souvent publié en second sélecteur à côté du RSA.
• v=DKIM1 — la version, présente au début de chaque enregistrement.

Un point qui piège les débutants : la clé publique est souvent trop longue pour tenir dans une seule chaîne DNS de 255 caractères. Elle est alors découpée en plusieurs chaînes entre guillemets, que le résolveur recolle. Ce n'est pas une erreur, c'est le fonctionnement normal.

Sélecteurs et rotation : le vrai savoir-faire DKIM

C'est ici que DKIM passe de « ça marche » à « ça marche proprement et durablement ». Le sélecteur est ta clé de voûte pour deux besoins récurrents.

Un sélecteur distinct par source d'envoi. Si tu envoies via Google Workspace et via une plateforme marketing et via ton propre serveur transactionnel, donne à chacun son propre sélecteur avec sa propre paire de clés. L'intérêt est énorme : le jour où un prestataire est compromis, ou que tu le quittes, tu révoques uniquement son sélecteur (en retirant son p=) sans toucher aux autres. Tes autres flux continuent de signer et de passer sans interruption.

La rotation régulière. Une clé DKIM n'est pas éternelle : plus elle vit longtemps, plus le risque qu'elle fuite grandit. La bonne pratique est de la faire tourner périodiquement, et le sélecteur rend l'opération indolore :

1. Génère une nouvelle paire de clés et publie la nouvelle clé publique sous un nouveau sélecteur (ex. s2), en laissant l'ancien (s1) en place.
2. Bascule ton serveur d'envoi pour qu'il signe avec la nouvelle clé (s2).
3. Attends que tout le courrier signé avec l'ancienne clé soit délivré (quelques jours de marge).
4. Retire l'ancien sélecteur (s1) du DNS.

Aucune interruption, aucun message rejeté pendant la bascule. On déroule la procédure complète, avec les pièges, dans comment faire tourner une clé DKIM sans casser sa délivrabilité. Et si tu pars de zéro, notre guide générer une paire de clés DKIM te donne les commandes exactes.

Taille de clé : 1024 vs 2048 bits

La longueur de la clé RSA détermine sa résistance. Deux tailles circulent aujourd'hui :

• 1024 bits — historiquement le standard par défaut, encore accepté par les destinataires, mais désormais considéré comme faible. Une clé 1024 bits reste cassable par un attaquant motivé disposant de ressources, et de plus en plus de fournisseurs la déclassent.
• 2048 bits — le choix à privilégier. C'est le standard recommandé aujourd'hui, offrant une marge de sécurité confortable pour les années à venir. La quasi-totalité des DNS et des plateformes d'envoi le supportent sans effort.

La seule contrainte historique du 2048 bits était la longueur de l'enregistrement DNS (d'où le découpage en chaînes mentionné plus haut), mais ce n'est plus un obstacle réel. Génère toujours du 2048 bits pour toute nouvelle clé. Si tu tournes encore en 1024, profite de ta prochaine rotation pour monter en 2048 — c'est exactement le genre de bascule que les sélecteurs rendent facile. On compare les deux en détail dans DKIM 1024 vs 2048 bits : lequel choisir.

Corps signé, en-têtes signés : ce que DKIM protège vraiment

Une subtilité utile : DKIM ne signe pas tout le message aveuglément. Il signe le corps et une liste choisie d'en-têtes (déclarée dans la balise h= de la signature). Les en-têtes non listés peuvent changer sans casser la signature — ce qui est voulu, car certains en-têtes techniques sont légitimement réécrits par les serveurs intermédiaires.

Cette distinction explique un phénomène courant : un email peut être modifié en transit (une passerelle qui ajoute une bannière « externe », une mailing-list qui appose un pied de page) et voir sa signature DKIM casser, car le corps signé n'est plus identique. Ce n'est pas forcément une attaque — c'est parfois un intermédiaire un peu trop zélé. C'est précisément pour distinguer ces cas qu'on croise DKIM avec les autres signaux. Si tu veux inspecter une signature réelle, comment vérifier une signature DKIM te montre comment lire chaque balise à la main.

DKIM face au forwarding : là où il brille

Voici l'avantage décisif de DKIM sur SPF. Quand un email est transféré (forwarding) — par exemple d'une adresse .fr vers un @gmail.com personnel — l'IP d'envoi change : c'est désormais le serveur qui transfère qui remet le message. Résultat : SPF casse, car l'IP du transfert n'est pas dans ton enregistrement SPF.

DKIM, lui, survit beaucoup mieux au transfert. La signature voyage avec le message ; tant que le corps et les en-têtes signés ne sont pas modifiés, la signature reste valide même après plusieurs sauts. C'est pourquoi DKIM est souvent le seul mécanisme qui « tient » sur du courrier transféré, et pourquoi il est essentiel de le déployer correctement. Un domaine qui ne s'appuie que sur SPF verra une partie de son courrier légitime échouer à l'authentification dès qu'il passe par un renvoi.

Pourquoi DKIM ne suffit pas : il faut DMARC par-dessus

Voici le point à ne jamais oublier. DKIM prouve qu'un message est intègre et signé par un domaine. Mais il ne vérifie pas que ce domaine correspond à celui que l'utilisateur voit dans le champ From:. Un attaquant peut parfaitement signer son courrier avec DKIM pour son propre domaine (mechant.com), passer le contrôle DKIM sans problème, et pourtant afficher ton domaine dans le From:. DKIM, seul, ne voit pas le mensonge.

Le chaînon manquant s'appelle l'alignement, et c'est le rôle de DMARC. DMARC exige que le domaine authentifié par DKIM (le d=) corresponde au domaine du From: visible. C'est cette règle qui transforme DKIM d'une simple preuve d'intégrité en une véritable protection contre l'usurpation de ton identité. Sans DMARC, DKIM est une serrure sur une porte que l'attaquant contourne simplement en passant par la fenêtre d'à côté.

C'est pourquoi DKIM, SPF et DMARC forment un tout. DKIM et SPF fournissent les preuves ; DMARC les relie à ton domaine visible et dit aux destinataires quoi faire en cas d'échec. Pour la vue d'ensemble, commence par qu'est-ce que DMARC — c'est le standard qui donne enfin du sens à ta signature DKIM.

Passe à l'action

DKIM n'est pas compliqué, mais chaque détail compte : le bon sélecteur, une clé 2048 bits, une rotation propre, et surtout DMARC par-dessus pour relier le tout à ton domaine visible. Voici l'ordre de marche que je recommande :

• Génère une clé 2048 bits et publie-la sous un sélecteur clair (un par source d'envoi).
• Vérifie que chacune de tes plateformes d'envoi signe bien en DKIM — Google et Microsoft l'activent en quelques clics, mais les outils tiers l'oublient souvent.
• Planifie une rotation régulière via un second sélecteur, sans jamais couper le flux.
• Coiffe le tout de DMARC pour exiger l'alignement et fermer la porte à l'usurpation.

Pas envie de deviner où tu en es ? Lance une vérification gratuite et instantanée de ta configuration SPF, DKIM et DMARC avec notre analyseur DMARC gratuit — il te montre tes sélecteurs détectés, la taille de tes clés, et une note claire. Puis laisse Thomas, ton RSSI virtuel, te dire exactement quoi corriger et dans quel ordre.

Analyse ton domaine gratuitement → ou crée un compte et laisse Thomas s'occuper du reste.