Trouver le sélecteur DKIM d'un domaine

Dernière mise à jour : 4 novembre 2026

Vous voulez vérifier la configuration DKIM d'un domaine, et vous butez sur une difficulté qui surprend : il est impossible de demander au DNS quels sélecteurs existent.

Ce n'est pas une limite des outils, c'est une propriété du protocole. Et elle explique pourquoi tous les vérificateurs DKIM, sans exception, vous demandent de saisir le sélecteur à la main : ou le devinent.

Pourquoi on ne peut pas les lister

Une clé DKIM se publie à l'adresse <sélecteur>._domainkey.<domaine>. Par exemple google._domainkey.exemple.fr.

Le DNS répond parfaitement à « que contient ce nom précis ? ». Il ne sait pas répondre à « quels noms existent sous _domainkey ? ». Il n'existe aucun mécanisme d'énumération : pas de liste, pas d'index, pas de jokers exploitables pour cela.

Conséquence directe : pour lire une clé DKIM, il faut connaître son nom à l'avance. Un domaine peut parfaitement avoir une clé DKIM valide et active sans qu'aucun outil extérieur ne puisse la trouver.

Méthode 1 : Lire un message réellement reçu

C'est la seule méthode certaine à cent pour cent, et la plus rapide quand c'est possible.

Récupérez un message envoyé par le domaine, affichez sa source complète (dans Gmail, « Afficher l'original » ; dans Outlook, « Propriétés du message ») et cherchez l'en-tête DKIM-Signature. Vous y trouverez :

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
            d=exemple.fr; s=selector1; t=1762243200;

Le s= est le sélecteur, le d= le domaine signataire. Vous pouvez alors interroger directement selector1._domainkey.exemple.fr.

Un détail qui compte : vérifiez que d= correspond bien au domaine affiché dans le champ De :. Si le message vient de facture@exemple.fr mais que la signature porte d=prestataire.com, DKIM ne s'aligne pas et DMARC échouera sur ce mécanisme.

Méthode 2 : Essayer les sélecteurs par défaut

La plupart des services utilisent des sélecteurs prévisibles. C'est ce que fait Radar DNS, qui teste une trentaine de sélecteurs courants à chaque analyse. Voici les principaux.

Service	Sélecteurs
Google Workspace	`google`
Microsoft 365	`selector1`, `selector2`
SendGrid	`s1`, `s2`
Mailchimp	`k1`, `k2`, `k3`
Mandrill	`mandrill`
Brevo	`mail`
Mailjet	`mailjet`
Postmark	`pm`
Zoho	`zoho`
Fastmail	`fm1`, `fm2`, `fm3`
Proton Mail	`protonmail`, `protonmail2`
HubSpot	`hs1`, `hs2`
Constant Contact	`ctct1`, `ctct2`
Amazon SES	trois jetons aléatoires

Deux cas rendent cette méthode inopérante. Amazon SES génère des sélecteurs aléatoires, impossibles à deviner. Et de nombreux services permettent de choisir un sélecteur personnalisé, souvent daté : mars2026, cle-2, le nom de l'entreprise.

L'absence de résultat ne prouve donc jamais l'absence de DKIM. C'est une nuance importante à garder en tête quand un outil annonce « aucun DKIM trouvé ».

Méthode 3 : Regarder la configuration à la source

Si le domaine vous appartient, inutile de deviner : le sélecteur est affiché dans l'interface de votre prestataire.

Google Workspace : console d'administration, Applications, Google Workspace, Gmail, Authentifier le courrier.
Microsoft 365 : portail Defender, Politiques, DKIM. Microsoft publie deux CNAME, selector1 et selector2, qui pointent vers son infrastructure.
Prestataires d'emailing : rubrique « authentification de domaine », « domain authentication » ou « sender authentication ».

Le piège des deux grandes suites

Un point mérite d'être souligné, parce qu'il touche énormément de domaines : ni Google Workspace ni Microsoft 365 n'activent DKIM par défaut sur un domaine personnalisé.

Tant que vous ne l'avez pas explicitement généré et publié, vos messages sont signés avec le domaine du fournisseur, pas le vôtre. Techniquement il y a bien une signature DKIM : mais le d= ne correspond pas à votre domaine, donc l'alignement DMARC échoue sur ce mécanisme.

Le symptôme est déroutant : tout semble configuré, DKIM apparaît valide dans les en-têtes, et pourtant DMARC ne passe que par SPF. Or SPF casse dès qu'un message est transféré. Vérifiez ce point en priorité.

Deux vérifications à faire une fois le sélecteur trouvé

La taille de la clé

Les clés de 1024 bits sont en dessous de l'état de l'art ; 2048 bits est le minimum attendu aujourd'hui. Google Workspace crée encore des clés 1024 par défaut dans certains parcours : il faut choisir explicitement 2048 au moment de la génération.

Attention : c'est la clé la plus faible qui compte, pas la plus forte. Une clé 1024 encore publiée reste utilisable pour forger une signature, même si une clé 2048 existe à côté. Les vieux sélecteurs abandonnés sont donc à supprimer, pas seulement à ignorer. PayPal, par exemple, publie une clé 2048 sur s1 et une clé 1024 sur s2.

Les clés révoquées

Un enregistrement DKIM dont le p= est vide signifie « cette clé est révoquée ». C'est la manière propre de retirer une clé sans supprimer l'enregistrement. Si vous en trouvez une qui ne correspond à aucun service actif, l'enregistrement peut être supprimé.

Ce que fait Radar DNS

L'analyse teste une trentaine de sélecteurs courants, affiche pour chacun la taille réelle de la clé, signale les clés révoquées, et surtout résout la cible des CNAME. C'est ce dernier point qui est utile pour identifier un prestataire : un sélecteur s1._domainkey pointant vers s1.domainkey.uXXXXX.wlYYY.sendgrid.net désigne sans ambiguïté SendGrid, même quand le domaine ne publie ni MX ni SPF.