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

Quand on configure DKIM, un mot revient sans qu'on l'explique vraiment : le sélecteur. On te demande d'ajouter un enregistrement DNS à quelquechose._domainkey.ton-domaine.fr, et ce « quelquechose » est le sélecteur. Comprendre ce qu'il est lève d'un coup beaucoup de confusions sur DKIM — pourquoi il y en a plusieurs, comment la rotation des clés fonctionne, et pourquoi une signature peut échouer alors que « la clé est bien là ». Ce guide explique le sélecteur DKIM simplement, avec ce qu'il faut savoir en pratique.

À quoi sert un sélecteur

DKIM repose sur une paire de clés : une clé privée qui signe tes messages (gardée secrète par ta plateforme d'envoi) et une clé publique publiée dans ton DNS, que le destinataire récupère pour vérifier la signature. Mais un domaine peut avoir plusieurs clés publiques en même temps — une par plateforme d'envoi, par exemple. Comment le destinataire sait-il laquelle utiliser pour vérifier un message donné ?

C'est exactement le rôle du sélecteur. Chaque signature DKIM ajoutée à un email contient une étiquette s= (le sélecteur) qui dit au destinataire : « la clé publique pour vérifier ce message se trouve à ce sélecteur ». Le sélecteur est donc un pointeur : il relie une signature à la bonne clé publique dans ton DNS.

Où le sélecteur apparaît

Le sélecteur vit à deux endroits, et c'est utile de les relier :

1. Dans l'en-tête DKIM-Signature du message, via l'étiquette s=. Par exemple : s=selector1; d=ton-domaine.fr; ....
2. Dans ton DNS, comme un enregistrement TXT à l'adresse <sélecteur>._domainkey.<domaine>. Pour s=selector1 et d=ton-domaine.fr, le destinataire interroge :

selector1._domainkey.ton-domaine.fr

et y trouve la clé publique :

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

La vérification est donc un aller-retour limpide : le destinataire lit s= et d= dans la signature, construit l'adresse DNS, récupère la clé publique, et vérifie. Si la clé n'est pas là, ou ne correspond pas, la signature échoue.

Pourquoi tu as 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). Si tu envoies via Microsoft 365, un routeur marketing et un outil de facturation, chacun a sa propre clé DKIM, donc son propre sélecteur. Tu publies un enregistrement TXT par sélecteur.
• La rotation des clés crée des sélecteurs. Quand tu renouvelles une clé DKIM, tu publies une nouvelle clé sous un nouveau sélecteur, tu bascules la signature dessus, puis tu retires 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. Tu croiseras 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, tu ne « crées » pas un sélecteur à la main : ta plateforme d'envoi le génère pour toi et te donne l'enregistrement DNS à publier (souvent un CNAME qui pointe vers un enregistrement géré par le prestataire, ou un TXT avec la clé publique). Ton travail se résume à :

1. Activer DKIM dans la console de la plateforme (Microsoft 365, Google Workspace, ton routeur…).
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 que tu aies à retoucher ton 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 de ton From:. Le sélecteur, lui, ne concerne que la récupération de la clé ; c'est l'étiquette d= qui porte l'alignement. Tu peux donc avoir une signature parfaitement valide qui ne compte pas pour DMARC, parce que le d= est celui du prestataire, pas le tien. La solution est de configurer une signature à ta marque (d=ton-domaine.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, interroge directement le sélecteur en DNS (dig TXT selector1._domainkey.ton-domaine.fr) et vérifie que la clé publique est bien là 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é pour toi sans que tu retouches ton DNS à chaque rotation. C'est généralement la bonne option : tu publies une fois, 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. Tu envoies une facture depuis entreprise.fr via ta plateforme, 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 te permet de diagnostiquer n'importe quel échec : tu sais 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. Donne à tes sélecteurs des noms parlants et datés quand tu les contrôles (mail-2025, routeur-marketing), plutôt que des chaînes opaques : tu retrouveras plus vite lequel sert à quoi. Tiens un inventaire simple — quel sélecteur pour quelle plateforme, depuis quand — au même titre que ton inventaire de sources d'envoi. Et surtout, retire les sélecteurs morts 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. Si tu envoies depuis news.entreprise.fr, ce sous-domaine a besoin de 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 on configure DKIM seulement pour le domaine principal, puis qu'on se demande pourquoi les envois marketing ou les notifications automatisées ne s'alignent pas dans les rapports DMARC. Avant de te demander « est-ce que ma clé est bonne ? », vérifie d'abord « est-ce que j'ai bien publié une clé pour chaque domaine et sous-domaine d'envoi ? »

Laisse Thomas cartographier tes 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, ton 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 ton domaine — et te signale les sélecteurs morts à nettoyer.

Analyse ton domaine gratuitement → ou crée un compte pour y voir clair dans tes clés DKIM.