Comment générer une clé DKIM (et publier la bonne)

Activer DKIM commence par une question simple en apparence : comment génère-t-on une clé DKIM ? La réponse dépend de qui signe ton courrier — dans la grande majorité des cas, ta plateforme d'envoi génère la clé pour toi, et ton travail se résume à publier le bon enregistrement DNS. Mais il y a des choix qui comptent (la taille de clé, le CNAME vs le TXT, l'alignement) et des pièges à éviter. Ce guide explique comment obtenir une clé DKIM valide, où va chaque morceau, et comment vérifier que tout est correct.

Ce qu'est vraiment une « clé DKIM »

Une clé DKIM n'est pas un objet unique mais une paire :

• une clé privée, qui sert à signer tes messages au départ. Elle reste secrète, stockée par ta plateforme d'envoi. Elle ne quitte jamais cet environnement.
• une clé publique, dérivée de la privée, que tu publies en DNS. Les destinataires la récupèrent pour vérifier la signature.

Générer une clé DKIM, c'est donc créer cette paire. La partie visible de ton côté — l'enregistrement DNS — ne contient que la clé publique. Si tu vois ta clé privée dans un enregistrement DNS, c'est une erreur grave : elle ne doit jamais y figurer.

Le cas le plus fréquent : ta plateforme génère pour toi

Pour Microsoft 365, Google Workspace, un routeur marketing ou la plupart des SaaS, tu n'as pas à lancer de commande cryptographique. La plateforme génère la paire, garde la clé privée, et te fournit l'enregistrement DNS à publier. La marche à suivre :

1. Active DKIM dans la console de la plateforme.
2. Récupère l'enregistrement qu'elle te donne — souvent un ou deux CNAME, parfois un TXT avec la clé publique, à un sélecteur précis (voir le sélecteur DKIM).
3. Publie-le dans ton DNS, sans modifier la valeur (les clés sont longues ; recopie-les intégralement).
4. Active la signature côté plateforme une fois la propagation DNS faite.

C'est la voie recommandée : la plateforme gère la clé privée et, souvent, sa rotation.

Le CNAME plutôt que le TXT, quand c'est possible

Beaucoup de prestataires proposent de publier un CNAME qui pointe vers un enregistrement qu'ils maintiennent, plutôt qu'un TXT contenant la clé en dur. Privilégie le CNAME : il permet au prestataire de faire tourner la clé sans que tu retouches ton DNS à chaque fois. Tu publies une fois, et la rotation des clés devient transparente pour toi. Le TXT brut reste valable, mais t'oblige à intervenir à chaque renouvellement.

Générer une clé toi-même (cas avancé)

Si tu opères ta propre infrastructure d'envoi (un serveur Postfix, par exemple), tu génères la paire toi-même. Conceptuellement, tu crées une clé RSA, tu en extrais la partie publique, et tu construis l'enregistrement DNS. L'enregistrement publié ressemble à :

selecteur._domainkey.ton-domaine.fr.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ... (clé publique)"

Le p= contient la clé publique encodée. La clé privée correspondante, elle, reste sur ton serveur, lue par ton outil de signature. Deux règles d'or dans ce cas : protège la clé privée comme un secret critique, et choisis une taille adaptée (voir plus bas).

Quelle taille de clé choisir

La question revient toujours : 1024 ou 2048 bits ? La réponse courte : 2048 bits est le standard recommandé aujourd'hui, plus robuste. Le 1024 reste accepté mais vieillissant. Il y a toutefois une subtilité technique (la longueur de l'enregistrement DNS) qui mérite un guide dédié — vois 1024 ou 2048 bits. Si tu pars de zéro, choisis 2048.

Le piège qui annule tout : l'alignement

Voici l'erreur la plus coûteuse. Tu peux générer et publier une clé DKIM parfaitement valide, voir la signature « passer », et pourtant ne rien apporter à DMARC. Pourquoi ? Parce que DMARC exige que le domaine signataire (d= dans la signature) s'aligne avec celui de ton From:. La signature DKIM par défaut de beaucoup de plateformes utilise leur domaine (d=plateforme.com), pas le tien. Résultat : la signature est valide, mais pour le mauvais domaine.

La solution est de configurer une signature à ta marque : la plupart des prestataires proposent une option « domaine de signature personnalisé » ou « DKIM authentifié », qui fait signer avec d=ton-domaine.fr. C'est précisément ce qui rend ta clé DKIM utile pour DMARC. Le mécanisme complet est dans comment les trois protocoles fonctionnent ensemble.

Vérifier que ta clé fonctionne

Une fois la clé publiée et la signature activée, contrôle trois choses :

1. La clé publique est bien là, complète et au bon sélecteur (dig TXT selecteur._domainkey.ton-domaine.fr).
2. La signature passe sur un vrai message — vois comment vérifier une signature email.
3. Elle s'aligne avec ton From:, visible dans tes rapports agrégés.

Tu peux confirmer tout ça d'un coup en passant ton domaine dans notre analyseur gratuit, qui vérifie la présence, la validité et l'alignement de tes clés.

Activer DKIM sur les plateformes courantes

La marche exacte dépend de ta plateforme, mais le schéma est partout le même : activer DKIM dans la console, récupérer l'enregistrement, le publier, attendre, signer. Quelques repères concrets :

• Microsoft 365. Dans le portail de sécurité, sous l'authentification de la messagerie, tu actives DKIM pour ton domaine. Microsoft te fournit deux CNAME (selector1 et selector2) à publier ; les deux servent à permettre la rotation alternée des clés. Une fois publiés et propagés, tu actives la signature.
• Google Workspace. Dans la console d'administration, sous l'authentification de la messagerie, tu génères une clé (choisis 2048 bits) pour ton domaine. Google te donne un TXT à publier au sélecteur google. Après propagation, tu démarres l'authentification.
• Routeurs et SaaS (Brevo, SendGrid, Mailchimp…). Ils proposent presque tous un domaine de signature personnalisé via un ou plusieurs CNAME. C'est aussi là que tu actives l'alignement (d=ton-domaine.fr) — l'étape qui rend la signature utile à DMARC.

Dans tous les cas, la règle est la même : recopie la valeur intégralement, attends la propagation avant d'activer la signature, et vérifie ensuite que le d= est bien le tien et pas celui du prestataire.

Les erreurs de génération les plus fréquentes

Trois ratés reviennent en boucle. D'abord, activer la signature avant la propagation DNS : les premières signatures pointent vers une clé pas encore visible et échouent — attends que dig montre la clé avant de signer. Ensuite, tronquer la clé au copier-coller, surtout en 2048 bits où elle est longue : un seul caractère manquant casse toute la vérification. Enfin, oublier l'alignement : tu actives DKIM, la signature passe, mais avec le d= du prestataire — tu crois être protégé alors que DMARC ne s'appuie sur rien. Vérifie systématiquement ces trois points après chaque activation, et tu t'épargnes l'écrasante majorité des échecs DKIM de mise en route.

Questions fréquentes

Dois-je générer la clé moi-même ? Rarement. Si tu envoies via une plateforme (Microsoft, Google, un SaaS), elle génère la paire et garde la clé privée. Tu ne génères toi-même que si tu opères ta propre infrastructure de signature.

Où va la clé privée ? Elle reste dans l'environnement qui signe (la plateforme ou ton serveur). Elle ne se publie jamais en DNS et ne doit jamais quitter cet environnement. Le DNS ne contient que la clé publique.

Puis-je réutiliser la même clé pour plusieurs domaines ? À éviter. Chaque domaine devrait avoir sa propre clé (et son propre sélecteur), pour isoler les risques et simplifier la rotation.

Combien de temps avant que ça marche ? Le temps de la propagation DNS (de quelques minutes à quelques heures). N'active la signature côté plateforme qu'une fois la clé publique visible, sinon les premières signatures échoueront.

1024 ou 2048 bits ? 2048 pour un nouveau déploiement. Le 1024 fonctionne encore mais est moins robuste ; à remplacer à la prochaine rotation.

DKIM et délivrabilité : pourquoi ça compte vraiment

Au-delà de la sécurité, DKIM a un effet concret sur la délivrabilité de tes emails. Les grands fournisseurs de messagerie (Gmail, Outlook, Yahoo) intègrent la présence et l'alignement DKIM dans leurs scores de réputation : un domaine qui signe correctement depuis longtemps, avec une clé alignée, bâtit une historique de confiance que les filtres anti-spam prennent en compte. Inversement, un domaine sans DKIM (ou avec une signature non alignée) est traité avec plus de méfiance, surtout si sa réputation est encore jeune. DKIM n'empêche pas le spam — un spammeur peut tout à fait signer ses messages — mais il dit au récepteur « ce message vient bien de qui il prétend venir », ce qui est un signal de légitimité important. Combiné à SPF et DMARC, il constitue le trio de base que tout expéditeur sérieux doit avoir en place avant de chercher à optimiser quoi que ce soit d'autre. Bien configuré une fois, DKIM travaille de façon invisible pour toi, accumulant de la réputation à chaque email légitime que tu envoies.

Laisse Thomas générer le bon enregistrement

Entre la taille de clé, le CNAME vs TXT et surtout l'alignement, une clé DKIM mal posée passe inaperçue jusqu'au jour où DMARC échoue. Thomas, ton RSSI virtuel, te dit pour chaque plateforme l'enregistrement exact à publier, vérifie que la signature s'aligne avec ton domaine, et te guide jusqu'à un DKIM qui compte réellement pour DMARC.

Analyse ton domaine gratuitement → ou crée un compte pour un DKIM correct du premier coup.