Tous les services opérationnels Devise EUR Aucun frais de mise en service Vous êtes à La Réunion ?
Espace client
Se connecter
‹ Messagerie

DKIM : signer vos e-mails, pas à pas

DKIM (DomainKeys Identified Mail) ajoute à chaque message envoyé une signature, calculée avec une clé privée que garde le serveur d'envoi. La clé publique correspondante est publiée dans le DNS de votre domaine, sous un nom appelé sélecteur. La messagerie du destinataire la lit, vérifie la signature, et sait ainsi que le message vient bien de votre domaine et n'a pas été modifié en route.

Par Jonathan Dewaele · publié le

DKIM est défini par la RFC 6376, relue le 14 octobre 2026.

Comment fonctionne la signature

Au départ, le serveur d'envoi calcule une empreinte de certaines parties du message, dont le corps, l'objet et l'expéditeur, et la chiffre avec sa clé privée. Il ajoute le résultat dans un en-tête DKIM-Signature, que vous pouvez lire dans la source de n'importe quel message reçu. Deux de ses champs servent à retrouver la clé :

  • d= donne le domaine qui signe, par exemple exemple.fr ;
  • s= donne le sélecteur, par exemple default.

La messagerie du destinataire va alors chercher un enregistrement TXT au nom default._domainkey.exemple.fr, en assemblant le sélecteur, le mot _domainkey et le domaine. Elle y trouve la clé publique, vérifie la signature, et note le résultat : dkim=pass si tout concorde, dkim=fail si le message a été altéré ou si la clé publiée ne correspond plus.

Un domaine peut avoir plusieurs sélecteurs, donc plusieurs clés : une par service qui envoie en son nom. Ils ne se gênent pas.

L'enregistrement à publier

Il ressemble à ceci, la clé étant ici raccourcie :

default._domainkey.exemple.fr.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
  • v=DKIM1 annonce un enregistrement DKIM.
  • k=rsa donne le type de clé, RSA par défaut.
  • p= porte la clé publique elle-même, une longue suite de caractères. Une valeur vide signifie que la clé a été révoquée.

La RFC 6376 impose des clés RSA d'au moins 1 024 bits ; Google, dans ses consignes aux expéditeurs, conseille 2 048 bits quand le fournisseur le permet. Vous n'avez pas à choisir la clé vous-même : c'est le serveur d'envoi qui la génère, et vous recopiez sa partie publique.

Activer DKIM pour une messagerie Hubspace

Notre serveur signe avec le sélecteur default. La signature est activée domaine par domaine, et tous les domaines ne l'ont pas encore. Votre zone DNS étant presque toujours ailleurs que chez nous, chez Netim, Cloudflare ou votre ancien bureau d'enregistrement, c'est vous qui y publiez la clé.

  1. Vérifiez si votre domaine publie déjà une clé. Une réponse qui contient v=DKIM1 et une longue clé indique que l'enregistrement existe :
dig +short TXT default._domainkey.exemple.fr
  1. Si DKIM n'est pas activé pour votre domaine, demandez-le-nous par ticket depuis votre espace client. Tant qu'il ne l'est pas, Plesk ne vous montre aucune clé à recopier.
  2. Ouvrez les réglages de messagerie du domaine dans Plesk. La documentation de Plesk donne le chemin Websites & Domains, votre domaine, onglet Mail, Mail Settings, dans les libellés de la version anglaise.
  3. Affichez l'aide pour un DNS externe, intitulée How to configure external DNS dans cette même documentation. Plesk y présente deux enregistrements : default._domainkey avec la clé publique, et _domainkey avec la politique.
  4. Recopiez-les chez le gestionnaire de votre zone, en type TXT. La plupart des interfaces ajoutent le domaine d'elles-mêmes : saisissez default._domainkey comme nom, pas default._domainkey.exemple.fr, sous peine d'obtenir un nom à rallonge que personne n'interroge.
  5. Vérifiez sur un vrai message, une fois la propagation DNS faite : envoyez-en un vers Gmail, ouvrez-le, choisissez « Afficher l'original » dans le menu à trois points, et cherchez DKIM : PASS avec votre domaine.

Si votre messagerie est ailleurs

Une messagerie chez un autre fournisseur signe avec sa propre clé et son propre sélecteur, souvent nommé d'après lui. Gardez cet enregistrement tel quel : vous n'avez rien à changer de ce côté en hébergeant votre site chez nous. Si des messages partent aussi par notre serveur, l'enregistrement default._domainkey vient s'ajouter au sien, sans le remplacer.

Les erreurs fréquentes

  • Une clé coupée ou altérée. Certaines interfaces limitent la longueur d'un champ, ou ajoutent des espaces et des guillemets au collage. La clé doit arriver entière : comparez le résultat de dig à la valeur donnée par Plesk.
  • Un nom mal formé, avec le domaine écrit deux fois, comme vu à l'étape 5.
  • Une clé changée d'un côté seulement. Si la clé est régénérée sur le serveur, l'ancienne valeur publiée ne correspond plus et tous les messages échouent. Avant un changement de clé, abaissez la durée de vie de l'enregistrement, pour que l'ancienne valeur disparaisse vite des caches.
  • Un enregistrement publié, une signature absente. Si dig trouve la clé mais que vos messages n'ont pas d'en-tête DKIM-Signature, la signature n'est pas activée sur le serveur : écrivez-nous.

Questions fréquentes

DKIM suffit-il à protéger mon domaine ?

Non. DKIM prouve qu'un message signé vient de vous, mais ne dit pas quoi faire d'un message non signé qui prétend venir de vous. C'est le rôle de DMARC, qui s'appuie sur DKIM et sur SPF.

Une redirection casse-t-elle la signature DKIM ?

En général non : la signature voyage avec le message, et reste valable tant que le serveur qui fait suivre ne modifie ni le corps ni les en-têtes signés. C'est ce qui rend DKIM plus robuste que SPF dans ce cas.

Faut-il changer la clé régulièrement ?

C'est une bonne pratique, sans urgence pour une clé de 2 048 bits, la longueur de celles que génère notre Plesk. Le changement demande de publier la nouvelle clé avant que le serveur ne l'utilise : faites-le avec nous, pour éviter une période où vos messages échouent.

Articles liés