Publier le DKIM dans les DNS revient à ajouter dans la zone du domaine un enregistrement TXT nommé selecteur._domainkey.domaine, qui porte la clé publique. Le serveur d'envoi signe chaque message avec la clé privée ; sans cet enregistrement, le destinataire ne peut rien vérifier.
DKIM dans les DNS en quatre repères
- Le nom de l'enregistrement : un sélecteur choisi par l'outil d'envoi, puis _domainkey, puis le domaine.
- La valeur : v=DKIM1; k=rsa; p= suivi de la clé publique, 2 048 bits de préférence.
- Selon le fournisseur de messagerie, un enregistrement TXT ou un enregistrement CNAME qui délègue la clé.
- La signature s'active côté serveur une fois la clé visible dans la zone DNS, jamais avant.
Pourquoi DKIM n'est plus une option pour un domaine qui envoie
La signature DKIM, longtemps proposée comme un réglage facultatif, conditionne aujourd'hui la livraison du courrier vers les grandes boîtes. Depuis le 1er février 2024, Gmail exige de tout expéditeur une authentification SPF ou DKIM ; pour un expéditeur qui dépasse 5 000 messages par jour vers ses boîtes, il faut les deux, plus une politique DMARC publiée. Yahoo a annoncé des conditions voisines à la même date, et Microsoft applique depuis le 5 mai 2025 des règles comparables aux gros expéditeurs vers Outlook.com, Hotmail et Live.
Un domaine qui envoie des factures, des notifications de site, des confirmations de commande ou une lettre d'information sans signature DKIM voit donc une partie de ses messages classés en courrier indésirable, voire refusés. Les petits volumes ne sont pas épargnés : un mail non signé part avec un handicap dans les filtres, surtout quand le serveur d'envoi partage son adresse IP avec d'autres clients d'un hébergement mutualisé. Le TXT DKIM fait partie de la configuration DNS de base d'un domaine qui écrit, au même titre que l'enregistrement MX pour recevoir et l'enregistrement SPF pour déclarer les serveurs autorisés.
DKIM apporte aussi un avantage de sécurité des emails : la signature cryptographique prouve que le corps du message et les en-têtes signés n'ont pas changé en route, ce qui freine l'usurpation d'identité et le hameçonnage au nom du domaine.
Comment fonctionne une signature DKIM, de l'envoi à la réception
La norme DomainKeys Identified Mail, décrite par la RFC 6376 de l'IETF, repose sur une paire de clés RSA : une clé privée, gardée par le système d'envoi, et une clé publique, publiée dans la zone DNS du domaine. Au moment de l'envoi, le serveur calcule par une fonction de hachage SHA-256 une empreinte du corps et de certains en-têtes (From, Subject, Date, To), la chiffre avec la clé privée et ajoute le résultat dans un en-tête DKIM-Signature. La clé privée reste stockée sur le serveur ou chez le prestataire ; seule la donnée publique circule dans le DNS. DKIM ne chiffre pas la connexion entre serveurs, rôle de TLS : il authentifie le contenu, pas le transport.
Cet en-tête DKIM-Signature contient plusieurs balises utiles au diagnostic :
- d=
- le domaine signataire, celui dont la zone DNS porte la clé publique ;
- s=
- le sélecteur, qui indique quel enregistrement interroger dans cette zone ;
- a=
- l'algorithme utilisé, presque toujours rsa-sha256 ;
- h=
- la liste des en-têtes couverts par la signature ;
- bh= et b=
- l'empreinte du corps du message et la signature elle-même.
À la réception, le serveur de messagerie du destinataire lit d= et s=, construit le nom s._domainkey.d, interroge le DNS, récupère la clé publique et vérifie la signature. Si le calcul concorde, le résultat vaut dkim=pass ; si la clé est introuvable, tronquée ou si le message a changé, il vaut dkim=fail ou dkim=permerror. Le contrôle ne demande aucune action du destinataire : tout se joue entre le serveur qui signe et la zone DNS qui publie.
À quoi ressemble l'enregistrement TXT de la clé DKIM
L'enregistrement DKIM place la clé publique sous un sous-domaine réservé, _domainkey, précédé d'un sélecteur librement choisi. Le sélecteur permet d'avoir plusieurs clés valides en parallèle, par exemple une pour le serveur du site et une pour l'outil d'envoi de lettres d'information, ou une ancienne et une nouvelle pendant une rotation.
mail2026._domainkey.exemple.fr. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"- v=DKIM1 : la version, placée en tête quand elle figure.
- k=rsa : l'algorithme de la clé, rsa par défaut ; ed25519 existe depuis la RFC 8463, mais peu de services la valident seule.
- p= : la clé publique encodée en base64 ; une valeur vide signale une clé révoquée.
- t=y : facultatif, indique un domaine en phase de test ; à retirer une fois la configuration validée.
Une clé RSA de 2 048 bits dépasse 255 caractères, la longueur maximale d'une chaîne TXT fixée par la RFC 1035. Les interfaces DNS récentes, comme celle de Cloudflare ou l'espace client OVHcloud, découpent seules la valeur en plusieurs chaînes entre guillemets ; dans un fichier de zone écrit à la main, il faut faire ce découpage soi-même, les morceaux étant recollés à la lecture sans espace.
TXT ou CNAME : ce que demande chaque fournisseur de messagerie
Le format de l'enregistrement DNS dépend de qui détient la clé privée. Quand le domaine signe lui-même ses mails (serveur Postfix avec OpenDKIM, panneau d'un hébergement mutualisé), il publie un enregistrement TXT avec la clé publique. Quand un service tiers signe à sa place, il fournit souvent un enregistrement CNAME qui pointe vers une clé hébergée chez lui : le service peut alors changer de clé sans que le titulaire du domaine touche à sa zone. Le choix entre les deux solutions relève de la gestion technique : un CNAME laisse au fournisseur cloud le soin de gérer la clé et sa rotation, un TXT donne un contrôle complet mais impose de refaire la configuration à chaque changement de clé.
Microsoft 365 et Exchange Online
Microsoft 365 demande deux enregistrements CNAME, selector1._domainkey et selector2._domainkey, dont les cibles s'affichent dans le portail Microsoft Defender pour chaque domaine personnalisé. Une fois les deux CNAME DKIM visibles, l'activation se fait dans le même écran ; Microsoft alterne ensuite entre les deux sélecteurs lors des rotations.
Google Workspace
Google Workspace génère la clé dans la console d'administration (Applications, Gmail, Authentifier les e-mails), avec le sélecteur google par défaut et une longueur de 2 048 bits. L'administrateur copie l'enregistrement TXT dans sa zone DNS, attend qu'il soit publié, puis clique sur le bouton qui démarre l'authentification.
OVHcloud et les autres hébergeurs
OVHcloud propose un onglet DKIM sur ses offres e-mail dans l'espace client ; si la zone DNS est hébergée chez lui, il peut ajouter lui-même les enregistrements CNAME. Pour un domaine dont la zone se gère chez un autre bureau d'enregistrement, il faut saisir le nom et la valeur indiqués à la main. Les plateformes d'envoi (Brevo, Mailchimp, Amazon SES) suivent la même logique : un ou plusieurs enregistrements CNAME ou TXT, un bouton de vérification, puis la signature au nom du domaine.
Configurer DKIM étape par étape sans couper l'envoi
- Recenser tout ce qui envoie au nom du domaine : messagerie, site web, outil de facturation, plateforme de lettres d'information. Chaque service qui signe a besoin de son propre sélecteur.
- Créer la paire de clés dans le panneau du service ou sur le serveur, en 2 048 bits si le fournisseur DNS l'accepte, et noter le sélecteur proposé.
- Ajouter un enregistrement dans la zone DNS sur le nom exact indiqué, sans espace parasite, sans guillemet en trop, sans répéter le domaine quand l'interface l'ajoute d'office.
- Attendre la propagation DNS de la zone, qui dépend du TTL, puis seulement activer la signature côté serveur.
- Envoyer un message de test vers une boîte externe et lire ses en-têtes.
- Publier ensuite une politique DMARC en mode observation (p=none) pour recevoir les rapports et repérer les sources non signées.
Inverser les étapes 3 et 4 produit l'effet redouté : des messages signés avec une clé que personne ne trouve, donc en échec DKIM pendant toute la durée de la propagation. Avant toute modification, exporter la zone DNS actuelle permet de revenir en arrière en quelques minutes si un enregistrement a écrasé un autre.
Pour configurer DKIM sur un serveur dédié ou un VPS, le paquet OpenDKIM sert de générateur de clés : la commande opendkim-genkey -b 2048 -s mail2026 -d exemple.fr crée la paire et un fichier mail2026.txt prêt à copier dans la zone. Le paramètre KeyTable de sa configuration indique ensuite quelle clé utiliser pour quel domaine, et SigningTable quelle adresse d'expéditeur doit utiliser quel sélecteur. Sur un hébergement mutualisé, inutile d'utiliser ces outils : le panneau de l'hébergeur produit la clé et affiche la valeur à publier.
Vérifier un enregistrement DKIM et lire le résultat
La vérification d'un enregistrement DKIM commence par une requête DNS directe. La commande dig interroge la zone et montre si la clé est publiée telle qu'attendue :
dig +short TXT mail2026._domainkey.exemple.frPour un CNAME, la même commande suit la délégation et renvoie la clé hébergée par le fournisseur. Sous Windows, nslookup -type=TXT donne le même renseignement. Une réponse vide signifie un nom mal saisi, une zone pas encore propagée ou un enregistrement ajouté dans une autre zone que celle qui fait autorité.
Le contrôle décisif reste le message reçu : dans les en-têtes, la ligne Authentication-Results doit contenir dkim=pass suivi du domaine signataire. Un résultat dkim=fail vient presque toujours d'une clé tronquée lors du copier-coller, d'un sélecteur mal orthographié ou d'un message modifié par un relais, comme un pied de page ajouté par une liste de diffusion. Les réglages du logiciel de messagerie n'y sont pour rien : la signature est posée par le serveur, pas par le poste. Un outil de vérification en ligne (MXToolbox, l'outil DKIM de dmarcian ou de CaptainDNS) lit la clé et contrôle sa syntaxe en quelques secondes, sans remplacer le test d'un vrai envoi. Quand la vérification échoue malgré une clé correcte, le support ou l'assistance du fournisseur demande en général la ligne Authentication-Results complète et l'en-tête DKIM-Signature : les fournir d'emblée évite un échange supplémentaire. Le niveau de sécurité dépend aussi de la longueur de la clé utilisée, point traité plus bas.
DKIM, SPF et DMARC : trois enregistrements qui ne font pas la même chose
DKIM, SPF et DMARC se publient tous les trois dans la zone DNS, mais chacun répond à une question différente. SPF déclare les serveurs autorisés à envoyer pour le domaine ; DKIM prouve qu'un message signé n'a pas changé depuis son départ ; DMARC dit au destinataire quoi faire quand les deux contrôles échouent et vérifie que le domaine authentifié correspond à celui que lit l'utilisateur dans le champ From.
| Norme | Nom dans la zone | Ce qu'elle contrôle | Point faible seule |
|---|---|---|---|
| SPF | TXT sur le domaine | L'adresse IP du serveur d'envoi | Casse au transfert d'un message |
| DKIM | TXT ou CNAME sur selecteur._domainkey | L'intégrité du message signé | Ne dit rien du domaine affiché |
| DMARC | TXT sur _dmarc | L'alignement avec le From et la politique | Inutile sans SPF ou DKIM valide |
L'enregistrement SPF s'écrit à part, et ses pièges (plusieurs lignes, plus de dix requêtes DNS) sont détaillés dans la réponse sur la syntaxe d'un SPF sans erreur. La politique DMARC, elle, se règle par paliers : p=none pour observer, puis quarantine, puis reject quand les rapports montrent que tous les envois légitimes passent. Les balises rua, pct et l'alignement strict sont expliqués dans la page consacrée au contenu d'un enregistrement DMARC.
Clé, sélecteur et rotation : les cas qui bloquent la signature
Quelle longueur de clé DKIM choisir ?
La clé DKIM conseillée fait 2 048 bits quand le fournisseur DNS l'accepte, ce que recommande Google. La RFC 8301 fixe 1 024 bits comme minimum à valider ; une clé plus courte est rejetée par la plupart des serveurs de réception.
Faut-il changer de clé DKIM régulièrement ?
Une rotation de la clé DKIM, par exemple annuelle, limite les dégâts d'une clé privée compromise. La méthode : publier la nouvelle clé sous un nouveau sélecteur, basculer la signature, puis vider la valeur p= de l'ancienne quelques semaines plus tard, le temps que les messages en transit soient vérifiés.
Un sous-domaine a-t-il besoin de sa propre clé ?
Un sous-domaine qui envoie avec son propre From (factures.exemple.fr) se signe avec d=factures.exemple.fr, et sa clé se publie sous selecteur._domainkey.factures.exemple.fr. Un service peut aussi signer avec le domaine parent ; DMARC en alignement souple accepte alors le message.
Un domaine qui n'envoie jamais de mail a-t-il besoin de DKIM ?
Un domaine qui n'envoie aucun courrier n'a pas besoin de clé DKIM, mais il gagne à publier un SPF « v=spf1 -all » et un DMARC en rejet pour décourager l'usurpation de son nom par des tiers.
Sources : RFC 6376 de l'IETF (DomainKeys Identified Mail), RFC 8301 (algorithmes et longueur des clés), RFC 8463 (ed25519), RFC 1035 pour la longueur des chaînes TXT, aide Google Workspace sur les exigences applicables aux expéditeurs vers Gmail (entrée en vigueur le 1er février 2024), annonce Microsoft sur les expéditeurs de gros volumes vers Outlook.com (5 mai 2025).
