Tester DKIM : la clé publiée, puis la signature reçue

Tester DKIM recouvre deux vérifications distinctes : la clé publique publiée dans le DNS sous selecteur._domainkey.votredomaine.fr, et la signature réellement portée par un message qui a voyagé. La première prend trois secondes avec dig, la seconde exige un envoi réel, parce qu'une clé valide dans le DNS ne prouve pas que votre serveur signe quoi que ce soit.

Sommaire

Ce que « tester DKIM » recouvre vraiment

Deux personnes qui cherchent un test DKIM ne cherchent pas la même chose. Celle qui vient de coller un enregistrement TXT dans son panneau DNS veut savoir si la publication est correcte. Celle dont les messages tombent en spam veut savoir si les messages sortants sont signés, et si la signature survit au trajet. Le premier test porte sur le DNS, le second sur un message.

L'ordre compte. Un enregistrement TXT impeccable ne signe rien du tout : la signature est apposée à l'envoi par le serveur qui détient la clé privée (Postfix avec OpenDKIM, Exchange Online, SendGrid, Amazon SES). Tant que ce côté-là n'est pas configuré, dig vous renverra une clé parfaite et vos messages partiront sans le moindre en-tête DKIM-Signature. C'est la panne la plus fréquente après une migration : la clé a été publiée, le signeur n'a jamais été activé.

Test 1 : lire la clé publique avec dig

La clé vit dans un enregistrement TXT à l'adresse ._domainkey.. Le sélecteur est un nom libre choisi par le signeur, ce qui permet d'avoir plusieurs clés en parallèle. Exemple sur un domaine hébergé chez Google Workspace : `dig +short TXT google._domainkey.exemple.fr`. La réponse commence par `"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."`.

Une clé RSA 2048 bits produit un champ p= d'environ 392 caractères en base64. Or une chaîne TXT est plafonnée à 255 octets par la RFC 1035 : le serveur de noms la découpe et dig renvoie plusieurs blocs entre guillemets, qui doivent être concaténés sans espace ni retour ligne. Si le panneau DNS a glissé un espace à la jointure, la clé est invalide alors qu'elle s'affiche correctement à l'écran. C'est la cause numéro un des dkim=neutral inexplicables.

Pour contrôler la taille réelle de la clé, collez la valeur de p= dans un fichier cle.b64 puis lancez `base64 -d cle.b64 | openssl pkey -pubin -inform DER -noout -text | head -1`. La sortie attendue est `Public-Key: (2048 bit)`. Si openssl refuse le fichier, le base64 est tronqué ou pollué. Côté serveur, avec OpenDKIM, `opendkim-testkey -d exemple.fr -s google -vvv` compare la clé privée du disque à celle publiée : « key OK » signifie que la paire correspond, tandis que « key not secure » signale seulement l'absence de DNSSEC et n'est pas bloquant.

Un dernier détail que peu de panneaux expliquent : un tag p= vide révoque le sélecteur. C'est la manière propre de retirer une clé sans supprimer l'enregistrement.

Tag	Rôle	Valeur attendue
v	Version, doit apparaître en premier	DKIM1
k	Type de clé	rsa, ou ed25519 depuis la RFC 8463
p	Clé publique en base64 (DER SubjectPublicKeyInfo)	MIIBIjANBgkq...
h	Algorithmes de hachage acceptés	sha256
t	Drapeaux : y = mode test, s = pas de sous-domaines	absent en production
s	Types de service couverts	email, ou * par défaut
n	Note libre destinée à l'administrateur	peu utilisé

Test 2 : la signature sur un message réellement reçu

Envoyez un message depuis le domaine à tester vers une boîte que vous contrôlez chez un autre opérateur, puis ouvrez la source du message. Dans Gmail, menu du message, « Afficher l'original ». Deux en-têtes vous intéressent.

Le premier est posé par le serveur destinataire : `Authentication-Results: mx.google.com; dkim=pass header.i=@exemple.fr header.s=google header.b=Qr7dK2vX; spf=pass ...`. Le second est posé par l'expéditeur : `DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=exemple.fr; s=google; bh=47DEQpj8HBSa...; h=from:to:subject:date:message-id; b=...`. Le tag s= vous donne le sélecteur à interroger avec dig, le tag d= le domaine signataire, bh le condensat du corps et h la liste des en-têtes couverts.

Regardez cette liste h= de près. La RFC 6376 impose que From y figure ; s'il manque, la signature ne protège pas l'expéditeur affiché. Subject, Date et Message-ID sont couramment ajoutés. Plus la liste est longue, plus la signature casse facilement en transit, notamment si une passerelle réécrit le sujet.

Les services d'auto-réponse type check-auth@verifier.port25.com ou les testeurs web renvoient le même diagnostic sous forme lisible, avec SPF et DMARC en prime. Leur limite : ils testent le trajet vers eux, pas vers Gmail ou Outlook, et ne voient rien des messages qui partent d'une autre plateforme de votre parc.

Résultat dkim=	Signification	Où chercher
pass	Signature vérifiée avec la clé publiée	Contrôler ensuite l'alignement DMARC
fail	Signature présente mais invalide	Corps ou en-têtes modifiés, clé dépareillée
none	Aucune signature dans le message	Le serveur d'envoi ne signe pas
neutral	Signature illisible, syntaxe cassée	Tags manquants, base64 tronqué
policy	Signature écartée par la politique du vérificateur	Clé trop courte, algorithme refusé
temperror	Erreur DNS temporaire	Retenter, vérifier les serveurs de noms
permerror	Enregistrement absent ou inexploitable	Sélecteur non publié

Les échecs qu’on rencontre en vrai

Un test DKIM raté raconte presque toujours la même poignée d'histoires. Savoir laquelle évite de régénérer une clé pour rien.

« body hash did not verify » : le corps a changé après signature. Une liste de diffusion qui ajoute un pied de page, une passerelle antivirus qui réencode en quoted-printable, un lien réécrit par un outil de protection suffisent.
« signature did not verify » sans erreur de bh : c'est un en-tête listé dans h= qui a bougé. Le préfixe [EXTERNE] ajouté au sujet par certaines passerelles est le coupable classique.
Le tag t=y resté en place après la mise en production : il déclare la clé en mode test, et la RFC 6376 demande alors aux vérificateurs de ne pas traiter le message différemment d'un message non signé. Vous obtenez des pass qui ne construisent aucune réputation.
a=rsa-sha1 ou clé de 1024 bits héritées d'une vieille configuration : la RFC 8301 interdit SHA-1 et fixe le minimum à 1024 bits, 2048 étant la valeur recommandée. Les clés 512 bits qu'on croise encore sont cassables.
Un tag l= dans la signature : il limite le nombre d'octets du corps réellement couverts, ce qui permet d'ajouter du contenu sous la partie signée sans invalider la vérification. À retirer de la configuration du signeur.

Un pass qui ne compte pas : l’alignement avec DMARC

C'est la confusion la plus coûteuse. Un dkim=pass isolé ne suffit pas à DMARC : la RFC 7489 exige que le domaine du tag d= soit aligné avec le domaine du From affiché. En mode relaxed (adkim=r, valeur par défaut), le domaine organisationnel suffit, donc d=mail.exemple.fr aligne avec From: contact@exemple.fr. En mode strict (adkim=s), la correspondance doit être exacte.

Le cas typique : un routeur d'emailing signe avec d=sendgrid.net alors que le From affiche votredomaine.fr. La signature est mathématiquement valide, dkim=pass s'affiche, et DMARC échoue quand même sur le volet DKIM. La correction ne touche pas au signeur mais au DNS : publier les enregistrements fournis par le prestataire sous votre propre domaine (s1._domainkey et s2._domainkey chez SendGrid, trois CNAME générés chez Amazon SES, selector1 et selector2 chez Microsoft 365) pour qu'il signe avec votre domaine.

Vérifiez donc toujours deux choses dans le même en-tête : le résultat dkim=, et la valeur de header.d comparée au From. Un rapport DMARC agrégé le dira aussi, avec quelques jours de retard.

Questions fréquentes

Comment trouver le sélecteur DKIM d’un domaine ?

Le DNS ne permet pas de les énumérer : _domainkey n'accepte aucune requête de liste et aucun sélecteur n'est imposé par la norme. La méthode fiable consiste à récupérer un message signé par ce domaine et à lire le tag s= de son en-tête DKIM-Signature. À défaut, testez les sélecteurs par défaut des grandes plateformes : google pour Google Workspace, selector1 et selector2 pour Microsoft 365, s1 et s2 pour SendGrid, k1 pour Mailchimp. Amazon SES génère des sélecteurs aléatoires, indevinables.

Peut-on tester DKIM sans envoyer de message ?

Partiellement. dig valide la publication, la syntaxe et la taille de la clé. opendkim-testkey valide la correspondance entre la clé privée du serveur et la clé publiée. Aucun des deux ne prouve que votre serveur appose effectivement la signature sur les messages sortants, ni qu'elle survit aux relais. Pour ça, il faut un envoi réel vers une boîte externe.

Faut-il une clé de 1024 ou de 2048 bits ?

2048. La RFC 8301 fixe le plancher à 1024 bits et recommande 2048, les vérificateurs devant accepter jusqu'à 4096. Sachez qu'à partir de 2048 bits la clé publique dépasse les 255 octets d'une chaîne TXT unique et doit être découpée : certains panneaux DNS le font mal, ce qui explique une partie des tests qui échouent juste après une montée en taille de clé.

Pourquoi la signature casse-t-elle après un passage par une liste de diffusion ?

Parce que le gestionnaire de liste modifie le message avant de le redistribuer : pied de page ajouté, sujet préfixé du nom de la liste, parfois réencodage du corps. Le condensat bh ou la signature d'en-tête ne correspond plus. Le mécanisme prévu pour ce cas est ARC (RFC 8617), qui conserve la trace des résultats d'authentification avant modification, mais sa prise en compte dépend du destinataire.

Faut-il un enregistrement DKIM par plateforme d’envoi ?

Oui, un sélecteur par source, et c'est sans risque : DKIM n'a pas la limite de 10 résolutions DNS que la RFC 7208 impose à SPF. Vous pouvez publier autant de sélecteurs que vous avez d'outils. C'est aussi le principe de la rotation de clé : on publie la nouvelle sous un second sélecteur, on bascule le signeur, on laisse expirer le TTL et les messages en transit, puis on vide l'ancien avec un p= vide.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Où se trouve la clé publique DKIM d'un domaine ?