Outils populaires

Thème

Vérifier DKIM

Ce vérificateur DKIM lit les enregistrements DKIM d'un domaine comme les trouvent les serveurs de messagerie destinataires, ou teste la signature d'un e-mail collé : quels sélecteurs répondent, qui signe, quelle est la robustesse de chaque clé et si elle s'aligne sur DMARC.

Sources : 140 sélecteurs courants de 67 fournisseurs de messagerie, interrogés via Google Public DNS (Cloudflare derrière) · contrôles de clé des RFC 6376 et RFC 8301 · e-mails vérifiés dans votre navigateur · rien sur vous n'est enregistré

Interroge les 140 sélecteurs utilisés par les fournisseurs de messagerie à selector._domainkey. plus le domaine, car le DNS ne peut pas les lister

Essayer

Comment vérifier un enregistrement DKIM : DKIM lookup et dig

Saisissez le domaine ci-dessus : le vérificateur interroge les 140 sélecteurs qu'utilisent les fournisseurs de messagerie, affiche chaque clé trouvée avec sa taille et son fournisseur, et dit honnêtement quand il n'en trouve aucune. Vous connaissez le sélecteur ? Choisissez Domaine + sélecteur et il est vérifié en premier.

À la main, il vous faut le sélecteur, car le DNS ne peut pas les lister : dig +short TXT selector._domainkey.example.com, ou nslookup -type=TXT avec le même nom sous Windows. Le sélecteur est le s= de la DKIM-Signature de n'importe quel e-mail (RFC 6376 §3.6.2.1).

dig montre le texte, pas ce qu'il signifie : il ne décode pas la taille de la clé, ne suit pas le CNAME du fournisseur et ne distingue pas un emplacement de secours d'un enregistrement cassé. C'est ce qu'ajoute ce vérificateur d'enregistrement DKIM.

dig +short TXT selector._domainkey.example.com

Chaque chaîne TXT au nom : assemblez-les pour lire la clé.

Ce que dig montre, et ce qu'il ne montre pas

terminal

$ dig +short TXT 20251104._domainkey.google.com 1

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ…" "…k2A8ZfpQIDAQAB"2

$ dig +short TXT 20251104._domainkey.google.com | tr -d '" \n' | sed 's/.*p=//' | base64 -d | openssl pkey -pubin -inform DER -noout -text | head -1 3

Public-Key: (2048 bit)

$ dig +short TXT selector1._domainkey.microsoft.com 4

selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com.

  1. 1Le nom est selector._domainkey.domainePas de sélecteur, pas de réponse : le DNS n'a pas de « lister toutes les clés ».
  2. 2Deux chaînes, un enregistrementUne chaîne TXT contient 255 octets : une clé de 2048 bits est donc découpée ; les destinataires l'assemblent sans rien entre les morceaux.
  3. 3La taille réelle de la cléopenssl décode p= : 2048 bits, c'est ce que demande la RFC 8301.
  4. 4Un CNAME vers le fournisseurAucun TXT derrière : l'emplacement de secours de Microsoft 365, pas une erreur.
La clé de google.com et le selector1 de microsoft.com tels que Cloudflare DNS les a renvoyés le 25 octobre 2026.

Lire le résultat : le balayage des sélecteurs

La réponse vient d'abord, en une phrase. Dessous, qui signe et la clé elle-même, chaque tag coloré sur ses caractères exacts avec la taille de la clé sur l'échelle de la RFC 8301 ; sur fond bleu marine, chaque sélecteur interrogé, pour voir ce qui a été essayé.

Pas de note : une clé retirée ou le sélecteur de secours vide d'un fournisseur est normal, et « absente parmi les sélecteurs courants » ne veut jamais dire « pas de DKIM ».

Vérification DKIM de github.com : douze clés de six fournisseurs, le balayage des sélecteurs et l'indicateur de taille de cléVérification DKIM de github.com : douze clés de six fournisseurs, le balayage des sélecteurs et l'indicateur de taille de cléLe verdictUne phrase : combien de clés, et ce qu'il faut faire.Qui signeUne carte par fournisseur, trouvé par son CNAME ou un sélecteur documenté. Chaque pastille de sélecteur ouvre sa clé.La cléChaque tag coloré sur ses caractères, et la taille de la clé sur l'échelle de la RFC 8301.Le balayage des sélecteursChaque nom interrogé, allumé dès qu'il répond : vert une clé, ambre 1024 bits, en pointillé un emplacement de secours.Alignement DMARCSi une clé avec le d= de ce domaine s'aligne sur sa politique DMARC.
Une vérification DKIM de github.com : le verdict, qui signe, la clé découpée en tags avec sa taille et, sur fond bleu marine, chaque sélecteur interrogé. Sélectionnez un numéro pour voir ce que montre chaque partie.

Qu'est-ce que DKIM ?

DKIM (DomainKeys Identified Mail) est une signature qu'un serveur d'envoi ajoute à chaque message, et que les destinataires vérifient avec une clé publique que le domaine publie dans le DNS (RFC 6376). Une signature valide prouve deux choses : le domaine de d= l'a signée, et les parties signées n'ont pas changé depuis.

L'expéditeur hache le corps dans bh= et signe les en-têtes choisis plus ce hachage avec sa clé privée dans b=. Le destinataire lit d= et s=, récupère la clé à s._domainkey.d et refait les deux calculs. Un octet modifié dans le corps, ou dans un en-tête signé, et elle échoue.

DKIM ne dit rien de ce qu'il faut faire en cas d'échec, et n'importe quel domaine peut signer. C'est le rôle de DMARC : il exige une signature valide dont le d= correspond au domaine From:.

Un message, signé chez l'expéditeur et vérifié chez le destinataire

Le serveur de example.comsigne avec sa clé privée
le message, avec sa DKIM-Signature
Le destinataireGmail, Outlook.com, Yahoo…

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=dnsrobot-sample; h=from:from:to:subject:…; bh=fohb/a+auh1W9cUN…; b=fF0aMr3Uo+mbgG…

dnsrobot-sample._domainkey.example.com TXT?"v=DKIM1; k=rsa; p=MIIBIjANBgkq…"RSA 2048

Le message tel qu'envoyé

  • L'empreinte du corps correspond à bh=
  • La signature des en-têtes se vérifie

dkim=pass header.d=example.com

Le même message, son Subject modifié en route

  • L'empreinte du corps correspond à bh=
  • La signature des en-têtes ne se vérifie pas

dkim=fail (signature-mismatch)

Les deux résultats sont ceux du moteur, à partir de l'e-mail d'exemple de cette page et du même e-mail dont le Subject a été modifié après la signature. RFC 6376 §3.7, RFC 8301.

Qu'est-ce qu'un sélecteur DKIM, et comment trouver le mien ?

Un sélecteur est le nom d'une clé DKIM : le s= d'une signature, et le premier label du nom DNS où se trouve la clé (s1._domainkey.github.com). Un domaine peut en avoir autant qu'il veut : un par fournisseur, par serveur, par année (RFC 6376 §3.1).

Pour trouver le vôtre, ouvrez n'importe quel e-mail envoyé par le domaine et regardez l'original : dans Gmail, Plus (⋮) › Afficher l'original liste la DKIM-Signature, et son s= est le sélecteur. Ou collez l'e-mail dans Vérifier un e-mail ci-dessus.

La plupart des fournisseurs utilisent des noms fixes : un balayage les trouve. Amazon SES, Postmark, SparkPost et HubSpot génèrent un nom par compte, que seul un e-mail ou le tableau de bord du fournisseur vous donne.

De la signature à la clé, et les noms qu'utilisent les fournisseurs

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=s1; …

s1._domainkey.github.comCNAME s1.domainkey.u51742174.wl175.sendgrid.netRSA 2048

Google Workspacegooglel'administrateur peut changer le préfixe
Microsoft 365selector1 · selector2des CNAME vers le tenant ; un actif, un de secours
Twilio SendGrids1 · s2des CNAME vers u<id>.wl<n>.sendgrid.net
Mailchimpk2 · k3des CNAME vers dkim2/dkim3.mcsv.net
Fastmailfm1 · fm2 · fm3trois CNAME, un seul rempli à la fois
Proton Mailprotonmail · 2 · 3des CNAME vers domains.proton.ch
Amazon SES3 jetons aléatoires32 caractères aléatoires chacun : impossible à deviner
Postmark20240101000000pmune date et « pm » : impossible à deviner
SparkPostscph + MMYYscph et le mois de création de la clé
HubSpoths1-<HubID>votre numéro de compte
Le s1 de github.com tel que Cloudflare DNS l'a renvoyé le 25 octobre 2026. Noms des fournisseurs issus de leur propre documentation (67 fournisseurs, 140 sélecteurs dans le balayage).

Format d'un enregistrement DKIM : chaque tag expliqué

Un enregistrement DKIM est un enregistrement TXT de paires tag=valeur séparées par des points-virgules ; seul p=, la clé publique, est obligatoire. v=DKIM1 est facultatif mais, s'il est présent, doit venir en premier (RFC 6376 §3.6.1).

k= donne le type de clé (rsa sauf indication ed25519), t= porte des indicateurs (y test, s strict), h= limite les hachages et s= les services. Un p= vide révoque la clé exprès.

Les noms de tags respectent la casse, et un tag répété invalide l'enregistrement. Les tags inconnus sont ignorés.

L'enregistrement, tag par tag

v=DKIM1; k=rsa; t=s; h=sha256; p=MIIBIjANBgkqhkiG9w…IDAQAB

TagDéfinitValeursPar défautRemarque
v=VersionDKIM1DKIM1recommandé ; en premier s'il est présent
k=Type de clérsa · ed25519rsatypes inconnus : clé ignorée
p=Clé publique (base64)la clé, ou videobligatoirevide = révoquée
t=Indicateursy test · s strictaucuny : traité comme non signé
h=Hachages autoriséssha256 (sha1 interdit)toussha1 seul échoue (RFC 8301)
s=Type de service* · email*autres services seulement : ignoré
n=Notes pour les humainsn'importe quel texte–jamais lu par un logiciel

Quelle est la longueur de p=, et combien de chaînes TXT il faut

RSA 1024216 caractères · 1 chaîne TXT
RSA 2048392 caractères · 2 chaînes TXT
RSA 3072564 caractères · 3 chaînes TXT
RSA 4096736 caractères · 3 chaînes TXT
Ed2551944 caractères · 1 chaîne TXT

limites des chaînes TXT de 255 octets (en comptant « v=DKIM1; k=rsa; p= »)

Les longueurs de p= sont celles de clés SubjectPublicKeyInfo mesurées. yahoo.com publie sa clé de 2048 bits en 4 chaînes : n'importe quel découpage convient, puisque les destinataires les assemblent sans rien entre elles (RFC 6376 §3.6.2.2).

Clés DKIM de 1024 ou 2048 bits, et comment les renouveler

Utilisez du RSA 2048 bits. La RFC 8301 exige encore des vérificateurs qu'ils acceptent les clés de 1024 bits, mais demande aux signataires au moins 2048 et aux vérificateurs de rejeter les clés de moins de 1024 bits. M3AAWG qualifie 1024 bits « à la limite de l'attaque » et rapporte qu'une clé de 512 bits a été cassée en environ 72 heures pour environ 75 $.

Une clé Ed25519 est petite (44 caractères de p=) et, pour la rétrocompatibilité, la RFC 8463 permet aux signataires d'ajouter une signature RSA à côté : deux sélecteurs, deux signatures (RFC 8463).

Faites la rotation en publiant la nouvelle clé à un nouveau sélecteur, en basculant la signature, en gardant l'ancienne clé de 7 à 30 jours pour les e-mails en transit, puis en vidant son p=. M3AAWG suggère tous les six mois. Des fournisseurs comme Fastmail et Microsoft 365 s'en chargent pour vous grâce à des sélecteurs de secours.

Où se situent les vraies clés sur l'échelle de la RFC 8301

ÉchoueValide, passer à 2048BonnePeut échouer chez certains destinataires
  • microsoft.com · selector2
  • github.com · k1
  • google.com · 20251104
  • fastmail.com · fm2
  • archlinux.org · dkim-rsa
  • archlinux.org · dkim-ed25519 (Ed25519)

Rotation sans interruption (M3AAWG)

  1. Jour 0Publier la nouvelle clé à un nouveau sélecteur
  2. Jour 1+Basculer la signature dessus
  3. +7–30 joursGarder l'ancienne clé pour les e-mails en transit
  4. EnsuiteVider l'ancien p= ; ne pas réutiliser le nom
fastmail.comfm1p= videfm22 048fm3p= videtrois CNAME, un rempli : la rotation est un changement DNS côté Fastmail
Tailles de clé lues dans le DNS le 25 octobre 2026, décodées depuis chaque p=. RFC 8301 §3.2 ; M3AAWG DKIM Key Rotation Best Common Practices (2019).

Pourquoi DKIM échoue-t-il ? Empreinte du corps, transfert et listes de diffusion

DKIM échoue quand les octets signés ont changé, quand la clé est introuvable ou quand la clé ne correspond pas à la signature. Un transfert qui laisse le message inchangé laisse DKIM intact (contrairement à SPF) ; les listes de diffusion le cassent en général, car elles ajoutent des pieds de page ou étiquettent l'objet.

Le vérificateur de cette page contrôle séparément l'empreinte du corps et la signature des en-têtes : il peut donc distinguer un pied de page ajouté en route d'une falsification.

L'empreinte du corps ne s'est pas vérifiée

Une liste de diffusion a ajouté un pied de page de 153 octets. Les en-têtes se vérifient toujours avec la clé de project.example : ce n'est donc pas une falsification.

Solution Des listes qui gardent le corps intact, ou ARC (RFC 8617) pour que les destinataires suivants voient le résultat d'origine.

body-hash-mismatch

La signature ne s'est pas vérifiée

Un en-tête signé a changé après la signature (une liste qui ajoute son nom au Subject), ou le sélecteur contient maintenant une autre clé.

Solution Ne réécrivez pas les en-têtes signés ; publiez une nouvelle clé à un nouveau sélecteur plutôt que d'en remplacer une.

signature-mismatch

Aucune clé pour la signature

s=2023old._domainkey.shop.example est NXDOMAIN : le sélecteur a été supprimé alors que des e-mails signés avec lui étaient encore en transit.

Solution Gardez les anciennes clés publiées 7–30 jours après le changement ; videz p= plutôt que de supprimer.

key-not-found

Transfert : un transfert qui fait passer le message sans le modifier garde DKIM valide, ce qui explique que DMARC survive en général à un transfert grâce à DKIM même quand SPF échoue.

DKIM, SPF et DMARC : quelles différences ?

SPF dit quels serveurs peuvent envoyer pour un domaine, DKIM prouve qu'un domaine a signé le message et qu'il n'a pas été modifié, et DMARC relie les deux à l'adresse From: et dit quoi faire en cas d'échec.

Ils répondent à des questions différentes : il vous faut donc les trois. Gmail et Yahoo exigent SPF et DKIM des expéditeurs en masse, plus un enregistrement DMARC, et la RFC 9989 demande aux domaines à p=reject de signer avec DKIM plutôt que de s'appuyer sur SPF.

Trois enregistrements, trois questions

Trois enregistrements, trois questionsSPFDKIMDMARC
Ce qu'il prouveCe serveur peut envoyer pour le domaine MAIL FROMLe domaine d= a signé ; parties signées inchangéesFrom: correspond à un domaine qui a réussi SPF ou DKIM
Où il se trouveTXT à github.comTXT à s1._domainkey.github.comTXT à _dmarc.github.com
github.com aujourd'huiv=spf1 … ~all12 clés, 6 fournisseursp=quarantine; sp=reject
Survit au transfertNon : l'IP du serveur de transfert n'est pas listéeOui, si le message arrive inchangéOui, grâce à un succès DKIM aligné
Casse quandun nouveau service d'envoi n'est pas dans l'enregistrementle corps ou un en-tête signé changeaucun des deux ne réussit pour le domaine From:

Vérificateur d'Enregistrement SPFVérification DMARC

Les enregistrements de github.com tels que lus le 25 octobre 2026.

Comment lire l'en-tête DKIM-Signature d'un e-mail

Ouvrez le message d'origine et trouvez l'en-tête DKIM-Signature : d= est qui a signé, s= quelle clé, h= liste les en-têtes signés, et bh= et b= sont les deux hachages qu'un destinataire vérifie.

Le verdict du destinataire est un en-tête distinct ajouté à l'arrivée : Authentication-Results: … dkim=pass header.d=example.com header.s=dnsrobot-sample. La page « Afficher l'original » de Gmail (en anglais) le résume ainsi : « DKIM: 'PASS' with domain example.com ».

Un message peut porter plusieurs signatures, une par signataire (votre domaine et votre service de messagerie, ou une liste de diffusion). Une seule signature valide dont le d= correspond au domaine From: suffit pour DMARC.

La signature de l'e-mail d'exemple, tag par tag

v=11; a=rsa-sha2562; c=relaxed/relaxed3; d=example.com4; s=dnsrobot-sample5; t=17928331206; h=from:from:to:subject:date:message-id:mim…7; bh=fohb/a+auh1W9c…8; b=fF0aMr3Uo+mbgG…9

  1. 1Version v=toujours 1
  2. 2Algorithme a=rsa-sha256 (ou ed25519-sha256)
  3. 3Canonicalisation c=relaxed tolère un nouveau repliement
  4. 4Domaine de signature d=comparé à From: pour DMARC
  5. 5Sélecteur s=la clé à s._domainkey.d
  6. 6Signé à t=heure Unix : 24 oct. 2026, 09:12
  7. 7En-têtes signés h=from deux fois = sur-signé
  8. 8Empreinte du corps bh=SHA-256 du corps canonique
  9. 9Signature b=sur les en-têtes de h= et ce champ

Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=dnsrobot-sample

L'e-mail d'exemple fictif que charge cette page (example.com, une clé créée pour lui), vérifié par le moteur.

Vérificateur DKIM : questions fréquentes

Qu'est-ce qu'un enregistrement DKIM ?

Un enregistrement DKIM est un enregistrement TXT qui publie la clé publique d'un domaine à selector._domainkey.domaine, comme google._domainkey.example.com. Il contient des paires tag=valeur : p= est la clé en base64 et est obligatoire, k= le type de clé, t= des indicateurs. Les destinataires le récupèrent pour vérifier la DKIM-Signature des e-mails entrants. Un domaine peut en publier plusieurs, un par sélecteur, en général un par service d'envoi.

Comment trouver mon sélecteur DKIM ?

Ouvrez n'importe quel e-mail envoyé par le domaine, affichez le message d'origine et trouvez l'en-tête DKIM-Signature : la valeur après s= est le sélecteur, et d= le domaine. Dans Gmail, utilisez Plus (⋮) › Afficher l'original ; dans Outlook sur le web, View › View message source. Ou collez l'e-mail dans Vérifier un e-mail ci-dessus, qui lit s= et d= pour vous.

Pourquoi le vérificateur ne trouve-t-il aucune clé alors que mes e-mails sont signés ?

Parce que le DNS ne peut pas lister les sélecteurs : une clé ne se trouve qu'en demandant son nom exact. Le vérificateur interroge les 140 noms qu'utilisent les fournisseurs ; si votre domaine signe avec un autre (Amazon SES et Postmark en génèrent un par compte), le balayage ne le voit pas. Ajoutez le sélecteur du s= d'un e-mail et il est vérifié en premier, ou vérifiez plutôt un e-mail.

Une clé DKIM de 1024 bits est-elle encore acceptable ?

Elle fonctionne encore : la RFC 8301 exige des vérificateurs qu'ils acceptent les clés RSA de 1024 à 4096 bits, et Gmail et Yahoo fixent 1024 bits comme minimum. Mais la RFC 8301 demande aux signataires au moins 2048 bits, et M3AAWG qualifie 1024 à la limite de l'attaque. Prévoyez une rotation : Microsoft 365 et Google Workspace proposent tous deux des clés de 2048 bits. La RFC 8301 demande aux vérificateurs de rejeter les clés de moins de 1024 bits.

Que signifie un p= vide ?

Un p= vide signifie que la clé est révoquée : les signatures avec ce sélecteur échouent, exactement comme si la clé manquait. C'est en général voulu. Google garde ainsi ses anciens sélecteurs datés, et Fastmail et Microsoft 365 gardent des sélecteurs de secours vides pour y faire tourner la clé. Ce n'est un problème que s'il s'agit du sélecteur avec lequel vos e-mails sont signés aujourd'hui.

Que signifie t=y dans un enregistrement DKIM ?

t=y marque la clé comme étant en test : les destinataires doivent traiter un e-mail signé avec elle comme non signé, même quand la signature se vérifie. C'est prévu pour une première configuration, et souvent oublié. t=s est différent : il signifie strict, donc le i= des signatures doit être exactement le domaine de signature, pas un sous-domaine. Certains services de messagerie publient t=s sur leurs clés ; celles de SendGrid pour github.com l'ont.

Pourquoi DKIM échoue-t-il avec « body hash did not verify » ?

Le corps que le destinataire a haché ne correspond pas à la valeur bh= de la signature : le corps a donc changé après la signature. Les listes de diffusion qui ajoutent un pied de page, les passerelles de sécurité qui réécrivent les liens et les avertissements ajoutés par un serveur en sont la cause. Si la signature des en-têtes se vérifie encore, le message est authentique mais modifié ; le vérificateur de cette page contrôle les deux séparément.

DKIM survit-il au transfert d'e-mails ?

En général, oui. Un transfert qui fait passer le message sans le modifier garde la signature valide, car DKIM signe le contenu, pas le chemin. C'est la différence avec SPF, qui échoue à l'adresse IP du serveur de transfert. Les transferts qui modifient le message, comme les listes de diffusion qui ajoutent des pieds de page ou des étiquettes d'objet, cassent DKIM ; ARC leur permet de se porter garants du résultat d'origine.

Ai-je besoin de DKIM si j'ai déjà SPF ?

Oui. SPF casse quand les e-mails sont transférés et ne couvre que l'adresse MAIL FROM cachée, alors que DKIM survit au transfert et peut s'aligner sur le domaine From: que vérifie DMARC. Gmail et Yahoo exigent les deux des expéditeurs en masse, Outlook.com depuis mai 2025, et la RFC 9989 demande aux domaines à p=reject de signer leurs e-mails avec DKIM.

À quelle fréquence faut-il renouveler les clés DKIM ?

M3AAWG recommande au moins tous les six mois. Publiez la nouvelle clé à un nouveau sélecteur, basculez la signature dessus, gardez l'ancienne clé publiée de 7 à 30 jours pour que les e-mails en transit se vérifient encore, puis videz son p= au lieu de le supprimer. Ne réutilisez jamais un nom de sélecteur. Les fournisseurs hébergés qui utilisent des sélecteurs CNAME font la rotation des clés pour vous.

Mon e-mail est-il téléversé quand je le vérifie ici ?

Non. Ce validateur DKIM vérifie l'e-mail dans votre navigateur : le DNS public n'est interrogé que sur les noms des clés (s._domainkey.d), et dnsrobot.net uniquement sur la politique DMARC du domaine From et des domaines de signature. La seule exception est une signature Ed25519 qu'un navigateur ne peut pas vérifier : la page demande alors avant d'envoyer l'e-mail une fois à notre serveur, qui le vérifie en mémoire et ne stocke rien.

Puis-je utiliser une clé DKIM Ed25519 ?

Oui. La RFC 8463 la définit et exige des vérificateurs qu'ils la prennent en charge. Pour la rétrocompatibilité, publiez-la à son propre sélecteur à côté d'une clé RSA et signez chaque message deux fois, comme le fait archlinux.org avec dkim-ed25519 et dkim-rsa : les destinataires qui ne savent pas vérifier Ed25519 ont encore la signature RSA. Microsoft 365 et Google Workspace ne proposent que des clés RSA.

Outils e-mail et DNS associés