DKIM « No Key for Signature » : correctifs de sélecteur et de rotation (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

« No key for signature » signifie que le serveur de réception a interrogé l’enregistrement DNS visé par votre signature DKIM — selector._domainkey.yourdomain — et n’a trouvé aucune clé : elle n’a jamais été publiée, ou a été supprimée en pleine rotation. Publiez le sélecteur que votre signataire utilise réellement. Seuls 10 092 481 domaines — 3,87 % — complètent la triade SPF+DKIM+DMARC, selon le recensement Defaults.Exposed portant sur 261 086 232 domaines évalués.

Le correctif tient en un enregistrement DNS, trouvé dans un en-tête. Lisez les balises s= et d= d’un vrai en-tête DKIM-Signature pour savoir avec quel sélecteur votre courrier est signé, publiez (ou réparez) cet enregistrement exact, et préférez la délégation par CNAME pour que votre prestataire fasse tourner les clés à votre place. Puis faites la rotation selon le runbook ci-dessous — cette erreur signifie généralement que quelqu’un a supprimé un ancien sélecteur trop tôt.

Que signifie « dkim no key for signature » ?

Chaque signature DKIM porte deux balises indiquant au serveur de réception où récupérer la clé publique : d= (domaine de signature) et s= (sélecteur). Le serveur interroge un nom DNS construit à partir des deux — s._domainkey.d — pour obtenir la clé. « No key for signature » signifie que cette requête est revenue vide : la signature existe, mais la clé qu’elle nomme, non.

La formulation apparaît dans les en-têtes Authentication-Results et les rapports agrégés DMARC — le libellé exact varie selon le serveur de réception, mais deux variantes comptent :

Chaîne de résultat (fragment, tel qu’observé couramment)	Ce qui s’est réellement passé	Transitoire ?
`dkim=temperror (no key for signature)`	La requête DNS a échoué ou expiré — le serveur n’a pas pu obtenir de réponse du tout	Oui — les réessais passent souvent ; n’enquêtez que si c’est persistant
`dkim=permerror (no key for signature)`	La requête DNS a abouti et la réponse était « no such record » — le sélecteur est réellement absent	Non — l’enregistrement manque tant que vous ne le publiez pas

Un temperror isolé, c’est de la météo DNS. Un permerror — ou un temperror qui se répète sur plusieurs jours et serveurs — signifie que l’enregistrement visé par la signature n’est pas dans votre zone. C’est l’objet de ce guide.

La conséquence : une signature invérifiable compte comme une absence totale de DKIM, donc DMARC se rabat sur SPF seul — et SPF casse au transfert. Si la signature est présente mais invalide plutôt qu’absente (hash du corps, clé mutilée), c’est un autre échec — voir « DKIM signature not valid ».

Comment savoir avec quel sélecteur mon courrier est signé ?

Ne devinez pas d’après la documentation de votre prestataire — lisez-le dans un vrai message :

Envoyez un message depuis le système concerné vers une boîte que vous contrôlez (une adresse Gmail convient bien).
Ouvrez la source brute (« Afficher l’original » dans Gmail, « Afficher la source du message » dans Outlook).
Trouvez l’en-tête DKIM-Signature: et lisez deux balises : s= est le sélecteur, d= est le domaine de signature. Exemple illustratif : DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
L’enregistrement interrogé par le serveur de réception est s._domainkey.d — ici, mail2026._domainkey.yourdomain.com. Vérifiez-le vous-même : dig TXT mail2026._domainkey.yourdomain.com +short. Réponse vide = l’erreur est réelle pour tous les serveurs de réception.
Répétez pour chaque système émetteur. Un message peut porter plusieurs signatures DKIM — fournisseur de boîtes mail, outil de newsletter, helpdesk — chacune avec sa propre paire s=/d= et son enregistrement. Corrigez celle qui échoue, et notez son d= : seule une signature dont le d= correspond à votre domaine From aide DMARC.

Pourquoi l’enregistrement de sélecteur est-il absent ?

Quatre causes expliquent la quasi-totalité de ces erreurs — vérifiez-les dans cet ordre :

Il n’a jamais été publié. Le signataire a été activé (ou activé par défaut) avec un sélecteur que personne n’a ajouté au DNS. Fréquent avec les nouveaux outils et passerelles qui signent sans prévenir.
Il a été supprimé en pleine rotation. Quelqu’un a « fait le ménage » sur l’ancien sélecteur pendant que des messages signés avec lui étaient encore en transit, en file de réessai ou en attente de transfert. Ce courrier est déjà signé avec s=old ; supprimer old._domainkey casse rétroactivement chacun de ces messages.
Votre interface DNS a mutilé une cible CNAME. Beaucoup de prestataires délèguent via CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), et beaucoup de panneaux DNS ajoutent silencieusement votre zone à la cible — stockant s1.domainkey.u123.esp.com.yourdomain.com, qui ne se résout vers rien. Vérifiez la cible : dig CNAME s1._domainkey.yourdomain.com +short. Le même piège mord pendant les migrations d’outils — voir DKIM en échec après un changement d’outil e-mail.
Le prestataire a fait sa rotation, pas votre zone. Une clé de prestataire collée en enregistrement TXT statique (au lieu de ses CNAME) est orpheline dès sa rotation planifiée — le signataire passe à un sélecteur que vous n’avez jamais publié. Seuls 51,84 % des 261 millions de domaines du recensement présentent une clé DKIM découvrable au moment du scan (données au 2026-06-29).

Comment corriger « no key for signature » ?

Lancez le scan gratuit sur defaults.exposed avant de toucher au DNS. Il lit vos enregistrements DKIM, SPF et DMARC en direct et montre ce que les serveurs de réception voient réellement — y compris si le sélecteur se résout et si une cible CNAME a été mutilée.
Publiez le sélecteur que le signataire utilise réellement — la valeur s= de l’en-tête, pas celle d’un vieux runbook. Récupérez l’enregistrement dans la console d’administration de votre prestataire (configuration DKIM Google Workspace · configuration DKIM Microsoft 365) et ajoutez-le exactement à s._domainkey.yourdomain.com.
Préférez la délégation par CNAME au collage d’une clé TXT. Si votre prestataire propose des CNAME DKIM, utilisez-les : la clé vit dans sa zone, donc il la fait tourner sans que vous touchiez de nouveau au DNS — la cause 4 devient impossible. Les plateformes de newsletter fonctionnent presque toutes ainsi ; voir les e-mails Mailchimp/Brevo/Klaviyo échouent à DMARC.
Vérifiez depuis l’extérieur de votre panneau. dig TXT s._domainkey.yourdomain.com +short (ou dig CNAME … pour les sélecteurs délégués) depuis une machine hors de votre réseau. Que le panneau affiche l’enregistrement ne prouve rien si la zone sert autre chose.
Relancez le scan et renvoyez le message de test. Authentication-Results doit désormais afficher dkim=pass. Puis traitez tout ce que le scan signale d’autre sur la page corriger DKIM — une signature qui passe mais ne s’aligne pas avec votre domaine From échoue quand même à DMARC.

Comment faire tourner les clés DKIM sans provoquer cette erreur ?

La rotation est là où les configurations qui marchaient cassent. La règle qui l’évite : un sélecteur ne se supprime qu’une fois le dernier message signé avec lui écoulé — jamais à la bascule. Le courrier signé vit plus longtemps qu’on ne croit : les files de réessai courent des jours, et les messages transférés sont revérifiés à chaque déplacement.

Étape	Action	Condition avant l’étape suivante
1. Ajouter	Publiez le nouveau sélecteur (`s2._domainkey…`) à côté de l’ancien	`dig` confirme qu’il se résout depuis l’extérieur
2. Basculer	Pointez le signataire vers le nouveau sélecteur	Le message de test montre `s=s2` et `dkim=pass`
3. Attendre	Laissez l’ancien sélecteur publié pendant l’écoulement du trafic en transit, en file et transféré	≥ 7 jours ; surveillez les rapports agrégés DMARC jusqu’à disparition de l’ancien sélecteur
4. Retirer	Supprimez l’ancienne clé — ou mieux, republiez-la avec une balise `p=` vide : « retirée », pas « jamais existé »	Ne commencez jamais ceci à la bascule — la suppression prématurée est la cause n° 1 de « no key for signature »

Avec la délégation par CNAME, votre prestataire exécute exactement ce runbook dans sa propre zone et vous ne le voyez jamais — l’argument le plus fort en faveur de la délégation.

Questions fréquentes

« No key for signature », c’est un temperror ou un permerror ? Les deux chaînes existent : temperror est une requête DNS qui a échoué ou expiré — transitoire, souvent disparue au réessai — tandis que permerror signifie que le DNS a répondu « no such record ». Un temperror qui se répète chez plusieurs serveurs de réception se révèle généralement être lui aussi un enregistrement réellement absent. Vérifiez avec dig et fiez-vous à la réponse, pas à l’étiquette.

Cette erreur signifie-t-elle que quelqu’un usurpe mon domaine ? Non — un usurpateur ne signerait pas avec votre sélecteur. Elle signifie que votre propre courrier porte une signature que les serveurs de réception ne peuvent pas vérifier ; il compte donc comme non signé et DMARC s’appuie sur SPF seul. L’authentification complète et alignée est rare : seuls 10 092 481 des 261 086 232 domaines (3,87 %) complétaient la triade SPF+DKIM+DMARC dans le recensement Defaults.Exposed (données au 2026-06-29).

Puis-je simplement supprimer l’ancien sélecteur une fois que le nouveau fonctionne ? Pas immédiatement. Des messages signés avec lui sont encore dans les files de réessai et les chemins de transfert ; supprimer la clé les casse rétroactivement. Gardez l’ancien enregistrement au moins une semaine, surveillez vos rapports DMARC jusqu’à disparition de l’ancien sélecteur, puis retirez-le — idéalement avec un p= vide plutôt qu’une suppression.

Le vérificateur de mon prestataire dit que DKIM est configuré, mais les serveurs de réception signalent encore l’absence de clé. Comment ? Presque toujours le piège de la cible CNAME : votre panneau DNS a ajouté votre zone à la cible (…esp.com.yourdomain.com), donc l’enregistrement existe mais ne pointe vers rien. dig CNAME selector._domainkey.yourdomain.com +short montre la cible stockée telle quelle — comparez-la caractère par caractère avec ce que le prestataire demandait.

Envoyez le rapport au propriétaire

Si vous corrigez ceci pour un client ou votre employeur, bouclez la boucle avec des preuves. Relancez le scan gratuit une fois le sélecteur résolu et transmettez le rapport noté au chef d’entreprise : daté, en langage clair, DKIM qui vérifie désormais. C’est la pièce dont il aura besoin au renouvellement de la cyberassurance et au prochain questionnaire de sécurité fournisseur — la preuve d’un contrôle qui fonctionne, pas seulement un ticket fermé.

Vérifiez votre DKIM gratuitement

Voyez si vos sélecteurs se résolvent — et exactement quoi corriger — en privé, visible du propriétaire uniquement.

Vérifiez votre domaine → · « DKIM signature not valid » → · Corriger DKIM → · Configurer DKIM sur Google Workspace → · Données agrégées uniquement. Données stockées et traitées dans l’UE.