Formateur d’enregistrement TXT DKIM
Formater les enregistrements DKIM avec les guillemets corrects
DKIM Record Value
Enter a DKIM record to format and validate
Le Formateur d'enregistrement TXT DKIM convertit les clés publiques DKIM en enregistrements DNS TXT correctement formatés, conformes à la limite de 255 caractères par chaîne. Collez une clé publique encodée en base64, comme une clé RSA 2048 bits, et obtenez un enregistrement correctement découpé, prêt à être intégré dans un fichier de zone, pour un sélecteur tel que google._domainkey.example.com.
Comprendre les enregistrements DKIM
DKIM est le mécanisme d'authentification e-mail qui prouve qu'un message n'a pas été altéré pendant le transit. Lorsque votre serveur de messagerie envoie un e-mail, il génère une signature cryptographique sur les en-têtes et le corps du message à l'aide d'une clé privée. La clé publique correspondante est publiée dans le DNS pour que les serveurs destinataires puissent la consulter et vérifier la signature. Si la signature est valide, le destinataire sait que le message a véritablement été envoyé par votre domaine et qu'il n'a pas été modifié en chemin.
La difficulté avec DKIM n'est pas la cryptographie -- votre serveur de messagerie s'en charge automatiquement. La difficulté est d'intégrer correctement la clé publique dans le DNS. Une clé RSA 2048 bits produit une chaîne base64 d'environ 392 caractères, mais une seule chaîne d'enregistrement DNS TXT ne peut contenir que 255 caractères. Si vous collez la clé directement dans la plupart des interfaces de fournisseurs DNS, elle sera soit tronquée silencieusement (cassant la vérification DKIM), soit le fournisseur la rejettera avec un message d'erreur confus. La clé doit être découpée en plusieurs chaînes entre guillemets au sein d'un même enregistrement TXT, et le découpage doit être effectué correctement pour que les résolveurs DNS puissent la réassembler.
Ce formateur gère le découpage pour vous. Vous collez votre clé publique, spécifiez le nom du sélecteur et les tags DKIM optionnels, et il produit l'enregistrement DNS complet dans le format correct -- prêt à être collé dans un fichier de zone BIND ou dans l'interface web de votre fournisseur DNS. Il prévient les erreurs de formatage subtiles qui provoquent des échecs de validation DKIM, notoirement difficiles à diagnostiquer car les symptômes (e-mails marqués comme spam ou rejetés) ne pointent pas de manière évidente vers un problème de formatage DNS.
Comment formater un enregistrement TXT DKIM
- Collez votre clé publique DKIM (généralement une clé RSA 2048 bits encodée en base64)
- Saisissez le nom de votre sélecteur (ex. :
google,s1,default) - Sélectionnez le type de clé -- RSA est le standard, Ed25519 est émergent
- Configurez les tags DKIM optionnels tels que le mode test (
t=y) ou le type de service (s=email) - Le formateur découpe la clé en chaînes entre guillemets de 255 caractères avec la syntaxe correcte
- Copiez l'enregistrement formaté pour votre fichier de zone DNS ou l'interface de votre fournisseur
Exemples de format d'enregistrement DKIM
Clé courte (RSA 1024 bits) -- Chaîne unique
selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3QEKyU1fSma0axspqYK49aE..."
Clé longue (RSA 2048 bits) -- Découpage multi-chaînes requis
selector._domainkey.example.com. IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2UMfREvlgajdSp3jv1oI"
"k5LDXFMxqsmSZMTpNEm0MKhDlMlSGbNyERxMnpPQKHlkNPPsFKdXJQsaJFcFP1ab"
"jCNRQaSwrztEOLGhSV1YlfS0MkIm8v5LqlkFRm0+3kOpE+RSI0E/9IMERJ3v5ggJ"
"QIDAQAB"
)
Format de fichier de zone BIND
google._domainkey IN TXT ( "v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
"...base64data..."
"QIDAQAB" )
Référence des tags DKIM
| Tag | Requis | Exemple | Description |
|---|---|---|---|
v | Recommandé | v=DKIM1 | Identifiant de version |
k | Optionnel | k=rsa | Type de clé (par défaut : rsa) |
p | Requis | p=MIIBIj... | Clé publique encodée en base64 |
t | Optionnel | t=y | Mode test -- les vérificateurs ne doivent pas agir sur les échecs |
s | Optionnel | s=email | Type de service (par défaut : * pour tous) |
h | Optionnel | h=sha256 | Algorithmes de hachage acceptés |
Quand utiliser le formateur DKIM
- Mise en place de la signature DKIM pour un nouveau domaine et publication de la clé publique dans le DNS
- Rotation des clés DKIM de RSA 1024 bits vers 2048 bits pour une sécurité renforcée
- Ajout de nouveaux sélecteurs pour différents flux de messagerie (marketing, transactionnel, corporate)
- Migration de fournisseur DNS et saisie des enregistrements DKIM dans un format d'interface différent
- Dépannage des échecs DKIM causés par un formatage incorrect ou une troncature de l'enregistrement TXT
- Déploiement de multiples clés de signature lorsque différents services (Google, SendGrid, Postmark) nécessitent chacun leur propre sélecteur
Fonctionnement des enregistrements DNS DKIM
Structure du sélecteur et du domaine
Les clés publiques DKIM sont publiées à un emplacement DNS spécifique suivant le modèle :
<selector>._domainkey.<domain>
Par exemple, si votre sélecteur est google et votre domaine est example.com, l'enregistrement se trouve à google._domainkey.example.com. Le sélecteur permet d'avoir plusieurs clés DKIM par domaine -- une pour chaque source de signature.
La limite de 255 caractères par chaîne
Les enregistrements DNS TXT stockent les données dans des chaînes individuelles de 255 caractères maximum. Une clé publique RSA 2048 bits encodée en base64 représente environ 392 caractères pour les données de la clé seule, plus les tags DKIM. L'enregistrement total dépasse facilement 255 caractères, nécessitant le découpage de la valeur en plusieurs chaînes entre guillemets.
Les résolveurs DNS concatènent automatiquement les multiples chaînes d'un enregistrement TXT en une seule valeur. Les points de découpage peuvent se situer n'importe où dans les données -- même au milieu d'un mot -- car la concaténation s'effectue au niveau des octets, et non au niveau sémantique.
Considérations sur la taille des clés
| Taille de clé | Longueur base64 | Découpage multi-chaînes nécessaire ? |
|---|---|---|
| RSA 1024 bits | ~216 caractères | Généralement non |
| RSA 2048 bits | ~392 caractères | Oui |
| RSA 4096 bits | ~736 caractères | Oui, plusieurs découpages |
| Ed25519 | ~44 caractères | Non |
RSA 2048 bits est la norme actuelle de l'industrie. Les clés inférieures à 1024 bits sont considérées comme non sécurisées et peuvent être rejetées par les destinataires. Les clés Ed25519 sont beaucoup plus courtes mais ne sont pas encore universellement prises en charge.
Gestion des clés DKIM en pratique
L'erreur la plus courante lors du déploiement DKIM est de publier la clé incorrectement sans la vérifier ensuite. Après avoir ajouté l'enregistrement TXT dans le DNS, confirmez toujours sa présence en interrogeant l'enregistrement avec un outil comme dig ou nslookup et en comparant la valeur retournée avec la clé publique originale. La propagation DNS peut prendre de quelques minutes à plusieurs heures selon vos paramètres de TTL, attendez donc de manière appropriée avant de tester. Une vérification rapide consiste à exécuter dig TXT selector._domainkey.example.com et à vérifier que la clé base64 complète apparaît dans la réponse sans troncature.
La rotation des clés est un autre domaine où les administrateurs trébuchent souvent. La bonne pratique consiste à générer une nouvelle paire de clés avec un nouveau sélecteur, publier la nouvelle clé publique dans le DNS, attendre la propagation, basculer votre serveur de messagerie pour signer avec la nouvelle clé privée, et seulement ensuite supprimer l'ancienne clé publique du DNS. Si vous supprimez l'ancienne clé avant que tous les messages en transit aient été livrés et vérifiés, ces messages échoueront aux contrôles DKIM. Une bonne approche est de conserver l'ancienne clé publiée pendant au moins une semaine après le changement de sélecteur.
Lors de la première configuration de DKIM, utilisez le flag de test t=y initialement. Cela indique aux serveurs destinataires que votre domaine est en mode test DKIM et qu'ils ne doivent pas agir sur les échecs de vérification. Une fois que vous avez confirmé que la signature fonctionne correctement en consultant les rapports agrégés DMARC, supprimez le flag t=y pour activer l'application complète. Laisser t=y en place de manière permanente compromet la valeur sécuritaire de DKIM, car les destinataires ignoreront les échecs.
Questions fréquentes
Pourquoi mon enregistrement DKIM échoue-t-il à la validation après l'avoir collé dans le DNS ?
La cause la plus courante est un découpage incorrect des chaînes. Si votre fournisseur DNS ne prend pas en charge les enregistrements TXT multi-chaînes ou tronque les valeurs longues, les données de la clé publique sont incomplètes et la vérification DKIM échouera. Utilisez ce formateur pour garantir un découpage correct, puis vérifiez que l'enregistrement publié correspond à la valeur attendue avec dig TXT selector._domainkey.votredomaine.com.
Puis-je avoir plusieurs enregistrements DKIM pour un même domaine ?
Oui. Contrairement au SPF, DKIM prend en charge plusieurs clés via différents sélecteurs. Chaque système de messagerie (Google Workspace, SendGrid, Mailchimp) utilise son propre sélecteur, évitant ainsi les conflits entre les clés. Par exemple, google._domainkey.example.com et sendgrid._domainkey.example.com coexistent sans problème.
Que fait t=y (mode test) ?
Lorsque t=y est défini, les serveurs de messagerie destinataires doivent traiter les échecs de vérification DKIM comme si le domaine n'était pas signé. Cela vous permet de publier une clé DKIM et de commencer à signer les e-mails sans risque d'échec de livraison pendant que vous vérifiez la configuration. Supprimez t=y une fois les tests terminés pour activer l'application complète de DKIM.
Dois-je utiliser des clés RSA 2048 bits ou 4096 bits ?
RSA 2048 bits est le standard actuel et est accepté par tous les principaux fournisseurs de messagerie. Bien que les clés 4096 bits offrent une sécurité plus forte, elles produisent des enregistrements TXT très longs que certains fournisseurs DNS ont du mal à gérer, et elles augmentent la taille des en-têtes de signature DKIM dans chaque e-mail. L'amélioration de sécurité par rapport au 2048 bits est marginale pour l'authentification e-mail. Utilisez le 2048 bits sauf si votre politique de sécurité exige spécifiquement des clés plus longues.
Qu'est-ce qu'Ed25519 et dois-je l'utiliser ?
Ed25519 est un algorithme à courbe elliptique qui produit des clés (~44 caractères) et des signatures beaucoup plus courtes que RSA, rendant les enregistrements DNS et les en-têtes e-mail plus compacts. Cependant, le support DKIM Ed25519 n'est pas encore universel parmi les serveurs de messagerie destinataires. Si vous adoptez Ed25519, publiez à la fois une clé Ed25519 et une clé RSA 2048 bits sous des sélecteurs différents, et signez avec les deux. Les destinataires qui supportent Ed25519 l'utiliseront ; les autres se rabattront sur RSA.
Outils associés
- Générateur d'enregistrement SPF - Créer des enregistrements SPF avec la syntaxe correcte
- Générateur d'enregistrement DMARC - Créer des enregistrements DMARC avec tous les tags de politique
- Vérificateur de longueur d'enregistrement SPF - Vérifier la longueur et les limites de résolutions des enregistrements SPF
- Dédoublonneur d'enregistrements DNS - Trouver et supprimer les enregistrements DNS en double
- Linter de fichier de zone - Vérifier les fichiers de zone pour les erreurs de syntaxe et les doublons