Defaults.Exposed › Corrections › Guides

« DKIM Signature Not Valid » — les causes, dans l'ordre où les vérifier (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.

« DKIM signature not valid » a cinq causes courantes, à vérifier dans l’ordre : contenu modifié en transit, enregistrement de clé tronqué, clé publiée qui ne correspond pas au signataire, mauvais sélecteur, et canonicalisation fragile. Seuls 10 092 481 des 261 086 232 domaines évalués (3,87 %) détiennent la triade complète SPF + DKIM + politique DMARC appliquée, selon le recensement Defaults.Exposed (2026-06-29).

L’ordre de correction compte, car la cause la plus fréquente ne se trouve pas du tout dans votre DNS. Vérifiez d’abord ce qui a modifié le message en transit, puis remontez vers l’intérieur : l’intégrité de l’enregistrement de clé, sa correspondance avec ce que votre serveur de messagerie signe réellement, le sélecteur, et enfin les réglages de signature. La plupart des signatures invalides se corrigent à l’étape un ou deux.

Que signifie réellement « DKIM signature not valid » ?

Chaque message signé DKIM porte un en-tête DKIM-Signature qui nomme un domaine (d=), un sélecteur (s=), un hash du corps du message (bh=), et une signature cryptographique sur le hash du corps plus certains en-têtes (b=). Le serveur de réception récupère votre clé publique dans le DNS à <selector>._domainkey.<domain>, recalcule les deux hashs, et vérifie la signature (RFC 6376). « Signature not valid », dans le langage des outils de vérification et des en-têtes, veut dire : cette vérification a eu lieu et a échoué — la clé a été trouvée, mais le calcul n’est pas tombé juste.

Cette dernière précision est de l’or pour le diagnostic. Un vérificateur qui ne peut pas trouver votre clé dit autre chose — typiquement un en-tête du type dkim=fail (no key for signature) — et c’est un problème de sélecteur, couvert dans DKIM « no key for signature » — correctifs de sélecteur et de rotation. Et un vérificateur qui recalcule un hash de corps différent le dit généralement explicitement : body hash did not verify — Microsoft le signale comme dkim=fail (body hash did not verify), tandis que Gmail rend souvent le même diagnostic en dkim=neutral (body hash did not verify). Dans les deux cas, cela pointe vers une modification du contenu, couverte dans « body hash did not verify » — ce qui a modifié votre message. Lisez le libellé exact dans l’en-tête Authentication-Results avant de toucher à quoi que ce soit : il vous dit laquelle des cinq causes vous tenez.

Réussir tout cela est rare : seuls 51,84 % des domaines évalués publient une clé DKIM détectable dans le DNS, selon le recensement Defaults.Exposed, et seuls 3,87 % des 261 millions de domaines évalués combinent SPF, DKIM et une politique DMARC appliquée — la configuration que les règles pour expéditeurs en masse présupposent désormais. Le panorama étape par étape se trouve dans le modèle de maturité d’adoption SPF.

Quelles sont les cinq causes, dans l’ordre ?

La cause 1 est en gras parce qu’elle casse des signatures de messages signés parfaitement. Une passerelle de sécurité ajoute une mention légale, un pied de page de conformité est apposé après la signature, une liste de diffusion ajoute [listname] au sujet — le corps ou les en-têtes signés changent, les hashs ne correspondent plus, et la signature est invalide sans que votre DNS y soit pour rien. Si les échecs coïncident avec du courrier passé par une passerelle, une liste ou un relais d’archivage, commencez là.

Comment corriger « DKIM signature not valid » ?

1. Lancez le scan gratuit sur defaults.exposed avant de toucher au DNS. Il montre si votre enregistrement de clé publié est présent, bien formé et complet — séparant « votre DNS est cassé » (causes 2 à 4) de « votre DNS va bien, le message est modifié » (cause 1) en une seule étape.
2. Lisez l’en-tête Authentication-Results d’un message en échec. body hash did not verify → cause 1, allez au guide body-hash — les suspects habituels sont les pieds de page de passerelle et les mentions légales, et le correctif est de signer après la modification. no key for signature → cause 4, allez au guide sélecteur. Un simple échec de signature → continuez.
3. Vérifiez que la clé publiée n’est pas tronquée. Interrogez <selector>._domainkey.<yourdomain> en TXT (dig TXT selector._domainkey.example.com). Une clé publique RSA 2048 bits dépasse la limite de 255 caractères d’une chaîne TXT unique : elle doit donc être publiée en plusieurs chaînes entre guillemets que les serveurs de réception concatènent — et les interfaces web des prestataires DNS sont réputées pour tronquer silencieusement le collage, mutiler le découpage, ou injecter espaces et guillemets dans la valeur p=. Comparez caractère par caractère avec la clé générée par votre signataire ; nos guides pas à pas de configuration DKIM couvrent les particularités par prestataire.
4. Confirmez que la clé publiée correspond au signataire. Après une rotation de clé, une migration de prestataire ou une reconnexion d’ESP, il est courant que le signataire détienne une nouvelle clé privée pendant que le DNS sert encore l’ancienne clé publique — chaque signature est vérifiée contre la mauvaise clé et échoue. Recopiez l’enregistrement actuel depuis la console d’administration de votre prestataire. Mieux : là où le prestataire propose la délégation par CNAME, utilisez-la — le prestataire fait tourner les clés de son côté et toute cette classe d’échecs disparaît. Et ne supprimez jamais un ancien sélecteur avant que le trafic signé avec lui ne se soit tari.
5. Corrigez les réglages de signature, pas seulement l’enregistrement. Passez la canonicalisation en c=relaxed/relaxed, qui tolère le rehabillage des espaces et le repliage des en-têtes que les serveurs intermédiaires font légitimement ; la canonicalisation simple échoue sur des changements qu’un humain ne peut même pas voir. Et n’utilisez pas le tag de longueur de corps l= : il était censé laisser passer les pieds de page, mais il permet à n’importe qui d’ajouter du contenu à votre message signé sans casser la signature — un vrai vecteur d’attaque — et il ne survit de toute façon pas à la plupart des modifications de passerelle. Pas de l=, c’est à la fois le choix le plus sûr et le plus fiable.
6. Relancez le scan, puis vérifiez l’alignement. Une signature valide n’aide DMARC que si le domaine d= s’aligne avec votre domaine From — une signature qui se valide en d=yourcompany.gappssmtp.com passe DKIM et échoue quand même à DMARC. Si c’est votre cas, voir le piège de la signature par défaut, puis traitez tout ce que le scan signale d’autre sur la page corriger DKIM.

Questions fréquentes

« DKIM signature not valid » est-il la même chose que « body hash did not verify » ? Le message body-hash est un sous-cas spécifique : le corps a changé après la signature (pieds de page, mentions légales, réécritures de liste). « Signature not valid » est le verdict générique de toute vérification échouée, y compris mauvaises clés et changements d’en-têtes — c’est pourquoi l’étape 2 ci-dessus consiste à lire l’en-tête, et pourquoi le cas body-hash a son propre guide.

Une signature DKIM invalide signifie-t-elle que mon courrier est rejeté ? Pas en soi — les serveurs de réception traitent une signature cassée comme une signature absente. Le dégât arrive via DMARC : si SPF ne passe pas non plus avec alignement, le message échoue à DMARC et votre politique publiée s’applique. Au recensement du 2026-06-29, seuls 3,87 % des 261 086 232 domaines évalués détiennent ensemble SPF, DKIM et une politique DMARC appliquée — mais Gmail et Microsoft attendent désormais exactement cela des expéditeurs, donc une jambe DKIM cassée coûte en délivrabilité avant même le rejet.

Dois-je utiliser une clé DKIM de 1024 ou de 2048 bits ? 2048 bits — les clés 1024 bits sont en dessous des recommandations cryptographiques actuelles et certains serveurs de réception les pénalisent. Le piège est purement opérationnel : une clé 2048 bits ne tient pas dans une seule chaîne TXT de 255 caractères, elle doit donc être découpée correctement (cause 2 ci-dessus). La délégation par CNAME vers votre prestataire contourne entièrement le problème du découpage.

Mon DKIM passe sur un outil de vérification mais DMARC échoue encore — comment ? Presque certainement l’alignement : la signature se valide, mais son domaine d= (disons yourcompany.gappssmtp.com ou yourtenant.onmicrosoft.com) ne correspond pas à votre domaine From, donc DMARC ne peut pas s’en servir. Activez la signature en domaine personnalisé de votre prestataire — le parcours complet est dans le guide du piège de la signature par défaut.

Puis-je simplement désactiver DKIM s’il continue d’échouer ? Non — depuis les exigences 2024 pour expéditeurs en masse, Gmail et Yahoo imposent DKIM aux expéditeurs à volume, et une politique DMARC appliquée a réalistement besoin de DKIM parce que SPF seul casse au transfert. Corrigez la signature ; les causes ci-dessus se règlent toutes en une après-midi.

Envoyez le rapport au propriétaire

Si vous corrigez cela pour un client ou votre employeur, bouclez la boucle avec une preuve. Relancez le scan gratuit après vos modifications et transmettez le rapport noté au chef d’entreprise : daté, en langage clair, DKIM au vert. C’est la pièce dont il aura besoin pour le renouvellement de la cyberassurance et le prochain questionnaire de sécurité fournisseurs — la différence entre « j’ai corrigé un truc DNS » et un avant-après documenté qui atteste que le domaine authentifie son courrier.

Vérifiez votre domaine → · Guide « Body hash did not verify » → · Corriger DKIM → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.