Le DKIM expliqué

Comment fonctionne la signature DKIM, ce qu'est un sélecteur, pourquoi elle survit au transfert contrairement au SPF, et ce qui casse une signature.

Ce qu’est le DKIM

Le DKIM, DomainKeys Identified Mail (RFC 6376), attache une signature numérique à chaque message que vous envoyez. Le serveur de réception récupère votre clé publique dans le DNS, vérifie la signature et en déduit deux choses : votre domaine a autorisé ce message, et les parties signées n’ont pas été modifiées en chemin.

Là où le SPF autorise un serveur, le DKIM autorise un message. C’est cette différence qui rend les deux nécessaires.

Comment ça fonctionne

Quand Mailverick envoie votre email, il calcule une empreinte du corps et d’une série d’en-têtes, puis la signe avec une clé privée. Le résultat voyage avec le message dans un en-tête DKIM-Signature, qui ressemble à ceci :

DKIM-Signature: v=1; a=rsa-sha256; d=votredomaine.com; s=mv1;
  h=from:to:subject:date; bh=<empreinte du corps>; b=<signature>

Les deux balises qui vous concernent :

Le serveur de réception les combine en une requête DNS sur <selecteur>._domainkey.<domaine>, récupère la clé publique et vérifie la signature. Le sélecteur existe pour qu’un même domaine puisse héberger plusieurs clés en parallèle, ce qui rend la rotation possible sans interruption.

Pourquoi le DKIM survit au transfert

Une vérification SPF échoue dès qu’un message est relayé par un serveur que vous n’avez jamais autorisé, ce qui est exactement le cas d’un transfert automatique. Le DKIM, lui, ne s’intéresse pas au serveur qui a livré le message, seulement au fait que le contenu correspond toujours à la signature.

Un message transféré continue donc de s’authentifier. Une politique DMARC qui rejetterait ce courrier transféré passe grâce au DKIM seul.

C’est la principale raison de ne pas traiter le DKIM comme optionnel une fois le SPF en place.

Comment le configurer

1. Récupérez l’enregistrement auprès de votre plateforme. La clé est générée pour vous, vous ne manipulez jamais la partie privée.
2. Créez un enregistrement TXT dont le nom est le sélecteur complet, par exemple mv1._domainkey.votredomaine.com. Certaines interfaces DNS ajoutent automatiquement votre domaine : saisir le nom complet produit alors un domaine dupliqué. Vérifiez ce qu’affiche l’hébergeur après enregistrement.
3. Collez la valeur exactement, y compris v=DKIM1; k=rsa; p=. Elle est longue, et une clé tronquée échoue silencieusement.
4. Vérifiez, puis envoyez un message de test et inspectez ses en-têtes à la recherche de dkim=pass.

Avec Mailverick

Mailverick génère la paire de clés à l’ajout d’un domaine et affiche l’enregistrement TXT exact dans la section Domaines du portail, avec la procédure complète dans Démarrage. La génération et la rotation des clés sont prises en charge pour vous.

Le SPF et le DKIM doivent tous deux être valides avant que le domaine puisse envoyer. Vérifier le DNS indique ce qui a été trouvé face à ce qui était attendu : une clé tronquée ou déformée devient visible au lieu de rester un mystère.

Erreurs fréquentes

Créer un CNAME au lieu d’un TXT. Certaines plateformes fournissent le DKIM sous forme de CNAME pointant vers leur propre zone. Mailverick publie la clé directement, le type d’enregistrement est donc TXT. Créer le mauvais type laisse le DKIM non vérifié, sans erreur ailleurs que dans la vérification DNS.

Laisser l’hébergeur dupliquer le domaine. Saisir mv1._domainkey.votredomaine.com dans une interface qui ajoute déjà la zone produit mv1._domainkey.votredomaine.com.votredomaine.com. Relisez toujours l’enregistrement enregistré.

Tronquer la clé. Une clé publique DKIM dépasse la limite de 255 caractères d’une chaîne TXT. Elle doit être découpée en plusieurs chaînes entre guillemets dans un même enregistrement, ce que la plupart des hébergeurs font automatiquement. Un collage dans une interface qui coupe silencieusement la valeur donne un enregistrement qui existe et ne se vérifie jamais.

Signer avec le mauvais domaine. Si un outil tiers signe avec son propre domaine dans d=, le DKIM passe mais ne s’aligne pas avec votre domaine From:. Le DMARC échoue donc quand même. C’est l’alignement, et pas seulement une signature valide, que le DMARC vérifie.

Attendre qu’une signature survive à une modification. Les listes de diffusion qui ajoutent un pied de page ou réécrivent le sujet cassent l’empreinte du corps, et le DKIM échoue ensuite. C’est la signature qui fonctionne comme prévu, pas une erreur de configuration.

Conserver une clé de 1024 bits. 2048 bits est l’attente actuelle. Si vous avez hérité d’une clé courte d’une ancienne configuration, remplacez-la.

Questions fréquentes

Le DKIM chiffre-t-il mes emails ?

Non, il les signe. N’importe qui peut lire un message signé en DKIM ; la signature prouve seulement l’origine et l’intégrité. Le chiffrement en transit, c’est TLS, un mécanisme distinct.

Qu’est-ce qu’un sélecteur, et puis-je le choisir ?

Un sélecteur est simplement une étiquette qui désigne une clé précise dans votre DNS, ce qui permet à un domaine d’en héberger plusieurs à la fois. Mailverick en attribue un et vous n’avez pas à le gérer.

Ai-je encore besoin du SPF si le DKIM fonctionne ?

Oui. Les grands fournisseurs attendent les deux, et chacun couvre un cas que l’autre manque : le SPF autorise le serveur qui se connecte, le DKIM autorise le message et survit au transfert.

Pourquoi le DKIM passe-t-il alors que le DMARC échoue ?

Presque toujours l’alignement. Le domaine signataire dans d= doit correspondre au domaine de votre en-tête From: visible. Une signature valide provenant d’un domaine sans lien ne donne rien d’exploitable au DMARC.

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

Tous les six à douze mois est un rythme raisonnable, et Mailverick s’en charge. La rotation est sans risque car l’ancien et le nouveau sélecteur peuvent être publiés en même temps : les messages déjà envoyés se vérifient toujours.

Dernière mise à jour : mai 2026