Sélecteur DKIM : définition et configuration DNS

On remarque généralement un sélecteur DKIM quand l’authentification échoue, que Gmail classe des messages en spam ou qu’un fournisseur demande un TXT étrange comme tm1._domainkey.example.com. Voilà le problème : ce détail paraît mineur, mais une erreur peut faire échouer DKIM. DMARC peut aussi échouer s’il n’existe pas de résultat SPF valide et aligné pour compenser. La délivrabilité peut en souffrir.

La situation se complique avec plusieurs expéditeurs sur un domaine. L’hébergeur des boîtes signe avec une clé, l’outil marketing avec une autre, le CRM avec une troisième. Sans comprendre le sélecteur, vous ne pouvez pas attribuer chaque signature à son système, savoir quel enregistrement faire évoluer ni expliquer pourquoi un flux réussit et un autre échoue. Pour le contexte général, commencez par la messagerie professionnelle.

La solution : considérer le sélecteur comme une étiquette orientant la recherche des clés DKIM. Une fois son lien avec le DNS compris, configuration et diagnostic deviennent une procédure plutôt qu’un mystère.

Qu’est-ce qu’un sélecteur DKIM ?

C’est l’étiquette d’une signature DKIM indiquant au destinataire quelle clé publique récupérer dans le DNS. Un domaine peut ainsi publier plusieurs clés simultanément pour différents systèmes, flux ou rotations.

Le sélecteur n’est pas la clé, mais l’indication permettant de la trouver. Dans DKIM-Signature, il figure dans s= ; le domaine signataire figure dans d=. Le destinataire combine les deux dans une requête comme selector._domainkey.example.com et récupère la clé du TXT correspondant.

Le RFC 6376 le définit directement : le vérificateur utilise le domaine de d= et le sélecteur de s= pour trouver l’enregistrement de clé publique. Sans sélecteur, la recherche est impossible ; avec un mauvais sélecteur, elle vise le mauvais emplacement. Dans les deux cas, la vérification DKIM peut échouer.

Si un message contient d=example.com et s=tm1, le destinataire recherche tm1._domainkey.example.com.

À quoi sert réellement le sélecteur DKIM ?

Il indique quelle clé publique utiliser pour un message précis. Plusieurs clés peuvent ainsi coexister sous un domaine sans collision.

Trois raisons opérationnelles l’expliquent.

1. Séparer les expéditeurs. Votre outil de support peut utiliser un sélecteur et votre application transactionnelle un autre.
2. Permettre la rotation. Publiez un nouveau sélecteur, basculez la signature, puis retirez l’ancien une fois les messages en transit acheminés.
3. Limiter la portée des incidents. Si une clé de fournisseur est compromise ou révoquée, les autres expéditeurs n’ont pas tous besoin de changer.

Les configurations bien entretenues évitent donc généralement une clé unique conservée indéfiniment. Elles utilisent plusieurs enregistrements DKIM, chacun avec son sélecteur, gérés comme d’autres identifiants sensibles.

Où trouver le sélecteur DKIM ?

Dans les en-têtes du message ou les instructions DNS du fournisseur d’envoi. Dans un message réel, il apparaît comme valeur de s= dans DKIM-Signature.

Ouvrez les en-têtes bruts d’un message reçu et recherchez DKIM-Signature:. Deux balises vous intéressent :

• d= indique le domaine signataire.
• s= indique le sélecteur DKIM.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=tm1;
 c=relaxed/relaxed; h=from:to:subject:date:message-id;
 bh=...; b=...

Ici, le sélecteur est tm1. L’enregistrement à examiner est :

tm1._domainkey.example.com TXT

Pour un nouvel expéditeur, le fournisseur donne généralement le sélecteur et une valeur TXT ou une cible CNAME. TrekMail affiche les enregistrements nécessaires dans la configuration du domaine et permet leur contrôle depuis le tableau de bord, selon les fonctions disponibles. Consultez les enregistrements DNS requis et la vérification de l’état DNS pour remplir les bons champs.

Comment publier un sélecteur DKIM dans le DNS ?

Créez un enregistrement à selector._domainkey.yourdomain.com. Il s’agit généralement d’un TXT DKIM ou, chez certains prestataires, d’un CNAME pointant vers leur clé gérée.

Voici les deux modèles courants.

DKIM avec TXT :

Host: tm1._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

DKIM avec CNAME :

Host: tm1._domainkey
Type: CNAME
Value: tm1.example-com.dkim.vendor.net.

N’inventez pas le sélecteur. Utilisez exactement celui du système signataire. Si le fournisseur indique s1, publiez s1._domainkey. Si TrekMail affiche dkim._domainkey pour l’envoi géré du domaine, utilisez ce nom et cette valeur. La configuration SMTP personnalisé (BYO) peut vous guider si vous utilisez un fournisseur externe sur Nano ; clés et sélecteurs viennent alors du fournisseur sortant.

Comment vérifier qu’un sélecteur DKIM fonctionne ?

Vérifiez que le DNS résout l’enregistrement, puis que les messages réels sont signés avec ce sélecteur et réussissent la vérification DKIM.

Commencez par interroger directement le DNS :

dig +short TXT tm1._domainkey.example.com
nslookup -type=TXT tm1._domainkey.example.com

Une réponse vide peut signaler un enregistrement absent, un nom incorrect, des caches non actualisés, un type de requête inadapté ou un autre problème de résolution. Vérifiez aussi les serveurs faisant autorité.

Envoyez ensuite un vrai message et examinez ses en-têtes :

Authentication-Results: mx.google.com;
 dkim=pass header.i=@example.com header.s=tm1 header.b=...
 spf=pass smtp.mailfrom=example.com;
 dmarc=pass header.from=example.com

Voici les résultats recherchés :

• dkim=pass
• header.s=tm1 correspond au sélecteur publié
• header.i décrit l’identité de la signature, tandis que d= est le domaine comparé à From pour l’alignement DKIM de DMARC

Si vous transférez souvent des messages, lisez aussi le transfert d’e-mails. SPF peut échouer après transfert. DKIM peut préserver l’authentification DMARC si le contenu signé reste intact et le domaine aligné, sans garantir la livraison.

Pourquoi un sélecteur DKIM échoue-t-il ?

Les causes habituelles sont un mauvais nom DNS, une clé mal formée, un expéditeur utilisant un autre sélecteur ou un relais modifiant le message après signature.

Voici les échecs que je rencontre le plus souvent en production.

1. Mauvais nom DNS. Vous avez publié _domainkey.tm1 au lieu de tm1._domainkey.
2. Mauvais domaine. Le message utilise d=mg.example.com, mais le sélecteur est publié sous example.com.
3. DNS incohérent. L’enregistrement existe sur des serveurs de noms qui ne font pas autorité.
4. Clé tronquée. Le panneau DNS a raccourci le TXT lors du copier-coller.
5. Ancien sélecteur toujours utilisé. La clé a été renouvelée, mais l’expéditeur signe encore avec l’ancien sélecteur.
6. Modification après signature. Un service de transfert ou une passerelle a changé des en-têtes protégés ou le corps.

Les consignes Google pour les expéditeurs avertissent que les messages en nombre ne respectant pas l’authentification peuvent être limités ou bloqués. Google note aussi que le transfert fait souvent échouer SPF : une signature DKIM vérifiable est importante, mais ne règle pas tous les facteurs de livraison.

Comment nommer un sélecteur DKIM ?

Il devrait être simple, stable et lié à un usage opérationnel. Un bon nom accélère le diagnostic en identifiant le responsable de la clé sans fouiller trois tableaux de bord.

Des noms comme default, key1 ou test fonctionnent, mais apportent peu de contexte avec le temps. Des modèles plus descriptifs :

• tm1 pour l’envoi géré par TrekMail
• ses2026q1 pour une rotation Amazon SES
• crm1 pour une plateforme CRM
• mktg2026a pour le marketing

Quand vous pouvez choisir les noms, répondez d’un coup d’œil à deux questions : qui gère la clé et quand a-t-elle été introduite ? Cela facilite les audits de nombreux domaines, notamment dans un hébergement de messagerie multidomaine.

Comment effectuer une rotation prudente ?

Publiez une nouvelle clé sous un nouveau sélecteur, basculez la signature, attendez la fin du transit des anciens messages, puis retirez l’ancien enregistrement.

N’écrasez pas une clé active sauf demande explicite du fournisseur. Une procédure plus prudente :

1. Créez un nouveau sélecteur, par exemple en passant de tm1 à tm2.
2. Publiez le nouvel enregistrement DNS.
3. Attendez qu’il soit visible dans le DNS.
4. Basculez l’expéditeur vers le nouveau sélecteur.
5. Envoyez des tests et confirmez dkim=pass avec ce sélecteur.
6. Gardez l’ancien enregistrement pendant une période tampon.
7. Retirez-le après confirmation qu’aucun système ne l’utilise et qu’aucun message en transit n’en a encore besoin.

C’est encore plus important avec plusieurs systèmes sortants. L’ancienne approche partage une clé durable partout en espérant que personne n’oublie ses usages. La nouvelle attribue un sélecteur par expéditeur, planifie la rotation et isole les changements.

Comment TrekMail gère-t-il le sélecteur DKIM ?

TrekMail affiche les enregistrements nécessaires, permet leur contrôle et prévoit envoi géré sur les forfaits payants et BYO SMTP sur Nano, selon les conditions actuelles. Cela peut réduire les incertitudes sur l’emplacement du sélecteur et l’état DNS.

Pour l’hébergement entrant et les boîtes, l’offre décrite comprend tableau de bord des domaines, stockage mutualisé, création par invitation, transfert et migration IMAP intégrée. Pour l’envoi, vous choisissez le modèle :

• Les forfaits payants peuvent utiliser TrekMail Managed SMTP, qui signe avec la clé DKIM de votre domaine.
• Nano utilise BYO SMTP : votre fournisseur sortant contrôle donc le sélecteur actif et la signature.

Cette distinction compte. Si le fournisseur externe signe, le sélecteur actif vient généralement de ses instructions DNS. Si TrekMail Managed SMTP signe, utilisez l’enregistrement DKIM du tableau de bord. L’offre décrite présente Starter à $3.50 par mois et un essai gratuit de 14 jours avec carte bancaire pour les forfaits payants. Nano est présenté comme gratuit, sans essai ; vérifiez les conditions actuelles. Pour le modèle forfaitaire sans frais par utilisateur, consultez les tarifs TrekMail.

Liste de diagnostic du sélecteur DKIM

Suivez une liste fixe : confirmez le sélecteur dans les en-têtes, l’enregistrement au nom DNS exact, son utilisation par l’expéditeur et l’absence de modification du contenu signé pendant le transport.

1. Examinez un message réellement reçu et notez s= et d=.
2. Interrogez directement selector._domainkey.domain dans le DNS.
3. Vérifiez les serveurs faisant autorité, pas seulement le panneau du registrar.
4. Confirmez si le fournisseur demande TXT ou CNAME.
5. Comparez From au domaine signataire pour l’alignement DMARC.
6. Retestez après les transferts, passerelles ou logiciels de listes si le message est modifié en transit.

Si le message direct réussit mais que le message transféré échoue, le problème peut venir d’une modification invalidant la signature plutôt que du sélecteur. Les consignes Google sur le transfert expliquent ce cas fréquent. Si vous transférez des messages, consultez aussi transférer la messagerie d’un domaine vers Gmail.

Conclusion : que retenir du sélecteur DKIM ?

C’est l’étiquette indiquant au destinataire quelle clé publique DKIM récupérer dans le DNS. Retenir cette phrase simplifie une grande partie du diagnostic.

Publier le bon sélecteur au bon nom et signer avec lui est nécessaire, mais les clés doivent aussi correspondre et le contenu signé être vérifié. En cas d’échec, examinez d’abord les en-têtes, puis le DNS, puis les modifications sur le chemin. Séparez les sélecteurs par expéditeur et renouvelez les clés avec de nouveaux noms plutôt que des modifications risquées en place. Pour simplifier la messagerie multidomaine, TrekMail propose hébergement, contrôles DNS, outils de migration et tarif forfaitaire sans frais par utilisateur, selon l’offre actuelle.