DKIM est le seul mécanisme d’authentification du courriel sans convention de nommage standard. SPF vit dans le TXT racine. DMARC vit à _dmarc.<domaine>. DKIM vit à <sélecteur>._domainkey.<domaine> — et le sélecteur peut être littéralement n’importe quoi que l’expéditeur a choisi. Quand vous héritez d’un domaine et devez vérifier que son DKIM est intact, ou qu’un expéditeur tiers jure avoir publié une clé sans vous donner le sélecteur, vous pouvez passer un après-midi à deviner, ou laisser le DKIM Selector Probe de PortJar essayer les candidats évidents en quelques secondes.
Ce que fait l’outil
Il prend un domaine et sonde 24 sélecteurs DKIM courants contre lui — ceux par défaut utilisés par Google Workspace, Microsoft 365, Mailgun, SendGrid, Postmark, Zoho, ProtonMail, Mailchimp, Amazon SES, et d’autres expéditeurs de masse. Pour chacun, il essaie <sélecteur>._domainkey.<domaine> et rapporte lesquels retournent un enregistrement DKIM TXT valide. Si vous connaissez le sélecteur à vérifier (depuis un en-tête DKIM-Signature trouvé dans un message), vous pouvez sonder uniquement celui-là.
Comment l’utiliser
Ouvrez portjar.com/tools/dkim-lookup, entrez le domaine, et laissez-le balayer la liste de sélecteurs courants ou fournissez un sélecteur précis à vérifier directement. Pour trouver le sélecteur d’un expéditeur donné, regardez le paramètre s= dans l’en-tête DKIM-Signature d’un message réel qu’il a envoyé — c’est la réponse qui fait foi. La sonde est utile quand vous n’avez pas de message d’exemple sous la main.
Quand l’utiliser
- Prise en charge d’un nouveau client dont l’opérateur précédent n’a laissé aucune documentation. Le client sait qu’il « a DKIM configuré quelque part », mais le cahier de procédures est muet et l’ancien administrateur injoignable. Un balayage des sélecteurs courants trouve généralement les enregistrements vivants en moins d’une minute.
- Vérifier qu’un nouveau service d’envoi a vraiment publié sa clé. Quand vous avez activé DKIM dans le tableau de bord Postmark ou SendGrid et ajouté les enregistrements par l’API DNS, la sonde confirme que les enregistrements se résolvent correctement avant de basculer le courriel de production.
- Enquêter sur un échec DKIM. Le guide de dépannage PortJar sur les échecs DKIM liste les quatre causes courantes : sélecteur manquant, désaccord de clé publique, dérive de canonisation d’en-têtes, et modification du message en transit. La sonde distingue « sélecteur manquant » des trois autres en une requête — si l’enregistrement n’est sincèrement pas là, le reste du diagnostic se simplifie.
- Auditer un domaine pour du shadow IT. La sonde trouve parfois un sélecteur inattendu —
mandrill._domainkey.example.com,smtpapi._domainkey.example.com— pointant vers un expéditeur que personne dans l’équipe actuelle n’a configuré. C’est une observation : quelqu’un, à un moment, a donné à un service la permission de signer au nom de votre domaine, et vous devez décider de le garder actif ou de le révoquer. - Confirmer une rotation de clé. Quand vous tournez les clés DKIM, vous faites typiquement coexister l’ancien et le nouveau sélecteur 48 heures pour que le courriel en vol signé avec l’ancienne clé valide encore. La sonde confirme que les deux sélecteurs sont vivants pendant le chevauchement et permet de vérifier que l’ancien est parti une fois la fenêtre de bascule close.
Quoi faire du résultat
Une sonde qui ne trouve rien ne veut pas forcément dire que DKIM n’est pas configuré — ça veut dire qu’aucun des sélecteurs courants n’est utilisé. Vérifiez l’en-tête DKIM-Signature sur un message sortant réel ; la valeur s= nomme le sélecteur. Une fois trouvé, fournissez-le à la sonde directement pour confirmer l’enregistrement. Une sonde qui trouve plusieurs sélecteurs est normale pour tout domaine qui utilise plus d’un expéditeur : Google Workspace, un service transactionnel et un outil marketing auront typiquement chacun leur propre sélecteur actif simultanément. Un résultat de sonde qui montre un enregistrement TXT publié avec le champ de clé tronqué ou vide (p= sans valeur) veut dire que la clé a été révoquée au niveau DNS — l’enregistrement existe encore pour la rétrocompatibilité mais n’authentifie plus rien, état courant après une rotation pas entièrement nettoyée.
Pour les environnements où la rotation DKIM, l’hygiène des sélecteurs et l’inventaire des expéditeurs doivent rester à jour sur plusieurs domaines, Stack Harbor gère cette discipline dans le cadre de la gestion cPanel/WHM.