Générateur d'enregistrement DKIM

Cet outil génère une paire de clés RSA-2048 entièrement dans votre navigateur via l'API Web Crypto. Rien n'est envoyé sur un serveur : la clé privée est créée, affichée puis proposée au téléchargement sans le moindre aller-retour réseau. Le résultat comporte deux parties : une valeur d'enregistrement TXT au format `v=DKIM1; k=rsa; p=<clé publique en base64>` à placer dans le DNS, et une clé privée au format PEM à charger dans votre serveur de messagerie ou votre plateforme d'envoi pour signer les messages sortants.

La RFC 6376 définit le mécanisme de signature DKIM lui-même mais laisse la génération de clé aux implémenteurs - il n'existe donc pas d'outil ou de format imposé pour créer la paire, seulement des exigences sur le contenu de l'enregistrement une fois la clé créée.

• Clé publique → enregistrement TXT à `<sélecteur>._domainkey.<votredomaine>`
• Clé privée → chargée dans le serveur de messagerie ou l'ESP qui signe vos emails
• La génération se fait localement ; la clé privée n'est jamais transmise

Le sélecteur est l'étiquette placée avant `._domainkey` dans le nom de l'enregistrement, et la RFC 6376 n'impose presque aucune contrainte au-delà d'être un label DNS valide - un mot, une date, un numéro de version conviennent tous. Ce qui compte en pratique, c'est que le sélecteur soit assez unique pour ne pas entrer en collision avec un autre système de signature sur le même domaine, et assez explicite pour identifier d'un coup d'œil à quelle plateforme d'envoi ou génération de clé il correspond.

Une convention courante consiste à intégrer une date ou un usage dans le sélecteur, par exemple `2026a` ou `mailgun`, plutôt que de garder la valeur par défaut `default` - cela facilite l'audit de la rotation et des configurations multi-prestataires, chaque sélecteur visible dans le DNS devenant auto-descriptif au lieu de nécessiter une table de correspondance tenue ailleurs.

• Toute chaîne valide en tant que label DNS fonctionne : lettres, chiffres, tirets
• Un sélecteur par source d'envoi garde les signatures traçables jusqu'à leur origine
• Éviter de réutiliser un sélecteur déjà occupé par une autre plateforme sur le même domaine

La RFC 8301 met à jour la spécification DKIM d'origine en imposant une taille minimale de clé RSA de 1024 bits pour la vérification, mais recommande 2048 bits pour la signature, et déprécie SHA-1 au profit de SHA-256 pour le hachage de signature. Le RSA-2048 est la taille que les grands fournisseurs de messagerie attendent aujourd'hui : descendre en dessous risque de faire traiter la signature comme faible ou invalide côté destinataire, et monter au-delà se heurte à une autre contrainte détaillée plus bas.

Les clés Ed25519 sont définies pour DKIM par la RFC 8463 et produisent une clé publique bien plus courte, mais le support côté serveurs destinataires reste assez inégal pour que le RSA reste le choix par défaut le plus sûr, sauf à avoir confirmé que vos destinataires valident les signatures Ed25519.

Le nom de l'enregistrement suit toujours le motif `<sélecteur>._domainkey.<domaine>`, et la valeur est la chaîne unique produite par ce générateur, débutant par `v=DKIM1`. La plupart des fournisseurs DNS acceptent cette valeur en une seule chaîne ; comme une chaîne TXT unique est plafonnée à 255 octets par la RFC 1035, les résolveurs et logiciels DNS répartissent une valeur plus longue sur plusieurs chaînes entre guillemets qui se recombinent au moment de la requête - vérifiez que l'interface de votre fournisseur ne tronque pas plutôt qu'elle ne poursuit la valeur base64 d'une clé de 2048 bits.

Les RFC DKIM n'imposent aucune valeur de TTL fixe, mais un TTL plus court sur un enregistrement récemment publié ou en cours de rotation réduit la durée pendant laquelle une copie en cache obsolète peut subsister chez les résolveurs si une correction est nécessaire.

La clé privée produite par ce générateur est l'unique exemplaire : fermer l'onglet sans la télécharger signifie devoir régénérer une nouvelle paire et republier l'enregistrement TXT depuis zéro. Conservez le fichier PEM téléchargé comme n'importe quel identifiant sensible : hors du contrôle de version, réservé au compte de service qui en a besoin, jamais collé dans un chat, un ticket ou un document partagé. Quiconque détient la clé privée peut produire des signatures qui se vérifient contre votre sélecteur publié, ce qui est indiscernable au niveau du protocole d'une signature légitime de votre serveur de messagerie.

Si une clé privée est exposée à un moment donné - commit dans un dépôt public, journalisée en clair, partagée sur un canal non sécurisé - traitez-la comme compromise immédiatement et suivez les étapes de rotation ci-dessous plutôt que d'attendre une preuve d'usage frauduleux.

La RFC 6376 présente le sélecteur lui-même comme l'unité de rotation : générez une nouvelle paire sous un nouveau sélecteur, publiez son enregistrement TXT, basculez votre système d'envoi pour signer avec la nouvelle clé privée, et ne retirez l'enregistrement DNS de l'ancien sélecteur qu'une fois certain qu'aucun email en file ou différé n'est encore signé avec. Retirer l'ancien enregistrement trop tôt fait échouer la vérification d'emails légitimes signés juste avant la bascule.

Pour révoquer une clé sans supprimer l'enregistrement, publiez une valeur `p=` vide sur le même sélecteur - la RFC 6376 définit cela comme une révocation explicite, distincte d'un enregistrement absent, et elle prend effet dès qu'un résolveur récupère la nouvelle valeur TXT, sans attendre le TTL restant d'un enregistrement qui aurait été simplement supprimé.