Créer un enregistrement DKIM : clés, DNS et vérification

Si vous envoyez des messages depuis votre domaine, vous devez publier des enregistrements DKIM dans le DNS. Une configuration correcte est importante pour l’authentification et peut contribuer à la délivrabilité. Sans signature DKIM vérifiable, les destinataires ne peuvent pas utiliser ce mécanisme pour contrôler l’intégrité du contenu signé pendant le transport. Google, Yahoo et Microsoft imposent des exigences d’authentification à certains expéditeurs, notamment ceux envoyant en nombre ; DKIM reste également conseillé pour les faibles volumes.

Ce guide couvre tout le processus : génération des clés, publication DNS, activation de la signature et vérification. Sans détour : les étapes, la syntaxe et les pièges habituels. Les principes sont identiques, que vous créiez les enregistrements manuellement ou utilisiez une plateforme gérée.

Qu’est-ce qu’un enregistrement DKIM ?

Un enregistrement DKIM est un TXT DNS contenant la partie publique d’une paire de clés cryptographiques. Votre serveur signe les messages sortants avec la clé privée. Le destinataire récupère la clé publique dans le DNS et vérifie la signature pour établir la responsabilité du domaine signataire et l’intégrité du corps et des en-têtes signés. DKIM est défini dans le RFC 6376 et constitue un élément majeur de l’authentification moderne des e-mails.

Créer des enregistrements DKIM en 4 étapes

Étape 1 : générer la paire de clés DKIM

Avant de publier l’enregistrement, il vous faut une paire de clés : une clé privée conservée dans le système signataire et une clé publique publiée dans le DNS. La méthode de génération dépend de votre configuration.

Avec une messagerie hébergée (Google Workspace, Microsoft 365, Zoho), le fournisseur génère les clés. Vous copiez les enregistrements DNS qu’il fournit. Dans Google Workspace, ouvrez Console d’administration > Applications > Google Workspace > Gmail > Authentifier les e-mails et cliquez sur « Générer un nouvel enregistrement » ; les libellés peuvent varier.

Avec votre propre serveur de messagerie (Postfix, Exim, OpenDKIM), générez la paire en ligne de commande :

openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

Utilisez des clés de 2048 bits lorsque votre système les accepte. Des guides anciens mentionnent 1024 bits, une taille offrant une marge de sécurité moindre en 2026. L’acceptation des signatures de 1024 bits dépend du destinataire et de ses politiques ; préférez une clé plus robuste quand c’est possible.

Choisissez aussi un sélecteur, une étiquette identifiant cette clé précise. Les sélecteurs permettent la rotation des clés ou des clés distinctes selon les services. Les conventions courantes comprennent google, s1, mail2026 ou le nom du service, comme sendgrid.

Étape 2 : ajouter la clé publique au DNS

C’est ici que vous publiez l’enregistrement DKIM dans le DNS du domaine. La procédure est généralement simple. Connectez-vous au fournisseur DNS (Cloudflare, Route 53, GoDaddy, Namecheap) et ajoutez un TXT, ou le type d’enregistrement demandé par le fournisseur d’envoi.

Champ Hôte/Nom :

selector._domainkey.yourdomain.com

Remplacez selector par le nom choisi à l’étape 1. Avec le sélecteur s1 et le domaine example.com, le nom complet est :

s1._domainkey.example.com

Champ Valeur :

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2K4PavXoNY8eGK2u...truncated...base64encodedpublickey

La balise p= contient la clé publique complète sous forme de chaîne base64. Retirez les en-têtes PEM (-----BEGIN PUBLIC KEY-----) et les retours à la ligne : les données de la clé doivent former une chaîne continue. L’exemple est abrégé et n’est pas une clé utilisable.

Important : Chaque chaîne d’un TXT DNS est limitée à 255 caractères d’un octet. Une clé RSA de 2048 bits dépasse cette taille après encodage. Certains fournisseurs divisent automatiquement le texte en chaînes entre guillemets ; d’autres exigent des fragments manuels de 255 caractères au maximum entre guillemets doubles. Le vérificateur concatène les chaînes d’un même enregistrement.

Étape 3 : activer la signature DKIM sur le serveur

L’enregistrement DNS seul ne suffit pas. Votre serveur doit signer activement les messages sortants avec la clé privée correspondante.

Google Workspace : Cliquez sur « Démarrer l’authentification » dans le panneau où la clé a été générée, selon l’interface actuelle.

OpenDKIM (Postfix/Exim) : Modifiez /etc/opendkim.conf :

Selector    s1
KeyFile     /etc/opendkim/keys/example.com/dkim_private.pem
Domain      example.com
Socket      inet:8891@localhost

Ajoutez ensuite le milter dans Postfix, dans /etc/postfix/main.cf :

milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

Redémarrez les deux services après avoir validé les réglages pour votre installation :

sudo systemctl restart opendkim
sudo systemctl restart postfix

Les prestataires d’envoi tiers (SendGrid, Mailgun, Amazon SES) ont leurs propres procédures. Le schéma habituel est de recevoir des CNAME ou TXT, les publier dans le DNS, puis cliquer sur « Vérifier » dans le tableau de bord. Suivez les instructions actuelles du service.

Étape 4 : vérifier l’enregistrement

Ne supposez pas que tout fonctionne. Vérifiez dès le départ.

En ligne de commande :

dig TXT s1._domainkey.example.com +short

La réponse devrait contenir la clé publique. Si elle est vide, vérifiez le nom, le type d’enregistrement et le DNS faisant autorité, ainsi que les caches. Certains guides conseillent d’attendre jusqu’à 48 heures, même si beaucoup de TXT deviennent visibles en quelques minutes ; le délai dépend du TTL et ne corrige pas un enregistrement erroné.

Avec un message de test : Envoyez vers Gmail et examinez les en-têtes bruts. Recherchez :

Authentication-Results: mx.google.com;
    dkim=pass header.i=@example.com header.s=s1

Si vous voyez dkim=pass, la signature de ce test est validée. Avec dkim=fail ou dkim=neutral, examinez la configuration et la cause précise du résultat ; la section suivante présente les erreurs fréquentes.

Comprendre la syntaxe DKIM

Comprendre la syntaxe aide à publier correctement les enregistrements, surtout la première fois. Voici leurs composants :

v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhkiG9w0BAQE...

Erreurs fréquentes lors de la création d’enregistrements DKIM

Lors d’une première configuration, les équipes rencontrent souvent les mêmes erreurs.

1. Retours à la ligne dans la clé publique. Très fréquent. Copier une clé PEM avec ses retours à la ligne dans le champ DNS peut l’invalider. Retirez les retours et espaces des données base64.

2. Mauvais sélecteur dans le nom DNS. Vous avez généré la clé avec s1, mais le serveur utilise default. Le destinataire recherche default._domainkey.example.com, ne trouve pas la clé et DKIM échoue. Le sélecteur DNS doit correspondre exactement à celui utilisé pour signer.

3. Plusieurs enregistrements DKIM avec le même sélecteur. Contrairement à SPF, qui exige une politique unique par domaine, DKIM permet plusieurs clés avec des sélecteurs distincts. Publier deux TXT séparés pour s1._domainkey peut invalider la recherche de clé ; le destinataire ne doit pas avoir à en choisir un.

4. Oublier d’activer la signature. Vous avez ajouté l’enregistrement en pensant avoir terminé. Le DNS publie seulement la clé publique ; le serveur doit signer les messages avec la clé privée. Sans signature, l’enregistrement n’authentifie rien.

5. Utiliser des clés de 1024 bits. Elles peuvent encore être acceptées, mais les consignes Google pour les expéditeurs recommandent 2048 bits lorsque c’est possible. Générez une nouvelle paire, publiez la clé publique sous un nouveau sélecteur et actualisez la signature. Gardez l’ancienne clé pendant le transit des messages déjà envoyés, puis révoquez-la en vidant son p=.

DKIM, SPF et DMARC : l’ensemble complet

DKIM ne fonctionne pas seul. Il constitue un volet d’un cadre d’authentification à trois composants.

SPF vérifie que l’IP du serveur expéditeur est autorisée par le domaine évalué. Il est important, mais peut échouer lors d’un transfert puisque l’IP change. Si vous ne l’avez pas configuré, consultez le guide de configuration SPF et le fonctionnement de SPF pour les e-mails pour comprendre le plafond de 10 termes déclenchant des recherches et les autres contraintes.

DKIM peut survivre au transfert parce qu’il signe le contenu, pas l’IP d’envoi, à condition que les données signées restent intactes. C’est donc un complément important de SPF.

DMARC relie les mécanismes. Il indique une politique au destinataire pour les messages échouant à DMARC : quarantaine, rejet ou aucune action demandée. Pour réussir, SPF ou DKIM doit être validé et aligné sur le domaine From visible.

L’objectif peut être que SPF réussisse et s’aligne, que DKIM réussisse et s’aligne, puis d’appliquer p=reject après vérification de tous les expéditeurs légitimes. Cela peut contribuer à une bonne réputation du domaine, sans garantir un meilleur placement en boîte de réception.

Pour une entreprise, cet ensemble constitue une base importante pour des opérations de messagerie sécurisées, pas une garantie de sécurité complète.

Comment TrekMail peut vous aider avec DKIM

Pour un domaine unique, la création manuelle est souvent gérable. Sur des dizaines de domaines, l’automatisation peut réduire le travail : rotation des clés, coordination des sélecteurs entre services et détection des erreurs avant qu’elles nuisent à la délivrabilité.

L’approche TrekMail consiste à afficher les enregistrements SPF/DKIM/DMARC nécessaires lors de la connexion d’un domaine et à vérifier leur configuration. La génération et la gestion des clés dépendent du chemin d’envoi : la plateforme s’en charge pour son SMTP géré ; avec un SMTP externe, obtenez les valeurs du fournisseur signataire. Les contrôles peuvent signaler des problèmes, sans garantir la détection de tout incident avant son impact sur les messages.

• Forfait Nano ($0) : BYO SMTP (Amazon SES, Mailgun, etc.). Utilisez les enregistrements DKIM du fournisseur signataire. Présenté sans carte bancaire ; vérifiez les conditions actuelles.
• Starter ($3.50/mois) : SMTP géré ; vérifiez les fonctions disponibles de génération et rotation DKIM. L’offre décrite comprend un essai gratuit de 14 jours avec carte.
• Pro ($10/mois) : Plusieurs domaines d’envoi avec leurs propres sélecteurs DKIM, selon les fonctions actuelles. Essai gratuit de 14 jours dans l’offre décrite.
• Agency ($23.25/mois) : Gestion centralisée des domaines clients, avec une référence de 100+ domaines. Vérifiez les limites et fonctions de rotation et surveillance. Essai gratuit de 14 jours dans l’offre décrite.

Ce n’est pas seulement une question de confort. Un enregistrement incorrect peut rester invisible jusqu’à l’apparition d’échecs d’authentification ou de livraison. La validation automatisée aide à détecter les problèmes, mais ne remplace pas les tests avec de vrais messages.

Conclusion

Pour créer correctement des enregistrements DKIM, il faut quatre éléments : une paire de clés de 2048 bits lorsque c’est possible, un TXT DNS sous le bon sélecteur, un serveur signant activement et une vérification du résultat. Un domaine simple peut demander environ dix minutes de travail, hors attente et diagnostic.

Après DKIM, ajoutez SPF et DMARC pour renforcer l’authentification du domaine. Ne pas disposer de l’ensemble peut limiter les signaux de confiance et la protection contre l’usurpation, mais sa configuration ne garantit ni livraison ni sécurité absolues.

Pour réduire la gestion manuelle du DNS, essayez TrekMail gratuitement selon les conditions actuelles et utilisez l’assistant pour vous aider à configurer les enregistrements.