DKIM : le sceau qui prouve qui a réellement écrit

DKIM signe vos messages avec une clé privée que les destinataires vérifient dans votre DNS. Comment lire l’enregistrement, choisir le sélecteur et réparer ce qui manque.

DKIM est un sceau de cire. Votre serveur d’envoi appose une signature sur chaque message sortant, calculée à partir d’une clé privée que lui seul détient. La clé publique correspondante, elle, est publiée dans votre DNS. Le destinataire lit la signature, va chercher la clé publique, et vérifie que les deux correspondent. Si c’est le cas, deux choses sont établies : le message vient bien d’un serveur autorisé pour ce domaine, et son contenu n’a pas été modifié en route.

C’est la différence décisive avec SPF. SPF juge le serveur qui remet le message ; dès qu’un message est transféré, le serveur change et SPF échoue. La signature DKIM voyage dans l’en-tête du message : elle reste valable après un transfert, une liste de diffusion ou un renvoi automatique. DMARC se contente de l’un des deux contrôles, et en pratique, c’est souvent DKIM qui sauve la mise.

À quoi ressemble l’enregistrement

La clé publique est publiée sous un nom en deux morceaux : un sélecteur que vous choisissez, puis _domainkey, puis votre domaine.

google._domainkey.exemple.fr.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC…"

Chaque message signé transporte, dans son en-tête DKIM-Signature, le domaine (d=) et le sélecteur (s=) à interroger. Le destinataire n’a donc rien à deviner. Vous, si.

Le sélecteur : ce que le DNS ne dit pas

C’est le point le plus souvent mal compris, et c’est aussi la principale limite de notre vérification. Le DNS ne permet pas de lister les sélecteurs d’un domaine. Il n’existe aucune requête qui réponde « voici les clés DKIM de exemple.fr ». On ne peut qu’interroger des noms précis et voir lesquels répondent.

Notre vérification essaie donc les sélecteurs habituels des hébergeurs des cinq marchés que nous couvrons, plus une liste de noms génériques. Quand elle ne trouve rien, cela signifie exactement une chose : aucun des noms essayés n’a répondu. Cela ne signifie pas que votre domaine n’a pas de DKIM.

Comment le mettre en place

Chez la quasi-totalité des hébergeurs, vous ne fabriquez pas la clé vous-même : le panneau la génère et vous indique l’entrée DNS à publier. Souvent, ce n’est même pas un TXT mais un CNAME, un simple renvoi vers la clé que le prestataire fait tourner à votre place. C’est le cas chez Microsoft 365 et chez IONOS.

Voici les sélecteurs que notre vérification connaît pour les hébergeurs du marché francophone. Ils viennent de notre table de signatures, pas d’une supposition.

Les noms génériques – default, dkim, mail, selector1, mailjet, k1 – sont essayés pour tous les domaines, quel que soit l’hébergeur détecté.

Le chemin chez OVHcloud, pas à pas

1. Dans l’espace client OVHcloud, ouvrez Web Cloud, puis E-mails et le service concerné.
2. Ouvrez l’onglet E-mails sortants ou DKIM, selon la version de l’interface.
3. Activez DKIM pour le domaine. OVHcloud génère la paire de clés et propose les entrées DNS correspondantes.
4. Si votre zone DNS est gérée chez OVHcloud, acceptez la configuration automatique : les entrées sont ajoutées pour vous.
5. Si vos serveurs de noms sont ailleurs, copiez les entrées proposées et publiez-les dans la zone de cet autre prestataire.
6. Envoyez-vous un message de test, ouvrez « Afficher l’original » et vérifiez que la ligne DKIM-Signature est présente et que le contrôle est indiqué comme réussi.

L’étape 6 n’est pas une précaution de plus : une clé publiée sans que le serveur signe réellement est un cas fréquent, et il ne se voit que dans un message réel.

Les constats en détail

Aucune clé DKIM trouvée

Nous avons interrogé les sélecteurs habituels de votre hébergeur, plus une liste générique. Aucun n’a répondu.

Rappelons-le, parce que le constat prête à confusion : cela ne veut pas dire que DKIM est absent. Si votre hébergeur attribue des sélecteurs comportant un numéro – OVHcloud et Amazon SES le font –, il est normal qu’une recherche à l’aveugle échoue. Le constat ne devient inquiétant que si vous ne savez pas non plus si DKIM est activé.

Ce qu’il faut faire. Ouvrez un message que vous avez envoyé, affichez sa source, cherchez DKIM-Signature. Si la ligne existe, notez le s= et relancez la vérification avec ce sélecteur : tout est en ordre. Si la ligne n’existe pas, DKIM n’est pas activé – ouvrez le panneau de votre hébergeur et activez-le.

Clé DKIM révoquée

L’enregistrement du sélecteur existe, mais son champ p= est vide.

C’est la manière normale de mettre une clé hors service : on la vide plutôt que de la supprimer, pour que les messages signés avec elle et encore en circulation échouent proprement au lieu de rencontrer un enregistrement manquant. Vue isolément, une clé révoquée n’est donc pas un défaut – c’est une rotation en cours.

Ce qu’il faut faire. Vérifiez qu’un autre sélecteur du même domaine porte bien une clé valide. Si oui, il n’y a rien à faire ; l’enregistrement vide pourra être supprimé une fois que plus aucun message signé avec cette clé ne circule, disons après quelques semaines.

Toutes les clés DKIM trouvées sont révoquées

Chaque sélecteur détecté porte un p= vide. Aucune clé utilisable n’a été trouvée.

Cette fois, il n’y a pas de lecture rassurante. Le courrier sortant n’est plus signé, ou l’est avec une clé que personne ne peut vérifier. Dès que SPF ne s’aligne pas – un transfert suffit –, le message échoue à DMARC. C’est le résidu typique d’une rotation interrompue à mi-chemin : l’ancienne clé a été vidée, la nouvelle n’a jamais été publiée.

Ce qu’il faut faire. Sans attendre. Générez une nouvelle clé dans le panneau de votre fournisseur de messagerie, publiez l’enregistrement qu’il vous donne, puis envoyez un message de test et vérifiez la ligne DKIM-Signature dans sa source.

Clé DKIM trop courte

La clé publiée fait moins de 1024 bits.

En dessous de ce seuil, une clé RSA est considérée comme non sûre, et plusieurs grands opérateurs de messagerie n’évaluent plus les signatures correspondantes. Le résultat est le même qu’une absence de signature : DKIM ne compte plus pour DMARC.

Ce qu’il faut faire. Générez une clé de 2048 bits chez votre fournisseur, publiez-la sur un nouveau sélecteur, laissez le serveur signer avec la nouvelle clé, puis videz l’ancienne au bout de quelques semaines.

Clé DKIM de 1024 bits

La clé fait exactement 1024 bits.

Elle est encore acceptée partout, mais elle est dépassée : 2048 bits est le standard actuel. Ce n’est pas une urgence, c’est une tâche à inscrire dans la prochaine intervention sur le domaine.

Ce qu’il faut faire. Au prochain passage dans le panneau, générez une clé de 2048 bits sur un nouveau sélecteur. Certains hébergeurs limitent encore la longueur de l’enregistrement TXT et ne permettent pas 2048 bits – dans ce cas, 1024 reste préférable à rien, et c’est un argument de plus pour changer d’hébergeur le jour venu.

DKIM en mode test (t=y)

L’enregistrement contient l’indicateur t=y.

Ce drapeau demande explicitement aux destinataires de traiter une signature en échec comme si elle n’existait pas. Il est prévu pour la phase de mise en route, le temps de vérifier que la signature fonctionne. Tant qu’il est là, DKIM ne protège de rien : c’est une répétition, pas une représentation.

Ce qu’il faut faire. Retirez t=y de l’enregistrement. Si vous n’êtes pas certain que la signature fonctionne, vérifiez-le d’abord dans la source d’un message envoyé – puis retirez le drapeau.

Clé DKIM illisible

Un enregistrement existe au nom d’un sélecteur, mais son contenu ne peut pas être analysé.

La cause est presque toujours mécanique : un saut de ligne conservé au copier-coller, des espaces insérés au milieu de la clé, des guillemets de trop, ou une interface d’hébergeur qui a tronqué la valeur. La clé est là, mais elle ne ressemble plus à une clé.

Ce qu’il faut faire. Retournez chercher la valeur chez votre fournisseur et ressaisissez-la sur une seule ligne, sans espace à l’intérieur de p=. Si l’interface refuse une valeur de cette longueur, c’est le signe qu’elle ne gère pas correctement les enregistrements découpés : demandez au support, ou publiez la clé en CNAME si le fournisseur le propose.

Questions fréquentes

Combien de clés DKIM faut-il ?

Une par service qui envoie en votre nom. Votre messagerie signe avec son sélecteur, l’outil de newsletter avec le sien, la boutique avec le sien. Il n’y a pas de limite et rien ne se gêne : c’est précisément le rôle du sélecteur.

Faut-il changer de clé régulièrement ?

C’est une bonne pratique, sans obligation. La marche à suivre est toujours la même : publier une nouvelle clé sur un nouveau sélecteur, basculer la signature dessus, attendre quelques semaines, puis vider l’ancienne en laissant p= vide. Ce qu’il ne faut pas faire, c’est vider l’ancienne avant que la nouvelle ne soit en place – vous obtenez alors le constat « toutes les clés révoquées ».

DKIM suffit-il sans SPF ?

Non, et l’inverse non plus. DMARC exige que l’un des deux contrôles réussisse et que le domaine correspondant s’aligne avec l’expéditeur affiché. Publier les deux vous donne deux chances plutôt qu’une, ce qui compte pour le courrier transféré.

Pourquoi le rapport parle-t-il de CNAME et pas de TXT ?

Parce que plusieurs fournisseurs préfèrent garder la main sur la clé. Vous publiez un renvoi, ils publient la clé derrière : ils peuvent ainsi effectuer les rotations sans vous demander de modifier votre zone. Microsoft 365 et IONOS fonctionnent ainsi. Pour le destinataire, le résultat est identique.