Le sélecteur DKIM, c'est quoi (et pourquoi il y en a plusieurs)

selector1._domainkey.exemple.fr

selector1._domainkey.exemple.fr.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkq... (clé publique)"

Pourquoi il y a souvent plusieurs sélecteurs

C'est le point qui surprend. Un domaine n'a presque jamais un seul sélecteur, et c'est normal :

• Une plateforme = un sélecteur (au moins). Avec des envois via Microsoft 365, un routeur marketing et un outil de facturation, chacun a sa propre clé DKIM, donc son propre sélecteur — et un enregistrement TXT à publier par sélecteur.
• La rotation des clés crée des sélecteurs. Renouveler une clé DKIM, c'est publier une nouvelle clé sous un nouveau sélecteur, basculer la signature dessus, puis retirer l'ancien. Pendant la transition, deux sélecteurs coexistent (voir rotation des clés).
• Les sous-domaines peuvent avoir leurs propres sélecteurs.

Avoir plusieurs sélecteurs n'est donc pas un problème — c'est le fonctionnement attendu. Chaque sélecteur est indépendant, et un destinataire n'utilise que celui indiqué dans la signature qu'il vérifie.

À quoi ressemble un nom de sélecteur

Le nom du sélecteur est libre, et chaque plateforme a ses conventions. On croise par exemple selector1/selector2 (Microsoft 365), google (Google Workspace), des noms datés comme s1024-2024, ou des chaînes générées par un prestataire. Le nom n'a aucune importance technique : ce qui compte, c'est que le sélecteur de la signature corresponde à un enregistrement DNS existant. Inutile donc de chercher un sens caché dans un nom de sélecteur — c'est juste une étiquette.

Comment activer un sélecteur DKIM

En pratique, un sélecteur ne se « crée » pas à la main : la plateforme d'envoi le génère et fournit l'enregistrement DNS à publier (souvent un CNAME qui pointe vers un enregistrement géré par le prestataire, ou un TXT avec la clé publique). Le travail se résume à :

1. Activer DKIM dans la console de la plateforme (Microsoft 365, Google Workspace, le routeur d'envoi…).
2. Publier l'enregistrement fourni au sélecteur indiqué.
3. Vérifier que la signature passe et s'aligne (voir comment vérifier une signature email).

Le CNAME est souvent préférable au TXT brut : il laisse le prestataire faire tourner la clé sans qu'il faille retoucher le DNS.

L'alignement : le sélecteur ne fait pas tout

Un point crucial pour DMARC. Une signature DKIM valide prouve qu'un domaine a signé le message — mais pour DMARC, encore faut-il que ce domaine (d=) s'aligne avec celui du From:. Le sélecteur, lui, ne concerne que la récupération de la clé ; c'est l'étiquette d= qui porte l'alignement. D'où des signatures parfaitement valides qui ne comptent pas pour DMARC, parce que le d= est celui du prestataire et non celui de l'expéditeur. La solution est de configurer une signature à la marque de l'expéditeur (d=exemple.fr) sur chaque plateforme. Ce mécanisme est détaillé dans comment les trois protocoles fonctionnent ensemble.

Dépanner un sélecteur

Quand une signature DKIM échoue, le sélecteur est souvent en cause. Les pistes classiques :

• L'enregistrement DNS du sélecteur est absent ou mal publié (faute de frappe dans le nom, mauvais sous-domaine ._domainkey).
• La clé publique a été tronquée au copier-coller (les clés sont longues ; un caractère manquant casse la vérification).
• Le sélecteur de la signature ne correspond à aucun enregistrement — typiquement après une rotation mal terminée, où l'on a retiré l'ancien sélecteur avant d'avoir basculé la signature.
• La propagation DNS n'est pas terminée : un sélecteur fraîchement publié peut mettre un peu de temps à être visible partout.

Pour confirmer, le sélecteur s'interroge directement en DNS (dig TXT selector1._domainkey.exemple.fr) : la clé publique doit y être, et complète.

Questions fréquentes

Combien de sélecteurs puis-je avoir ? Autant que nécessaire — il n'y a pas de limite gênante. Une plateforme par sélecteur, plus ceux créés temporairement par la rotation. Avoir plusieurs sélecteurs est sain, pas problématique.

Puis-je supprimer un ancien sélecteur ? Oui, mais seulement quand plus aucune signature ne l'utilise (typiquement après une rotation terminée). Supprimer un sélecteur encore référencé par des messages en transit casse leur vérification.

Le sélecteur est-il secret ? Non. Le sélecteur et la clé publique sont publics par nature (ils sont dans le DNS et dans chaque email signé). C'est la clé privée, côté plateforme d'envoi, qui doit rester secrète.

Pourquoi mon prestataire me donne-t-il un CNAME plutôt qu'un TXT ? Pour pouvoir faire tourner la clé sans imposer une retouche du DNS à chaque rotation. C'est généralement la bonne option : une publication unique, et le prestataire gère la suite.

Deux plateformes peuvent-elles partager un sélecteur ? En théorie, mais c'est déconseillé : chaque plateforme a sa propre clé, donc son propre sélecteur. Mélanger complique le dépannage et la rotation.

Tracer une vérification, étape par étape

Pour ancrer le rôle du sélecteur, suivons un message réel. Une facture part de entreprise.fr via une plateforme d'envoi, qui signe avec s=mail2025; d=entreprise.fr. Voici ce que fait le serveur destinataire :

1. Il lit l'en-tête DKIM-Signature et y trouve s=mail2025 et d=entreprise.fr.
2. Il construit l'adresse DNS : mail2025._domainkey.entreprise.fr.
3. Il interroge cette adresse et récupère la clé publique publiée.
4. Il recalcule le hash du message et le compare à la signature. Si tout concorde : dkim=pass.
5. Il vérifie enfin que d=entreprise.fr correspond au domaine du From: — l'alignement, indispensable pour DMARC.

Si l'une de ces étapes échoue — sélecteur introuvable, clé tronquée, hash différent — la signature ne passe pas. Comprendre cette chaîne permet de diagnostiquer n'importe quel échec : on sait exactement où regarder, et dans quel ordre.

Organiser ses sélecteurs proprement

Avec le temps, un domaine accumule des sélecteurs : un par plateforme, plus ceux laissés par d'anciennes rotations. Quelques principes évitent le chaos. Des noms parlants et datés quand le choix est libre (mail-2025, routeur-marketing) valent mieux que des chaînes opaques : on retrouve plus vite lequel sert à quoi. Un inventaire simple — quel sélecteur pour quelle plateforme, depuis quand — se tient au même titre que l'inventaire des sources d'envoi. Et surtout, les sélecteurs morts se retirent une fois leurs rotations terminées : un sélecteur orphelin n'est pas dangereux, mais il encombre et brouille le diagnostic le jour où une signature échoue. Un DNS bien tenu est un DNS où chaque enregistrement _domainkey a une raison d'être connue — c'est ce qui transforme un dépannage d'une heure en un coup d'œil de deux minutes.

Sélecteur et sous-domaines : un cas à connaître

Un point qui surprend souvent : les sous-domaines ne « héritent » pas du sélecteur du domaine racine. Un envoi depuis news.entreprise.fr suppose que ce sous-domaine ait son propre enregistrement DKIM — par exemple mail._domainkey.news.entreprise.fr — et la signature doit indiquer d=news.entreprise.fr pour que l'alignement DMARC soit correct. Domaine racine et sous-domaines sont indépendants, avec leurs propres sélecteurs et leurs propres clés. Cette réalité est souvent ignorée quand DKIM n'est configuré que pour le domaine principal, avant qu'on se demande pourquoi les envois marketing ou les notifications automatisées ne s'alignent pas dans les rapports DMARC. Avant la question « la clé est-elle bonne ? » vient donc celle-ci : « une clé a-t-elle bien été publiée pour chaque domaine et sous-domaine d'envoi ? »

Thomas cartographie les sélecteurs

Entre les sélecteurs de chaque plateforme et ceux laissés par d'anciennes rotations, il est facile de s'y perdre. Thomas, le RSSI virtuel, identifie chaque source d'envoi, repère le sélecteur qu'elle utilise, vérifie que la clé publique est bien publiée et que la signature s'aligne avec le domaine expéditeur — et signale les sélecteurs morts à nettoyer.

Analyser un domaine gratuitement ou créer un compte pour y voir clair dans ses clés DKIM.