Faire un DKIM check : du sélecteur au verdict

Un DKIM check consiste à lire les tags s= (sélecteur) et d= (domaine) dans l'en-tête DKIM-Signature d'un message, puis à interroger l'enregistrement TXT publié sous selecteur._domainkey.domaine pour contrôler la clé publique. Le verdict réel, lui, se lit dans l'en-tête Authentication-Results ajouté par le serveur destinataire : dkim=pass signifie que le corps et les en-têtes signés n'ont pas bougé pendant le transport.

Sommaire

Deux contrôles différents portent le même nom

Deux outils qui s'appellent tous les deux « DKIM checker » ne font pas le même travail. Le premier demande un domaine et un sélecteur, interroge le DNS, et vous dit si l'enregistrement existe, s'il est syntaxiquement valide et quelle taille fait la clé. Le second veut un message complet, ou vous fait envoyer un mail à une adresse jetable, puis rejoue le calcul cryptographique : il recalcule le hachage du corps, le compare au tag bh=, et vérifie la signature b= sur les seuls en-têtes listés dans h=.

Seul le second répond à la question qui vous intéresse. Un enregistrement DKIM impeccable ne prouve rien sur ce que signe réellement votre serveur sortant. Si vous avez régénéré une paire de clés sur le MTA sans republier la partie publique, le contrôle DNS reste vert et vos mails partent en dkim=fail. Le DNS ment par omission.

Commencez donc par un vrai message. Le DNS sert ensuite à expliquer l'échec, rarement à le détecter.

Le sélecteur ne se devine pas

Le DNS ne sait pas lister les sélecteurs d'un domaine. Il n'existe ni joker ni requête d'énumération sous _domainkey : on ne peut interroger qu'un nom exact. Un outil qui annonce « aucun enregistrement DKIM trouvé » a donc peut-être seulement essayé les mauvais noms, en piochant dans une liste de sélecteurs populaires.

La source fiable, c'est un message réellement expédié par le domaine. Ouvrez son en-tête DKIM-Signature et lisez deux tags : s= donne le sélecteur, d= donne le domaine signataire. Dans Gmail, passez par « Afficher l'original » ; dans Outlook, par Fichier, Propriétés, En-têtes Internet. Vous obtenez par exemple s=google; d=exemple.fr, ce qui donne directement la requête à lancer : dig +short TXT google._domainkey.exemple.fr

Si la réponse commence par un alias, ne vous arrêtez pas là. Beaucoup de prestataires publient un CNAME pour pouvoir changer la clé sans vous prévenir ; dig +short affiche alors l'alias puis le TXT final, et c'est ce TXT qu'il faut lire. Les valeurs ci-dessous changent au fil des migrations de ces prestataires, elles servent de point de départ, pas de référence.

Service d'envoi	Sélecteur publié	Forme de l'enregistrement
Google Workspace	google	TXT
Microsoft 365	selector1 et selector2	CNAME vers le tenant onmicrosoft.com
Amazon SES (Easy DKIM)	trois jetons alphanumériques	CNAME vers dkim.amazonses.com
SendGrid	s1 et s2	CNAME
Mailchimp	k1	CNAME vers dkim.mcsv.net

Lire l’enregistrement TXT tag par tag

L'enregistrement tient sur une ligne, sous la forme v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... Ce préfixe MIIBIjANBgkq est la signature visuelle d'une clé RSA de 2048 bits encodée en DER puis en base64 ; une clé de 1024 bits commence par MIGfMA0GCSq.

La taille se mesure au lieu de se supposer. Reprenez la valeur de p= dans une variable P, puis : { echo "-----BEGIN PUBLIC KEY-----"; echo "$P" | fold -w64; echo "-----END PUBLIC KEY-----"; } | openssl pkey -pubin -text -noout | head -1 qui répond Public-Key: (2048 bit). La RFC 8301 interdit aux vérificateurs de valider une signature reposant sur une clé RSA de moins de 1024 bits, recommande 2048, et écarte l'algorithme rsa-sha1 qu'on croise encore dans de vieilles configurations OpenDKIM.

Le découpage est le piège le plus fréquent. Une chaîne de caractères TXT est plafonnée à 255 octets par la RFC 1035, or la partie p= d'une clé 2048 bits fait 392 caractères. L'enregistrement doit donc être publié en plusieurs chaînes entre guillemets, que le résolveur recolle. Certains panneaux d'hébergement le font seuls, d'autres tronquent sans rien dire. Les clés Ed25519 de la RFC 8463 échappent au problème : 44 caractères, une seule chaîne.

Tag	Rôle	Comportement par défaut
v	Version, doit valoir DKIM1 et arriver en premier	toléré s'il est absent
k	Type de clé, rsa ou ed25519	rsa
p	Clé publique en base64	obligatoire ; vide = clé révoquée
h	Algorithmes de hachage acceptés	tous
t	Drapeaux : y pour le mode test, s pour exclure les sous-domaines	aucun drapeau
s	Types de service couverts	* (tous)

Le verdict est dans Authentication-Results

Le serveur destinataire écrit sa conclusion dans un en-tête normalisé par la RFC 8601, du genre : Authentication-Results: mx.google.com; dkim=pass header.i=@exemple.fr header.s=google header.b=Xk3nQ1Zt; spf=pass; dmarc=pass. C'est la seule pièce qui compte, parce qu'elle vient de la machine qui a fait la vérification.

header.s vous rend le sélecteur employé, header.i ou header.d le domaine signataire, header.b les premiers octets de la signature, pratique quand un message porte plusieurs DKIM-Signature. Quand ça casse, Gmail précise la cause entre parenthèses ; la plus courante reste dkim=fail (body hash did not verify), autrement dit le corps du message a été modifié après la signature.

Résultat	Ce qui s'est passé	Où chercher
none	Aucune signature DKIM dans le message	la configuration du MTA sortant, pas le DNS
pass	Signature valide pour le domaine d=	l'alignement avec le From si DMARC échoue quand même
fail	Signature présente mais invalide	le corps modifié en transit, ou une clé désynchronisée
temperror	Échec temporaire, en général le DNS n'a pas répondu	les délais et les échecs du résolveur
permerror	Signature ou clé inexploitable	le TXT, souvent un découpage cassé ou un tag manquant

DKIM, SPF et DMARC ne posent pas la même question

La confusion classique consiste à voir SPF et DKIM comme deux versions du même contrôle. SPF regarde l'adresse IP qui se connecte et la confronte au domaine de l'enveloppe. DKIM se moque de l'IP et vérifie une signature portée par le message lui-même, définie par la RFC 6376.

D'où des comportements opposés en pratique. Un transfert automatique casse SPF, puisque l'IP émettrice change, mais laisse DKIM intact. Une liste de diffusion qui ajoute un pied de page fait exactement l'inverse : le corps bouge, le hachage bh= ne correspond plus, la signature tombe alors que SPF passe. C'est pour ce cas que la RFC 8617 a introduit ARC.

DMARC arbitre entre les deux. Il demande qu'au moins un des mécanismes passe et que le domaine vérifié soit aligné avec le From affiché à l'utilisateur. Le résultat qui surprend le plus vient de là : dkim=pass et dmarc=fail sur le même message, parce que le d= de la signature porte le domaine de votre routeur d'emails et pas le vôtre.

Critère	SPF	DKIM
Objet du contrôle	l'IP du serveur émetteur	une signature cryptographique du message
Identité vérifiée	domaine du MAIL FROM (enveloppe)	domaine du tag d= de la signature
Résiste à un transfert	non, l'IP change	oui, si le contenu ne bouge pas
Résiste à un pied de page ajouté	oui, sans rapport	non, le body hash change
Emplacement DNS	TXT à la racine du domaine	TXT sous selecteur._domainkey

Les pannes que le check fait remonter

Quand la configuration est « faite » mais que le contrôle échoue, l'explication est presque toujours dans cette liste.

Le nom a été saisi dans un panneau qui ajoute déjà le domaine, et l'enregistrement réel s'appelle selecteur._domainkey.exemple.fr.exemple.fr. Un dig sur le nom complet le montre en deux secondes.
Le TXT est coupé à 255 caractères : la clé se lit correctement au début, plus du tout à la fin, et le destinataire renvoie permerror.
p= est vide. Ce n'est pas un bug mais une révocation explicite, souvent le reste d'une rotation de clé où le sélecteur n'a pas été supprimé.
t=y traîne encore après la migration. Le drapeau demande aux destinataires de traiter un échec comme une absence de signature : le problème est masqué, pas résolu.
Le MTA ajoute un tag l= à ses signatures, qui limite la couverture aux N premiers octets du corps. N'importe qui peut alors coller du texte sous une signature qui reste valide.

Questions fréquentes

Peut-on vérifier DKIM sans envoyer de mail ?

Oui, mais partiellement. Avec le sélecteur, dig +short TXT selecteur._domainkey.exemple.fr vous donne la clé publique, sa taille et ses drapeaux. Ce contrôle ne dit rien de ce que signe votre serveur sortant : il valide la moitié réceptrice de la chaîne. Pour la moitié émettrice, il faut un message réel et son en-tête Authentication-Results.

Pourquoi un outil dit « no DKIM record found » alors que le DNS est bon ?

Trois causes dominent. L'outil a testé des sélecteurs génériques (default, mail, dkim) au lieu du vôtre. Ou l'enregistrement est un CNAME que l'outil ne suit pas. Ou le nom publié comporte le domaine en double à cause du panneau d'hébergement. Lancez le dig vous-même sur le nom complet, réponse sans ambiguïté.

Quelle taille de clé publier aujourd’hui ?

2048 bits en RSA. La RFC 8301 rend invalide toute signature sous 1024 bits et recommande 2048 ; 1024 est encore accepté par les vérificateurs mais n'a plus de raison d'être. Ed25519 (RFC 8463) donne une clé de 44 caractères qui tient dans une seule chaîne TXT, mais tous les vérificateurs ne la traitent pas, donc on publie généralement les deux en parallèle sur deux sélecteurs.

dkim=pass et le message part quand même en spam, pourquoi ?

DKIM prouve une origine et une intégrité, pas une réputation. Une signature valide sur un domaine inconnu ou signalé ne change rien au filtrage. Vérifiez d'abord l'alignement DMARC (le d= correspond-il au From visible), puis la réputation de l'IP et du domaine, puis le contenu.

À quelle fréquence changer la clé DKIM ?

La RFC 6376 ne fixe aucune durée. L'usage courant tourne autour de deux rotations par an, avec la même méthode : publier un nouveau sélecteur, attendre la propagation, basculer la signature dessus, et laisser l'ancien enregistrement en place quelques jours pour les messages déjà partis. Supprimer l'ancien sélecteur trop vite fait échouer les vérifications tardives.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Où lit-on le sélecteur utilisé pour signer un message ?