Générateur d'enregistrement DKIM
Transforme n'importe quelle public key en TXT record DKIM exact, avec nettoyage PEM, alertes de troncature et découpage automatique en chaînes de 255 caractères.
Ce générateur d'enregistrement DKIM transforme n'importe quelle public key en TXT record DNS exact à publier, directement dans votre navigateur, donc rien de ce que vous collez ne quitte la page. Déposez un bloc PEM ou du base64 brut avec un selector et un domaine, et il écrit l'hôte (selector._domainkey.votredomaine.com) et la valeur (v=DKIM1; k=rsa; p=...), en détectant RSA ou Ed25519 depuis les octets décodés. Le vrai atout, c'est le piège des 255 caractères TXT : les valeurs longues sont découpées automatiquement en blocs entre guillemets, donc aucun panneau DNS ne peut tronquer votre clé en silence. Il signale aussi les clés privées, le base64 invalide et les clés courtes.
100% dans votre navigateur. Rien de ce que vous tapez ne quitte cette page.
Générateur d'enregistrement DKIM avec nettoyage PEM, découpage TXT et outil de clés dans le navigateur
Les enregistrements DKIM échouent pour des raisons bêtes. Quelqu'un colle une public key avec les en-têtes PEM encore attachés, ou son panneau DNS tronque en silence une valeur de plus de 255 caractères, et la vérification meurt sans bruit. Cet outil gère les deux cas. Collez n'importe quelle public key (PEM ou base64 brut) avec un selector et un domaine, et il écrit le TXT record exact : l'hôte (selector._domainkey.yourdomain.com) et la valeur (v=DKIM1; k=rsa; p=...), déjà découpée en blocs entre guillemets quand elle est trop longue. Il y a aussi un deuxième onglet qui génère une paire de clés RSA 2048 ou Ed25519 directement dans votre navigateur avec WebCrypto, pratique pour les labs et les tests. Tout tourne côté client, rien ne quitte cette page. Une fois l'enregistrement publié, vérifiez-le avec le DKIM lookup.
Les en-têtes, sauts de ligne et guillemets sont retirés automatiquement. Le type de clé (RSA ou Ed25519) est détecté à partir des octets décodés.
Collez une public key ci-dessus pour construire l'enregistrement.
Une chaîne TXT plafonne à 255 caractères, donc les valeurs longues se publient en plusieurs chaînes entre guillemets que les resolvers recollent ensuite. Certains panneaux font le découpage à votre place, d'autres rejettent la valeur, et les pires la tronquent sans un mot. Si le vôtre râle, collez cette version découpée.
Lisez ceci avant de générer quoi que ce soit. La clé privée ci-dessous est créée dans votre navigateur et n'est envoyée nulle part, mais un onglet de navigateur reste un mauvais endroit pour faire naître un secret de production. Les installations sérieuses génèrent la paire de clés sur le serveur mail lui-même (ou laissent le fournisseur s'en charger), comme ça la clé privée ne voyage jamais. Utilisez cet onglet pour les labs, les tests et l'apprentissage. Stockez toute clé privée côté serveur uniquement, jamais dans le DNS, jamais dans un doc, jamais dans un chat.
Copiez-la directement dans la config de signature (OpenDKIM KeyFile, rspamd, milter Postfix, ce que vous utilisez), puis fermez cet onglet. Recharger la page détruit la clé, il n'y a aucun stockage ici, d'aucune sorte.
Ce que DKIM signe et pourquoi les selectors existent
Ce générateur d'enregistrement DKIM appose une signature cryptographique sur le mail sortant. Le serveur émetteur hache le corps du message et un jeu d'en-têtes choisi (From est obligatoire d'après la RFC 6376, le reste est au choix du signataire), signe le hash avec une clé privée et glisse le résultat dans un en-tête DKIM-Signature. Le récepteur lit deux choses dans cet en-tête : le domaine (d=) et le selector (s=), va chercher votre public key dans le DNS à selector._domainkey.domain, et vérifie le calcul. Signature valide, ça veut dire que le message n'a pas été modifié en transit et que le domaine signataire s'en porte vraiment garant.
Alors pourquoi cette indirection du selector ? Parce qu'un domaine a rarement un seul signataire. Votre propre serveur mail signe avec une clé, votre plateforme de newsletters avec une autre, le CRM avec une troisième. Chacun reçoit son propre selector, son propre enregistrement DNS, sa propre clé. Les selectors rendent aussi la rotation indolore : on publie la nouvelle clé sous un selector tout neuf, on bascule le signataire, et l'ancien enregistrement peut rester là jusqu'à ce que plus aucun mail en cache ne le référence. Sans selectors, vous auriez une seule clé globale et chaque rotation serait un jour J. Choisissez des noms de selector ennuyeux avec une date dedans, du genre s2026a. Vous vous remercierez à la prochaine rotation.
Le piège des 255 caractères TXT qui casse les clés longues
Voilà le piège pour lequel cet outil existe. Un TXT record DNS contient une ou plusieurs chaînes de caractères, et chaque chaîne plafonne à 255 octets. C'est le protocole, pas une lubie de fournisseur. Une public key RSA 2048 en base64 fait environ 392 caractères, donc la valeur complète de l'enregistrement atterrit autour de 410. Trop long pour une seule chaîne.
Le correctif est vieux et standard : publier la valeur en plusieurs chaînes entre guillemets, du style "v=DKIM1; k=rsa; p=MIIB..." "...rest...", et les resolvers les reconcatènent en une seule valeur logique. Les vérificateurs voient la clé entière. Le problème, c'est ce que les panneaux DNS font de votre copier-coller. Certains découpent automatiquement et vous ne remarquez rien. D'autres balancent une erreur de validation vague. Les pires acceptent la valeur et la coupent en silence à 255 caractères, ce qui laisse une clé tronquée dans le DNS et un échec DKIM permanent alors que tout le reste a l'air normal. Si vos signatures échouent et que l'enregistrement a l'air presque bon, comptez les caractères de p=. J'ai perdu un après-midi exactement là-dessus, et c'est pour ça que la sortie découpée ci-dessus apparaît automatiquement dès que la valeur dépasse la limite.
Les clés Ed25519 esquivent complètement le problème. La public key fait 32 octets, soit 44 caractères en base64, et l'enregistrement entier tient dans une seule chaîne courte. Une des raisons, parmi d'autres, qui font qu'on l'aime bien.
La rotation des clés, honnêtement
Tous les guides DKIM disent de faire tourner les clés régulièrement et la plupart des admins, discrètement, ne le font jamais. Soyons francs sur le compromis. Le risque d'une vieille clé, ce n'est pas que RSA 2048 se fasse craquer, c'est que la clé privée fuite : un serveur décommissionné que personne n'a effacé, une sauvegarde de config dans le mauvais bucket, le laptop d'un employé. Une clé DKIM qui fuit permet à un attaquant de signer du mail au nom de votre domaine, et ça passe DMARC. Le rêve du phisheur.
Le calendrier honnête : une rotation tous les 6 à 12 mois si vous pouvez l'automatiser, et tout de suite quand un signataire est décommissionné ou qu'une clé a pu fuiter. Si la rotation est manuelle et pénible chez vous, je préfère vous voir la faire une fois par an de façon fiable plutôt que promettre du trimestriel et ne jamais le tenir. La mécanique est facile grâce aux selectors : générez la nouvelle paire, publiez s2026b._domainkey à côté de l'ancien enregistrement, pointez le signataire vers la nouvelle clé, attendez une semaine environ que le mail en transit et en file d'attente se vide, puis supprimez l'ancien enregistrement ou, plus poliment, remplacez sa valeur p= par une valeur vide (p= sans rien derrière, c'est la façon RFC 6376 de dire que la clé est révoquée).
Une chose que les fournisseurs managés font pour vous : Microsoft 365 et Google gèrent ou font tourner eux-mêmes leurs selectors par défaut. Les clés que VOUS possédez sont celles que personne ne fait tourner.
Où DKIM se place à côté de SPF et DMARC
Trois mécanismes, trois questions différentes. SPF demande si ce serveur a le droit d'envoyer pour le domaine d'enveloppe. DKIM demande si ce message précis est signé par le domaine qu'il revendique. DMARC s'assoit au-dessus et pose la question qui intéresse vraiment les utilisateurs : est-ce que tout ça correspond à l'adresse From affichée dans le client mail, et que faire quand ça ne correspond pas.
DKIM est sans doute la jambe la plus solide des trois, parce que la signature survit au forwarding, ce que SPF, c'est connu, ne fait pas. Une mailing list ou un forwarder renvoie votre message depuis son propre serveur, SPF casse, DKIM tient en général (sauf si la liste réécrit le corps du message, oui, c'est de vous qu'on parle, les listservs qui rajoutent un footer). C'est pour ça qu'un domaine avec du DKIM solide sur chaque expéditeur peut atteindre p=reject avec bien moins de douleur qu'un domaine qui s'appuie sur SPF seul.
Mais DKIM tout seul ne bloque rien. Un usurpateur envoie simplement du mail non signé, et sans politique DMARC aucun récepteur n'est obligé de s'en soucier. La chaîne complète, c'est : DKIM signe, SPF autorise, DMARC aligne les deux avec le From visible et fixe les conséquences. Construisez l'enregistrement ici, puis écrivez la politique avec le DMARC record generator, et regardez la note de l'ensemble avec le vérificateur de posture d'authentification email.
Questions fréquentes
Je génère mes clés DKIM dans un outil en ligne ou sur le serveur mail ?
Sur le serveur mail, si c'est de la production. La clé privée devrait naître là où elle vit, comme ça elle ne traverse jamais un presse-papiers ni un écran. Le générateur de cet outil tourne entièrement dans votre navigateur avec WebCrypto et n'envoie rien nulle part, ce qui le rend très bien pour les labs, les salles de classe et les tests rapides, mais un openssl ou un opendkim-genkey côté serveur reste le choix d'adulte.
Pourquoi mon fournisseur DNS rejette ou tronque mon enregistrement DKIM ?
Parce qu'une chaîne TXT est plafonnée à 255 caractères et qu'une valeur d'enregistrement RSA 2048 tourne autour de 410. La valeur doit être publiée en plusieurs chaînes entre guillemets que les resolvers reconcatènent. Certains panneaux découpent automatiquement, d'autres ont besoin de la forme découpée que cet outil produit, et quelques-uns tronquent en silence, ce qui laisse une clé cassée dans le DNS.
C'est quoi un selector DKIM, et je peux le nommer n'importe comment ?
Le selector, c'est le label avant _domainkey dans le nom d'hôte DNS, et il indique aux vérificateurs laquelle de vos clés a signé un message donné. Les noms sont des labels DNS à peu près libres ; choisissez quelque chose de daté comme s2026a pour que les rotations restent lisibles. Chaque service de signature reçoit son propre selector et sa propre clé.
RSA 2048 ou Ed25519, lequel choisir ?
RSA 2048 pour tout ce qui est réel, parce que tous les vérificateurs de la planète gèrent k=rsa. Ed25519 (RFC 8463) a des clés plus courtes et un enregistrement qui tient dans une seule chaîne TXT, mais le support côté récepteurs n'est toujours pas universel, donc les déploiements qui l'utilisent signent en général avec les deux. Pour un lab, prenez celui que vous étudiez.
Comment confirmer que l'enregistrement fonctionne vraiment après publication ?
Interrogez le TXT record à selector._domainkey.votredomaine.com et vérifiez que v=DKIM1 et la valeur p= complète reviennent intacts, c'est exactement ce que fait l'outil DKIM lookup de ce site. Envoyez ensuite un vrai message vers une boîte que vous contrôlez et lisez l'en-tête Authentication-Results pour y trouver dkim=pass.
DKIM tout seul empêche-t-il quelqu'un d'usurper mon domaine ?
Non. DKIM prouve qu'un message signé est authentique, mais il n'oblige personne à rejeter du mail non signé qui prétend venir de chez vous. Cette contrainte vient d'une politique DMARC qui exige l'alignement entre le domaine DKIM et l'adresse From visible. DKIM, c'est la preuve ; DMARC, c'est le verdict.