Générateur d'enregistrement DNS DKIM
Saisissez un nom de sélecteur et une clé publique (format PEM) pour générer l'enregistrement DNS TXT de signature DKIM (v=DKIM1; k=rsa; p=...). Les clés publiques de plus de 255 caractères sont automatiquement découpées au format fichier de zone BIND.
Composer l'enregistrement DNS pour DKIM
Saisissez un nom de sélecteur et une clé publique au format PEM : cet outil compose l'enregistrement TXT du DNS servant à vérifier les signatures DKIM, de la forme `v=DKIM1; k=rsa; p=...`. Sa place est à `sélecteur._domainkey.votredomaine`.
**Ce sur quoi chacun bute ici, c'est la limite de 255 caractères par chaîne dans un enregistrement TXT du DNS.** Une clé publique RSA de 2048 bits atteint quelque 390 caractères en Base64 : **elle ne tient donc pas telle quelle dans une seule chaîne.** Dans un fichier de zone, on l'écrit entre parenthèses en plusieurs chaînes, et **le côté récepteur les rejoint en une seule valeur.** Cet outil effectue ce découpage pour vous. **L'autre chose qu'il ne faut jamais manquer, c'est que ce qui va dans le DNS est la clé publique.** La privée n'appartient qu'au serveur qui signe et ne doit jamais le quitter.
Comment s'en servir
- Saisissez le domaine et un nom de sélecteur Le sélecteur est un nom de votre choix ; prenez-en un neuf à chaque remplacement de clé.
- Collez la clé publique au format PEM **C'est la clé commençant par `-----BEGIN PUBLIC KEY-----`, non la privée.**
- Parcourez l'enregistrement produit **Dès qu'il dépasse 255 caractères, la sortie vient découpée entre parenthèses.**
- Inscrivez-le dans le DNS Posez-le comme enregistrement TXT à `sélecteur._domainkey.votredomaine`.
Astuces pour en tirer le meilleur parti
- Vous pouvez coller directement le contenu d'un fichier PEM généré avec opendkim-genkey ou avec openssl genrsa → openssl rsa -pubout d'OpenSSL. Les sauts de ligne et les en-têtes sont supprimés automatiquement.
- Activer le mode test (t=y) peut inciter certains serveurs destinataires à se montrer plus tolérants face à un échec DKIM plutôt que de rejeter le message. C'est une option plus sûre pendant la période de validation avant la mise en production.
- Après avoir publié l'enregistrement généré dans le DNS, nous vous recommandons de vérifier sa prise en compte avec l'outil de diagnostic de délivrabilité de ce site (diagnostic SPF/DKIM/DMARC).
- Les longueurs de clé courantes sont 1024 et 2048 bits ; avec 2048 bits, la chaîne de la clé publique dépasse généralement 255 caractères et se retrouve découpée en plusieurs chaînes. Ce découpage n'est pas une erreur.
- Le nom du sélecteur est libre, mais si un domaine utilise plusieurs prestataires de messagerie, inclure le nom du prestataire (par exemple « google », « mailgun ») facilite la gestion.
Dans quels cas s'en servir
Pour adopter DKIM une première fois
**Les clés une fois créées, il vous montre comment les écrire dans le DNS.**
Pour renouveler une clé
**Ajoutez un enregistrement sous un nouveau sélecteur et retirez l'ancien après la bascule.**
Pour confirmer l'écriture du découpage
Comment partager une clé longue est précisément ce que l'on manque à la main.
Pour vérifier ce qu'un service d'envoi vous a indiqué
**Vous confirmez qu'un enregistrement remis par un service extérieur a la forme voulue.**
Vocabulaire de DKIM
- Sélecteur
- Le nom identifiant une clé. **Il ouvre `sélecteur._domainkey.example.com`, et chaque clé porte le sien.**
- Clé publique
- **Celle qui va dans le DNS.** Le côté récepteur y vérifie les signatures.
- Clé privée
- La clé servant à produire les signatures. **Elle n'appartient qu'au serveur expéditeur et ne doit jamais être publiée.**
- La limite de 255 caractères
- **Le plafond d'une seule chaîne au sein d'un enregistrement TXT.** Ce qui dépasse s'écrit en plusieurs chaînes.
- V=DKIM1
- L'étiquette énonçant la version de l'enregistrement. Elle vient en tête.
- K=rsa
- Le type de clé. Outre RSA, il existe Ed25519, dont les clés sont bien plus courtes.
Questions fréquentes
Anecdote — comment la cryptographie à clé publique empêche l'usurpation d'identité par courriel
DKIM (DomainKeys Identified Mail) a été standardisé en 2004 en fusionnant deux technologies développées séparément par Yahoo! et Cisco — DomainKeys et Identified Internet Mail. Le principe repose sur la cryptographie à clé publique : l'expéditeur chiffre avec sa clé privée une empreinte calculée à partir des en-têtes et d'une partie du corps du message, puis l'ajoute sous forme d'en-tête DKIM-Signature. Le destinataire vérifie cette signature à l'aide de la clé publique publiée dans le DNS et, si la paire de clés correspond, peut confirmer mathématiquement que le contenu n'a pas été altéré après l'envoi.
Alors que SPF vérifie la légitimité au niveau réseau — l'adresse IP d'envoi —, DKIM est fondamentalement différent puisqu'il applique une signature numérique au contenu même du courriel. Ainsi, même si un message est retransmis plusieurs fois par des serveurs légitimes (un cas où SPF est reconnu pour mal se comporter), la signature DKIM reste valide tant que le corps du message n'est pas modifié. C'est pourquoi DKIM est jugé plus fiable que SPF sur les chemins de livraison impliquant un renvoi, comme les listes de diffusion.
Le mécanisme de sélecteur est également important en pratique. Lorsqu'un même domaine utilise plusieurs prestataires de messagerie (serveur interne, Gmail, SendGrid, etc.), attribuer à chacun une paire de clés et un nom de sélecteur distincts permet de révoquer ou de renouveler les clés indépendamment par prestataire. Cette souplesse opérationnelle — une clé compromise n'affectant que son propre sélecteur — explique en partie pourquoi DKIM, bien que reposant sur un simple enregistrement DNS, reste largement utilisé dans les infrastructures de messagerie à grande échelle.