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

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. Le CNAME est à privilégier : il permet au prestataire de faire tourner la clé sans retouche du DNS à chaque fois. Une seule publication suffit, et la rotation des clés devient transparente. Le TXT brut reste valable, mais oblige à intervenir à chaque renouvellement.

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

Une infrastructure d'envoi opérée en propre (un serveur Postfix, par exemple) impose de générer la paire soi-même. Conceptuellement : créer une clé RSA, en extraire la partie publique, construire l'enregistrement DNS. L'enregistrement publié ressemble à :

selecteur._domainkey.exemple.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 le serveur, lue par l'outil de signature. Deux règles d'or dans ce cas : protéger la clé privée comme un secret critique, et choisir 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é — voir 1024 ou 2048 bits. Quand tout part de zéro, le bon choix est 2048.

Le piège qui annule tout : l'alignement

Voici l'erreur la plus coûteuse. Une clé DKIM parfaitement valide peut être générée, publiée, la signature « passer », et pourtant n'apporter rien à DMARC. Pourquoi ? Parce que DMARC exige que le domaine signataire (d= dans la signature) s'aligne avec celui du From:. La signature DKIM par défaut de beaucoup de plateformes utilise leur domaine (d=plateforme.com), pas celui de l'expéditeur. Résultat : la signature est valide, mais pour le mauvais domaine.

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

Vérifier que la clé fonctionne

Une fois la clé publiée et la signature activée, trois contrôles s'imposent :

1. La clé publique est bien là, complète et au bon sélecteur (dig TXT selecteur._domainkey.exemple.fr).
2. La signature passe sur un vrai message — voir comment vérifier une signature email.
3. Elle s'aligne avec le From:, ce que montrent les rapports agrégés.

Un passage du domaine dans notre analyseur gratuit confirme tout ça d'un coup : il vérifie la présence, la validité et l'alignement des clés.

Activer DKIM sur les plateformes courantes

La marche exacte dépend de la 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, DKIM s'active pour le domaine. Microsoft 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, la signature s'active.
• Google Workspace. Dans la console d'administration, sous l'authentification de la messagerie, une clé se génère pour le domaine (2048 bits de préférence). Google fournit un TXT à publier au sélecteur google. Après propagation, l'authentification démarre.
• 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 se règle l'alignement (d=exemple.fr) — l'étape qui rend la signature utile à DMARC.

Dans tous les cas, la règle est la même : recopier la valeur intégralement, attendre la propagation avant d'activer la signature, puis vérifier que le d= porte bien le domaine de l'expéditeur 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 — dig doit montrer la clé avant que la signature démarre. 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 : DKIM est activé, la signature passe, mais avec le d= du prestataire — la protection est illusoire, DMARC ne s'appuie sur rien. Ces trois points contrôlés systématiquement après chaque activation, l'écrasante majorité des échecs DKIM de mise en route disparaît.

Questions fréquentes

Dois-je générer la clé moi-même ? Rarement. Un envoi via une plateforme (Microsoft, Google, un SaaS) lui confie la génération de la paire et la garde de la clé privée. La génération manuelle ne concerne que les infrastructures de signature opérées en propre.

Où va la clé privée ? Elle reste dans l'environnement qui signe (la plateforme ou le 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). La signature ne s'active 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é des 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 un 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, accumulant de la réputation à chaque email légitime expédié.

Thomas génère 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, le RSSI virtuel, indique pour chaque plateforme l'enregistrement exact à publier, vérifie que la signature s'aligne avec le domaine, et guide jusqu'à un DKIM qui compte réellement pour DMARC.

Analyser un domaine gratuitement ou créer un compte pour un DKIM correct du premier coup.