Comment diviser un enregistrement DKIM

La configuration de l'authentification des e-mails fait partie de ces tâches qui semblent ne prendre que cinq minutes, jusqu'à ce que l'on se heurte à un obstacle. On génère sa clé DKIM sécurisée de 2048 bits, on se rend chez son fournisseur DNS, on la colle dans le champ d'un nouvel enregistrement TXT, puis on clique sur « Enregistrer ».

Au lieu d'un message de réussite, une erreur s'affiche à l'écran. AWS Route 53 affiche une alerte énigmatique intitulée « CharacterStringTooLong ». Google Cloud DNS vous indique sans détour que vous avez des « données d'enregistrement non valides ».

Si vous atteignez la limite de 255 caractères lors de l'ajout de votre enregistrement DKIM, ne vous inquiétez pas : votre clé est intacte et vous n'avez pas besoin de réduire votre niveau de sécurité. Il vous suffit de diviser correctement votre enregistrement TXT DKIM en plusieurs chaînes de caractères. La division d'un enregistrement DKIM est une procédure administrative standard et sûre ; une fois publiée, les résolveurs DNS réassembleront automatiquement les fragments de manière transparente.

Voyons en détail pourquoi ce problème survient et comment le résoudre étape par étape, que ce soit à la main ou à l'aide d'un outil de fractionnement automatique des enregistrements DNS.

Pourquoi les enregistrements DKIM doivent être fractionnés

La nécessité de fractionner les enregistrements DKIM découle des principes fondamentaux d'Internet. Conformément à la section 3.3.14 de la RFC 1035, une chaîne de caractères unique dans un enregistrement DNS TXT est limitée à 255 caractères (ou octets) au maximum. Cette limite s'explique par le fait que la longueur d'une chaîne dans un paquet DNS standard est stockée dans un seul octet, ce qui signifie qu'elle ne peut pas dépasser 255 caractères.

Cette limite structurelle revêt une importance particulière en fonction de la longueur de vos clés cryptographiques :

• Clés DKIM de 1 024 bits: ces chaînes de clés publiques sont courtes et respectent généralement la limite de 255 caractères sans qu'il soit nécessaire de les modifier.
• Clés DKIM de 2048 bits: ces clés offrent une sécurité nettement renforcée, mais génèrent une chaîne de clé publique en base64 qui compte presque toujours entre 350 et plus de 500 caractères.

Une clé DKIM de 2 048 bits dépassant par nature la limite de 255 caractères, elle ne peut pas tenir dans une seule chaîne de caractères continue.

La manière dont cette limite est gérée dépend entièrement de votre fournisseur d'hébergement DNS. En 2026, les principales plateformes se répartissent toujours en deux camps :

• Fournisseurs stricts: des services tels qu'AWS Route 53, Google Cloud DNS et Azure DNS appliquent strictement la norme RFC 1035 au niveau de l'interface utilisateur. Si vous collez une chaîne de 300 caractères, ils la rejettent immédiatement.
• Fournisseurs automatisés: des plateformes telles que Cloudflare, GoDaddy et cPanel gèrent souvent ce formatage en arrière-plan, en scindant l'enregistrement en interne afin que vous n'ayez pas à le faire manuellement.

Remarque importante: le fractionnement d'un enregistrement ne modifie ni ne rompt votre signature DKIM. Lorsqu'un serveur de messagerie entrant recherche la clé publique DKIM de votre domaine, son résolveur DNS concatène (fusionne) automatiquement les chaînes fractionnées en une seule chaîne continue avant de procéder à la négociation cryptographique.

Comment diviser un enregistrement DKIM (étape par étape)

Pour diviser correctement votre enregistrement sans invalider vos données cryptographiques, vous devez respecter des règles de mise en forme bien définies.

Voici un aperçu en direct d'un enregistrement DKIM brut de 2048 bits non fractionné, une chaîne unique et continue que les fournisseurs rigoureux rejetteront, suivi de la même clé correctement fractionnée :

Avant – une chaîne continue (410 caractères, rejetée) :

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApTyGJMuHbEL31IeL2HPcHyGcFRl1SPnXNYvMIHa/2o76umfXfKm/r5kJP1VrT+1FJors/6ILi8IHn5kxsC7tVO/HbkQfyy/KV5zjR3j1twdTKWTddB+XhkAS1voQG6yyzyN9zHYIa4UOrGNATMuDJawTgsu8PO+799nKSNrh9UCauSDmLhuVtcqcYezdZ/tDDj8hYs5suKcNd8Zra9A9sKPxZ9W3qLy7zKUVQDT7S8sTQCBNR3YbDgbleph1QHt61QTC4XATWS8PHp9NHfYjFM5DI4pZj59fhZ5R1Py4oJe2JbmPTuSgR7cMy+UcU3zr1ZtoLuCr64CxqlIOdNKhiwIDAQAB

À la suite de cela : un enregistrement TXT, deux chaînes entre guillemets séparées à la limite des 255 caractères :

« v=DKIM1 ; k=rsa ; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApTyGJMuHbEL31IeL2HPcHyGcFRl1SPnXNYvMIHa/2o76umfXfKm/r5kJP1VrT+1FJors/6ILi8IHn5kxsC7tVO/HbkQfyy/KV5zjR3j1twdTKWTddB+XhkAS1voQG6yyzyN9zHYIa4UOrGNATMuDJawTgsu8PO+799nKSNrh9UCauSDmLhuVtcqcYezdZ/tDD »
«j8hYs5suKcNd8Zra9A9sKPxZ9W3qLy7zKUVQDT7S8sTQCBNR3YbDgbleph1QHt61QTC4XATWS8PHp9NHfYjFM5DI4pZj59fhZ5R1Py4oJe2JbmPTuSgR7cMy+UcU3zr1ZtoLuCr64CxqlIOdNKhiwIDAQAB »

Fractionnement d'une clé DKIM de 2048 bits

v=DKIM1 ; k=rsa ; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…wIDAQAB

Une chaîne continue de 410 caractères rejetée par AWS Route 53 / Google Cloud DNS

↓ coupure à la limite des 255 caractères

Un seul enregistrement TXT — deux chaînes entre guillemets

« v=DKIM1 ; k=rsa ; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A… »

bloc 1 · 255 caractères

« …zrIZtoLuCr64CxqlIOdNKhiwIDAQAB »

bloc 2 · reste (≈155)

exactement un espace entre les blocs, sans aucun espace à l'intérieur de chacun d'eux.

Étape 1 : Identifiez votre enregistrement DKIM complet

Vous pouvez vous connecter au tableau de bord de votre fournisseur de messagerie (tel que Google Workspace, Microsoft 365, SendGrid ou Mailchimp) pour retrouver votre clé publique générée. L'enregistrement commence toujours par des balises spécifiques, généralement selon le format suivant :

v=DKIM1 ; k=rsa ; p=[Une très longue chaîne Base64]

Vous pouvez également utiliser notre outil gratuit de vérification des enregistrements DKIM pour vérifier votre enregistrement en quelques secondes :

Pour vérifier si le fractionnement est vraiment nécessaire, copiez l'intégralité de la valeur et collez-la dans un éditeur de texte simple afin de vérifier sa longueur totale. Si le nombre de caractères dépasse 255, vous devez la fractionner.

Étape 2 : Diviser la valeur de la clé en segments de 255 caractères

Vous avez deux possibilités pour diviser votre enregistrement : soit effectuer le calcul manuellement, soit utiliser un outil automatisé.

La méthode manuelle

Ouvrez votre éditeur de texte et comptez exactement 255 caractères à partir du début de votre enregistrement (y compris le préfixe « v=DKIM1; k=rsa; p= »). Coupez la chaîne exactement à cette limite de 255 caractères.

Vous devez placer chaque segment entre ses propres guillemets doubles (« »). Il est essentiel de veiller à ce qu'il n'y ait aucun espace à l'intérieur des segments, mais il doit y avoir exactement un seul espace entre le guillemet de fermeture du premier segment et le guillemet d'ouverture du second.

La méthode automatique (recommandée)

Pour éviter toute erreur humaine, renoncez au comptage manuel des caractères et utilisez l'outil gratuit DNS Record Splitter de PowerDMARC.

• Accédez à la page des outils.

• Collez l'intégralité de votre enregistrement TXT DKIM (sans le diviser) dans la zone de saisie.

• Sélectionnez le format « entre guillemets » (obligatoire pour certains fournisseurs stricts comme AWS et Google).

• Cliquez sur « Diviser l'enregistrement » pour générer instantanément des chaînes correctement formatées.

• Voici à quoi devrait ressembler le résultat :

Étape 3 : Ajouter l'enregistrement Split à votre DNS

Une erreur courante chez les administrateurs consiste à essayer de créer deux enregistrements TXT distincts dans leur panneau DNS, un pour chaque bloc. Ne le faites pas ; cela rendra l'authentification totalement impossible.

Vous devez ajouter un seul enregistrement TXT. Dans votre interface de gestion DNS, collez les deux chaînes de caractères entre guillemets dans le champ « Valeur » ou « Données ». Pour la plupart des fournisseurs standard, séparez-les par un seul espace :

« v=DKIM1 ; k=rsa ; p=CHUNK1 » « CHUNK2 »

(Remarque : si vous utilisez AWS Route 53, ignorez le format à espace unique et suivez la méthode de saut de ligne spécifique à la plateforme indiquée dans la section consacrée au fournisseur ci-dessous.)

Étape 4 : Vérifier l'enregistrement DKIM

Une fois vos modifications enregistrées, prévoyez un délai pour la propagation du DNS sur Internet. Bien que cette mise à jour s'effectue généralement en 5 à 30 minutes, elle peut parfois prendre jusqu'à 48 heures, en fonction des paramètres TTL (Time to Live) de votre zone.

Pour vous assurer que tout fonctionne parfaitement, utilisez l'outil gratuit de vérification DKIM de PowerDMARC afin de vérifier que votre enregistrement est bien publié et qu'il se résout correctement.

Conseil de pro: si vous souhaitez vérifier votre travail avant d'attendre la propagation du DNS, copiez la chaîne finale que vous avez créée et collez-la à nouveau dans l'outil de fractionnement d'enregistrements DKIM pour vous assurer qu'aucun segment ne dépasse la limite de 255 caractères.

Si le test est réussi, vous obtiendrez votre clé cryptographique complète et unifiée, accompagnée d'un statut « vert ». En cas d'échec, vérifiez s'il y a des problèmes tels que des données tronquées (données manquantes), un bloc secondaire manquant ou des erreurs de syntaxe dues à des guillemets non fermés.

Répartition des enregistrements DKIM par fournisseur DNS

Les différents panneaux de configuration DNS gèrent les entrées TXT à plusieurs chaînes de caractères de manière différente. Voici comment procéder sur les quatre plateformes les plus courantes :

AWS Route 53

Amazon Route 53 applique strictement les limites et renvoie une erreur « CharacterStringTooLong » si une chaîne de caractères ne comporte pas de guillemets ou dépasse 255 caractères. Étant donné que les résolveurs DNS concatènent les chaînes de caractères consécutives sans aucun espace entre elles, l'insertion d'un espace littéral entre vos guillemets sur une même ligne peut accidentellement corrompre votre clé cryptographique.

• Méthode via la console: dans le champ « Value » (Valeur ) de la console Route 53, saisissez chaque segment sous forme de chaîne de caractères entre guillemets, sur une ligne distincte. Ne laissez pas d'espace à la fin de la ligne. Route 53 traite par défaut les lignes consécutives saisies dans un même champ de texte comme des chaînes distinctes au sein d'un seul enregistrement TXT et les assemble lors d'une requête.
• Méthode API/JSON: si vous déployez votre infrastructure via du code ou l'API AWS, structurez votre entrée d'enregistrement sous la forme d'un tableau JSON dans lequel chaque bloc séparé correspond à un élément indépendant du tableau : [“v=DKIM1…”, “…CHUNK2”].

DNS Google Cloud

Google Cloud DNS affichera un avertissement générique indiquant « données d'enregistrement non valides » si vous essayez de soumettre une longue chaîne non formatée. Pour résoudre ce problème dans l'interface utilisateur de la Google Cloud Console, ne collez pas cette chaîne sur une seule ligne. Placez plutôt chaque partie entre guillemets doubles et utilisez le bouton « Ajouter un élément » pour générer plusieurs champs de données consécutifs au sein du même ensemble d'enregistrements de ressources.

Cloudflare

Cloudflare dispose d'un backend intelligent qui analyse automatiquement les longues chaînes TXT lors de leur enregistrement, en les divisant en segments conformes à la norme RFC sans intervention de l'utilisateur. Cependant, le recours à l'analyse automatisée peut parfois entraîner des cas particuliers avec des clés complexes. La meilleure pratique de déploiement reste de coller manuellement vos chaînes pré-divisées et entre guillemets directement dans le tableau de bord Cloudflare.

cPanel / WHM

Les anciennes versions de l'éditeur de zone cPanel imposent une limite stricte de 255 caractères dans les champs de saisie de texte standard. Si votre interface principale ne prend pas en charge cette longueur, passez à l'éditeur de zone DNS avancé. Ce mode étendu offre la flexibilité structurelle nécessaire pour saisir sans difficulté des champs de données TXT pré-divisés en plusieurs segments.

Erreurs courantes lors de la division des enregistrements DKIM

Si vous avez déployé votre enregistrement fractionné mais que les outils de vérification de l'authentification signalent un problème avec votre domaine, vérifiez si vous n'avez pas commis l'une de ces trois erreurs de configuration courantes :

1. Échec de la signature DKIM après le fractionnement

• La cause: un espace a été inséré par inadvertance à l'intérieur de l'un de vos blocs cryptographiques Base64, au lieu d'être strictement placé entre les guillemets ouvrants et fermants.
• Solution: Copiez votre clé brute dans un fichier vierge, supprimez tous les espaces internes de la chaîne de caractères « p= », puis relancez le processus de fractionnement.

2. Le DNS n'affiche qu'une partie de la clé

• La cause: la deuxième partie a été enregistrée sous la forme d'un enregistrement TXT secondaire distinct sur votre hébergeur de domaine, au lieu d'être intégrée au premier enregistrement.
• Solution: Supprimez complètement l'enregistrement secondaire. Modifiez votre enregistrement TXT DKIM principal de manière à ce que les deux chaînes entre guillemets figurent ensemble dans le champ de valeur unique.

3. L'enregistrement dépasse 255 caractères après le fractionnement

• La cause: le point de fractionnement a été mal calculé, ce qui a fait que l'un des deux segments dépassait légèrement la limite de 255 caractères (souvent en comptant de manière erronée le préfixe « v=DKIM1; »).
• Solution: divisez à nouveau votre enregistrement exactement au 255e caractère, ou confiez le comptage à un outil automatisé de division des enregistrements DNS.

Comment la division du DKIM affecte le DMARC

Une question qui préoccupe souvent les responsables informatiques est de savoir si le fractionnement d'une clé publique modifie la manière dont le traitement DMARC gère les messages entrants.

Lorsqu'un enregistrement DKIM est fragmenté correctement, il se comporte exactement comme un enregistrement non fragmenté. Étant donné que les serveurs de messagerie destinataires réassemblent les fragments en une seule chaîne lors de la vérification, vos signatures DKIM sont validées sans problème, ce qui n'affecte en rien votre alignement DMARC.

Cependant, si votre enregistrement fractionné est mal formé ou mal formaté, les conséquences sont immédiates :

• Le serveur de messagerie destinataire ne pourra pas reconstituer votre clé publique.
• L'authentification DKIM échouera.
• DMARC sera contraint de se fonder entièrement sur la conformité de votre SPF Sender Policy Framework).
• Si SPF échoue également (ou si votre politique DMARC exige que les deux protocoles soient alignés), vos e-mails professionnels légitimes seront redirigés vers les dossiers de courrier indésirable ou risquent d'être purement et simplement rejetés.

Avant de vous fier entièrement à l'application de votre politique DMARC, vous devez valider vos clés DKIM publiques après avoir effectué toute modification du DNS.

Résumé

La division d'un enregistrement DKIM est une étape administrative indispensable lors de la gestion de clés sécurisées de 2048 bits sur des fournisseurs DNS rigoureux tels qu'AWS Route 53 ou Google Cloud DNS. Il s'agit d'une procédure sûre et standard, facile à mettre en œuvre une fois que l'on connaît les règles de formatage de base.

Chaque fois que vous mettez à jour vos dossiers, n'oubliez pas les règles fondamentales :

• Séparez votre chaîne au niveau de la limite des 255 caractères.
• Entourez chaque bloc de guillemets doubles.
• Veillez à regrouper toutes les informations dans un seul enregistrement TXT (séparées par un espace pour les fournisseurs classiques, ou sur des lignes distinctes pour les interfaces strictes comme AWS Route 53).

Ne vous fiez pas à vos estimations concernant le nombre de caractères et ne prenez pas le risque de voir vos e-mails ne plus fonctionner. Évitez les calculs manuels et formatez votre clé en un clin d'œil grâce à l'outil gratuit PowerDMARC DNS Record Splitter, sans inscription requise.

Foire aux questions

Qu'est-ce qu'un séparateur d'enregistrements DNS ?

Un séparateur d'enregistrements DNS est un utilitaire conçu pour diviser un long enregistrement DNS de type TXT en segments individuels de 255 caractères. Cette étape de mise en forme est nécessaire pour que vos enregistrements puissent être enregistrés correctement chez les hébergeurs DNS stricts qui n'effectuent pas automatiquement le fractionnement interne des chaînes de caractères. La valeur absolue de votre enregistrement reste inchangée ; il est simplement formaté en blocs structurés plus courts que les systèmes destinataires réassemblent immédiatement lors d'une requête.

Quels sont les fournisseurs de DNS qui nécessitent un fractionnement manuel des enregistrements ?

Plusieurs grands fournisseurs de solutions d'entreprise appliquent strictement la limite de 255 caractères au niveau de leur interface, ce qui vous oblige à préformater les valeurs de texte longues avant de les enregistrer :

• AWS Route 53: génère un message d'erreur « CharacterStringTooLong » à moins que les chaînes longues ne soient divisées en plusieurs blocs entre guillemets.
• Google Cloud DNS: rejette systématiquement les chaînes de caractères longues et continues, ce qui génère un avertissement indiquant « données d'enregistrement non valides ».
• DNS Azure: nécessite de diviser et de séparer manuellement les champs de texte lors de la création de chaînes de caractères directement via le tableau de bord du portail Azure ou l'interface de ligne de commande Azure (Azure CLI).
• DigitalOcean: ne divise pas automatiquement les longues chaînes de données TXT dans son panneau de contrôle web standard.

Pourquoi dois-je diviser mon enregistrement DKIM ?

Le principal facteur déclencheur du fractionnement d'un enregistrement TXT est le déploiement d'une clé publique DKIM hautement sécurisée de 2048 bits. Alors que les clés de 1 024 bits sont suffisamment courtes pour tenir dans une seule chaîne de caractères, une clé de 2 048 bits contient intrinsèquement entre 350 et plus de 500 caractères de données cryptographiques en base64. La section 3.3.14 de la RFC 1035 limitant une chaîne continue unique à exactement 255 octets, ces longues clés doivent être divisées en segments distincts pour s'adapter à l'architecture de stockage DNS standard.

Le fait de diviser mon enregistrement va-t-il modifier ses données ou empêcher la validation de l'adresse e-mail ?

Non. Le fractionnement d'un long enregistrement TXT n'endommage ni ne modifie sa valeur cryptographique. Lorsqu'un serveur de messagerie récepteur demande les paramètres d'authentification de votre domaine, son résolveur DNS lit automatiquement les segments fractionnés et les concatène (fusionne) pour former une valeur continue sans délimiteurs. Le format fractionné n'est qu'un détail de stockage en arrière-plan ; la charge utile évaluée reste identique.

Quelle est la différence entre les formats de sortie « entre guillemets » et « sans guillemets » ?

• Format entre guillemets (recommandé): chaque segment de 255 caractères est placé entre une paire de guillemets doubles (« chunk1 » « chunk2 »), soit séparés par un espace sur une seule ligne, soit saisis dans des champs ou des lignes de données consécutifs. Cette mise en forme précise est requise par des interfaces strictes telles qu’AWS Route 53 et Google Cloud DNS afin d’éviter toute corruption des clés.
• Format brut: divise les lignes longues en blocs distincts sans ajouter de guillemets ni d'espaces ou de caractères de ponctuation supplémentaires. Cette mise en page est destinée aux panneaux de configuration modernes qui acceptent des flux de chaînes brutes sur plusieurs lignes ou aux environnements système BIND (Berkeley Internet Name Domain) auto-hébergés.

Peut-on utiliser cet outil en toute sécurité avec des clés sensibles ou des données confidentielles ?

Oui. Le PowerDMARC DNS Record Splitter fonctionne entièrement au sein de votre navigateur Web local à l'aide de scripts côté client. Les chaînes de texte que vous saisissez ne quittent jamais votre appareil, aucune donnée n'est transmise via Internet à des serveurs de traitement externes, et aucun journal de suivi ni inscription obligatoire n'est requis. De plus, il est important de noter que l'outil est conçu exclusivement pour les configurations publiques, telles que les clés DKIM publiques, SPF , les politiques DMARC ou les enregistrements de vérification de domaine, qui sont déjà accessibles publiquement sur le Web. Les clés de signature privées ne doivent jamais être collées dans un outil en ligne.

• À propos de
• Derniers messages

Yunes Tarada

Expert en sécurité des domaines et des courriels chez PowerDMARC

Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.

Derniers messages de Yunes Tarada (voir tous)

• Comment diviser un enregistrement DKIM - 5 juin 2026
• compauth=fail : tout savoir sur l'authentification composite Microsoft - 1er juin 2026
• Windows Defender suffit-il pour assurer la sécurité des petites entreprises ? - 14 mai 2026