Vérificateur d’enregistrement DKIM

Vérifiez les clés DKIM d’un domaine : saisissez le sélecteur que vous utilisez, ou laissez le vérificateur essayer les plus courants, et voyez le type et la taille de chaque clé, si elle est révoquée et ce qui ne va pas dans l’enregistrement.

Les requêtes DNS partent directement de votre navigateur vers des résolveurs publics (Cloudflare, Google) : nous ne voyons rien.

Ce que vérifie le vérificateur DKIM

Le sélecteur que vous indiquez: Les clés DKIM sont publiées à <sélecteur>._domainkey.<domaine>. Indiquez le sélecteur trouvé dans le s= d’un en-tête DKIM-Signature : le vérificateur lit cet enregistrement précis, ou vous dit qu’il n’existe pas.
Les sélecteurs courants: Une trentaine de sélecteurs utilisés par Google Workspace, Microsoft 365, Mailchimp, Proton, Zendesk, OVHcloud et d’autres sont aussi essayés. On ne peut pas lister les sélecteurs : n’en trouver aucun ici ne prouve pas qu’il n’y en a pas.
Type et taille de la clé: Les clés RSA de moins de 1024 bits sont refusées par la plupart des destinataires, et 2048 bits est la norme aujourd’hui. Les clés Ed25519 sont courtes par nature (256 bits) et solides.
Les clés révoquées: Un p= vide signifie que la clé a été retirée exprès : tout message encore signé avec elle échoue à DKIM.
La syntaxe de l’enregistrement: v= doit valoir DKIM1 s’il est présent, k= rsa ou ed25519, et p= le base64 d’une vraie clé. Un enregistrement qui n’autorise que SHA-1 (h=sha1) n’est plus accepté, et t=y signale une clé en mode test.

Comment lire le résultat

Vert : une clé valide: Le sélecteur publie une clé RSA de 2048 bits ou plus, ou une clé Ed25519. Les messages signés avec elle peuvent passer DKIM.
Orange : faible ou incertain: Une clé de 1024 bits, SHA-1 seulement, le mode test, ou aucune clé sur les sélecteurs courants. Indiquez votre propre sélecteur pour en avoir le cœur net.
Rouge : cassé: Le sélecteur indiqué n’a pas d’enregistrement, ou sa clé est illisible : chaque message signé avec lui échoue à DKIM.
Le tableau des clés: Chaque sélecteur trouvé, le type, la taille et l’état de sa clé. Ouvrez un sélecteur pour voir son enregistrement complet, tel que le reçoivent les destinataires.

Erreurs DKIM fréquentes et leur correction

Les échecs DKIM apparaissent dans l’en-tête Authentication-Results d’un e-mail reçu et dans les journaux des serveurs de messagerie. Voici les plus courants, ce qu’ils veulent dire et ce qu’il faut changer.

`No DKIM record found for selector`

Pourquoi. La signature désigne un sélecteur qui n’a pas d’enregistrement dans le DNS. Les destinataires l’écrivent « dkim=neutral (no key for signature) » ou « dkim=permerror (no key for signature) ». Les enregistrements du fournisseur n’ont jamais été ajoutés, l’ont été dans la mauvaise zone, ou le fournisseur est passé à un nouveau sélecteur.

Correction. Copiez les enregistrements depuis la console du fournisseur (souvent deux CNAME, comme selector1 et selector2 pour Microsoft 365), vérifiez-les ici avec ce sélecteur, puis activez la signature.

`DKIM signature failed`

Pourquoi. La clé est trouvée, mais la signature ne se vérifie pas : « dkim=fail (signature did not verify) », ou « dkim=neutral (body hash did not verify) » quand le message a été modifié après la signature, par exemple par le pied de page d’une liste de diffusion ou une passerelle de sécurité. Cela arrive aussi quand la clé publiée ne correspond plus à la clé privée.

Correction. Si tous vos e-mails échouent, republiez la clé depuis le fournisseur : un enregistrement tronqué au copier-coller est fréquent. Si seuls les e-mails transférés ou de listes échouent, c’est normal ; DMARC peut encore passer par SPF pour les envois directs.

`dkim=pass but dmarc=fail`

Pourquoi. Le message est signé, mais par le domaine du fournisseur (d=sendgrid.net, d=mailchimpapp.net) et non par le vôtre. DKIM réussit, mais n’est pas aligné avec l’adresse From : DMARC échoue.

Correction. Configurez l’authentification de domaine chez le fournisseur (parfois appelée domaine personnalisé), pour qu’il signe avec d=votre domaine.

`DKIM key too short`

Pourquoi. La clé fait 1024 bits ou moins. En dessous de 1024 bits, elle est refusée ; 1024 bits passe encore, mais reste sous les recommandations actuelles.

Correction. Générez une clé de 2048 bits chez votre fournisseur, publiez-la sous un nouveau sélecteur, basculez la signature dessus, puis révoquez l’ancienne en vidant son p=.

`DKIM public key invalid`

Pourquoi. La valeur de p= n’est pas du base64 valide ou pas une clé entière : des guillemets ou des espaces à l’intérieur, un retour à la ligne, ou une valeur longue coupée à 255 caractères.

Correction. Collez la clé d’un seul tenant. Une valeur TXT de plus de 255 caractères doit être découpée en plusieurs chaînes entre guillemets, jamais tronquée ; la plupart des interfaces DNS le font seules.

Questions

Comment trouver mon sélecteur DKIM ?

Ouvrez un message que vous avez envoyé, affichez l’original ou les en-têtes, et cherchez DKIM-Signature : le sélecteur est la valeur de s=, le domaine signataire celle de d=. Notre analyseur d’en-têtes d’e-mail les lit pour vous.

Pourquoi le vérificateur ne trouve-t-il pas ma clé DKIM ?

Chaque fournisseur choisit ses sélecteurs et on ne peut pas les lister. Si le vôtre ne fait pas partie des plus courants, le vérificateur ne peut pas le deviner : saisissez-le dans le champ du sélecteur.

Clé DKIM de 1024 ou de 2048 bits ?

2048. Les clés de 1024 bits passent encore chez la plupart des destinataires mais sont sous les recommandations actuelles, et plus court est refusé. Si votre hébergeur DNS gère mal les longs enregistrements, ajoutez une clé Ed25519 à côté d’une clé RSA.

Comment changer de clé DKIM ?

Publiez la nouvelle clé sous un nouveau sélecteur, faites signer le fournisseur avec elle, attendez quelques jours pour les messages en transit, puis révoquez l’ancienne en la publiant avec un p= vide.

Quelque chose est-il envoyé à vos serveurs ?

Non. Les requêtes partent de votre navigateur vers des résolveurs DNS-over-HTTPS publics (Cloudflare, puis Google) : nous ne voyons rien.