Dépannage des enregistrements DNS pour l'e-mail : longueur des TXT, TTL, propagation et particularités des registrars

Un bon dépannage des enregistrements DNS pour l'e-mail commence par un constat désagréable : lorsque SPF, DKIM ou un CNAME de suivi refuse de se vérifier, la cause est rarement l'enregistrement que vous vouliez publier. C'est généralement la manière dont votre interface DNS l'a stocké. Une clé de plus de 255 caractères, un nom de domaine ajouté deux fois, une paire de guillemets devenue partie intégrante de la valeur, un second enregistrement SPF, ou une ancienne réponse qui n'a pas encore expiré d'un cache. Nous allons passer en revue chacun de ces cas, montrer comment les contrôler avec dig et nslookup, et terminer par un tableau à consulter selon le symptôme.

Comment les enregistrements e-mail vivent dans le DNS

Chaque méthode d'authentification e-mail repose sur une poignée de types d'enregistrements. SPF et DKIM sont publiés sous forme d'enregistrements TXT, DMARC est un enregistrement TXT placé sous un nom commençant par _dmarc, et de nombreuses plateformes d'envoi demandent des enregistrements CNAME pour un nom d'hôte de return-path ou de suivi. Les enregistrements MX acheminent le courrier entrant. Un résolveur demande un nom et un type, et la réponse porte une durée de vie, ou TTL, qui indique à chaque cache pendant combien de temps il peut la réutiliser.

Trois points expliquent la plupart des difficultés. Premièrement, les interfaces DNS sont des façades conviviales au-dessus d'une zone, et chacune fait ses propres choix en matière de noms, de guillemets et de découpage. Deuxièmement, les caches existent à plusieurs niveaux, de sorte que le même nom peut donner des réponses différentes selon l'endroit pendant un certain temps. Troisièmement, certains types d'enregistrements s'excluent mutuellement sous un même nom. Nous couvrons l'ensemble des enregistrements dans notre guide d'authentification et le processus de vérification dans la vérification de votre domaine d'envoi. Cet article en est le complément de diagnostic.

Vérifier d'abord au bon endroit : les serveurs de noms faisant autorité

Avant de modifier quoi que ce soit, déterminez ce qui est réellement publié. Un résolveur public, comme celui qu'utilise votre ordinateur portable, peut conserver une ancienne réponse. Les serveurs de noms faisant autorité sont ceux qui hébergent votre zone et donnent la réponse définitive : nous les interrogeons donc toujours en premier.

# 1. Find the authoritative nameservers for the domain
dig NS example.com +short

# 2. Ask one of them directly for the record (no cache involved)
dig TXT selector1._domainkey.example.com @ns1.dns-host.example +noall +answer

# 3. Compare with what a public resolver says
dig TXT selector1._domainkey.example.com @9.9.9.9 +noall +answer

# 4. Check the TTL and the negative caching value
dig SOA example.com @ns1.dns-host.example +noall +answer

# nslookup equivalent
nslookup -type=TXT selector1._domainkey.example.com ns1.dns-host.example

Si la réponse faisant autorité est erronée, le problème se trouve dans l'interface : corrigez l'enregistrement. Si la réponse faisant autorité est correcte et que le résolveur public diffère, le problème vient d'un cache : patientez. Si les deux sont corrects et que la vérification échoue encore, vous contrôlez probablement le mauvais nom, ou la plateforme attend un autre type d'enregistrement. Cette simple comparaison élimine plus d'hypothèses que n'importe quoi d'autre dans cet article.

Chaînes TXT de plus de 255 caractères et clés DKIM de 2048 bits

Un enregistrement TXT contient une ou plusieurs chaînes de caractères, et chacune est limitée à 255 octets. Cela vient du format DNS d'origine défini dans la RFC 1035, qui stocke chaque chaîne avec une longueur sur un octet. Un enregistrement peut contenir plusieurs chaînes, et pour SPF comme pour DKIM le récepteur les assemble dans l'ordre sans ajouter d'espaces. Les spécifications des deux le précisent (RFC 7208 pour SPF, RFC 6376 pour DKIM).

L'impact pratique concerne DKIM. Une clé publique RSA de 1024 bits en base64 frôle la limite une fois ajoutées les balises de version et de type de clé, tandis qu'une clé de 2048 bits est environ deux fois plus longue, de sorte que la valeur p= seule compte plusieurs centaines de caractères. Elle doit être stockée sous forme de plusieurs chaînes. Notre guide sur la rotation des clés DKIM, les sélecteurs et la longueur des clés explique pourquoi les clés de 2048 bits valent l'effort.

Comportement de votre interface	Ce que vous devez faire	Comment vérifier
Découpe automatiquement les valeurs longues	Collez la valeur complète une seule fois, sans guillemets ni sauts de ligne	dig affiche plusieurs chaînes entre guillemets qui, mises bout à bout, forment la clé complète
Attend que vous saisissiez des segments entre guillemets	Découpez à n'importe quel endroit en dessous de 255 caractères, placez chaque partie entre guillemets, séparez par un seul espace	Le texte assemblé est exactement identique à la clé d'origine
Refuse les valeurs de plus de 255 caractères	Cherchez un paramètre pour les enregistrements longs ou un autre éditeur d'enregistrements ; demandez à l'hébergeur s'il n'y en a pas	La requête renvoie la clé complète, pas une clé tronquée
Tronque la valeur silencieusement	Saisissez-la de nouveau en segments et relisez le résultat	Une clé qui se termine trop tôt fait échouer DKIM avec une erreur de clé ou de syntaxe

À quoi ressemble un découpage correct

L'exemple ci-dessous montre la forme d'un enregistrement découpé. Le texte de la clé est inventé et raccourci à titre d'illustration. Dans un enregistrement réel, les segments forment ensemble la clé complète fournie par votre plateforme.

selector1._domainkey.example.com. 3600 IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA"
  "q1x2example0invented0key0chunk0one0aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
  "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
  "IDAQAB" )

Deux pièges sont fréquents. N'ajoutez pas d'espace à l'intérieur de la clé lorsque vous la découpez, car le récepteur concatène les chaînes et un espace deviendrait une partie de la clé. Et ne coupez pas l'enregistrement au milieu du nom du sélecteur ou des balises. Si une clé découpée échoue, comparez le résultat assemblé à l'original, caractère par caractère, avec un outil de comparaison de texte plutôt qu'à l'œil nu.

Particularités des registrars et des interfaces DNS

Le même enregistrement peut être saisi de quatre façons différentes dans quatre interfaces. Voici les particularités que nous rencontrons le plus souvent.

Le domaine est ajouté deux fois

De nombreuses interfaces ajoutent automatiquement le nom de la zone. Si vous saisissez selector1._domainkey.example.com dans le champ d'hôte, l'interface peut stocker selector1._domainkey.example.com.example.com. Le symptôme : l'enregistrement existe dans l'interface, mais une requête sur le bon nom ne renvoie rien. Saisissez uniquement la partie relative, selector1._domainkey, et utilisez @ ou laissez le champ vide pour l'apex, selon l'interface. Un point final marque normalement un nom comme complet dans les fichiers de zone, mais les interfaces web diffèrent ; relisez donc le nom enregistré avec dig.

Guillemets, sauts de ligne et caractères invisibles

Copier une valeur depuis une page web ou un document peut amener avec elle des guillemets typographiques, des espaces insécables ou un saut de ligne. Si l'interface ajoute aussi ses propres guillemets, vous pouvez vous retrouver avec un guillemet littéral au début de la valeur, et un enregistrement qui commence par un guillemet ne commence pas par v=spf1 ou v=DKIM1 : il n'est donc pas reconnu. Collez d'abord dans un éditeur de texte brut, puis dans l'interface, et relisez le résultat.

Mauvais type d'enregistrement ou mauvais nom

Les plateformes demandent parfois un enregistrement TXT là où vous attendriez un CNAME, ou l'inverse. Utilisez le type exactement comme indiqué. Vérifiez aussi que vous êtes dans la bonne zone : si le domaine utilise des serveurs de noms chez un fournisseur mais que vous avez modifié la zone chez votre registrar, la modification n'est jamais servie. La requête NS présentée plus haut vous indique où se trouve la zone active.

Symptôme dans l'interface	Cause probable	Correction
L'enregistrement affiche le domaine deux fois dans le nom	L'interface a ajouté la zone à un nom complet	Saisissez uniquement le nom relatif
La valeur commence et se termine par des guillemets, une seule fois, dans la sortie d'une requête uniquement	Comportement normal de la sortie TXT de dig	Aucune modification nécessaire
La valeur contient des guillemets échappés ou un guillemet au début	Vous avez ajouté des guillemets et l'interface a ajouté les siens	Retirez vos guillemets
Enregistrement sauvegardé mais la requête ne renvoie rien	Vous avez modifié une zone que les serveurs de noms actifs ne servent pas	Modifiez la zone chez le fournisseur indiqué par les enregistrements NS
L'interface n'accepte pas de tiret bas dans le nom	Règle de validation des noms dans l'interface	Utilisez un autre mode d'édition ou contactez le fournisseur DNS

CNAME à l'apex, aplatissement et conflits d'enregistrements

Un CNAME indique qu'un nom est un alias d'un autre nom, de sorte que le résolveur doit le suivre et utiliser les réponses obtenues à cet endroit. Pour cette raison, un CNAME ne peut coexister avec aucun autre enregistrement sous le même nom (RFC 1034 et RFC 2181). La racine de votre domaine, l'apex, doit porter des enregistrements SOA et NS, et comporte généralement aussi des MX et des TXT : un CNAME à l'apex n'est donc pas valide.

Certains fournisseurs DNS contournent cette limite grâce à l'aplatissement ou à un type d'enregistrement alias. Le fournisseur résout lui-même la cible et renvoie des enregistrements d'adresse ordinaires à l'apex. Cela aide à faire pointer l'adresse web de votre racine vers un service hébergé. Cela n'aide pas pour l'authentification e-mail. Si une plateforme demande un CNAME sur un nom d'hôte tel qu'un sous-domaine, placez-le sur ce sous-domaine. Si une plateforme demande un CNAME sur le domaine nu, demandez-lui une alternative, comme des enregistrements TXT et d'adresse.

Le conflit joue aussi dans l'autre sens. Si vous ajoutez un CNAME pour un nom qui possède déjà un enregistrement TXT, par exemple un sélecteur DKIM que vous aviez publié auparavant en TXT, l'un des deux sera rejeté ou ignoré, selon l'interface. Supprimez l'ancien enregistrement avant d'ajouter le CNAME. Cette situation est courante lors d'un changement de fournisseur, et notre guide de migration détaille l'ordre des étapes.

Enregistrements SPF en double et autres doublons

Un domaine ne peut publier qu'un seul enregistrement SPF, c'est-à-dire un enregistrement TXT commençant par v=spf1. Si les récepteurs en trouvent deux, le résultat est une erreur permanente (RFC 7208), et SPF échoue pour tous les messages, pas seulement ceux d'un seul prestataire. Cela se produit lorsque deux équipes ajoutent chacune l'enregistrement demandé par leur prestataire.

Situation	Ce que voient les récepteurs	Correction
Deux enregistrements TXT commençant tous deux par v=spf1	Erreur permanente, SPF n'est pas validé	Fusionnez-les en un seul enregistrement contenant tous les mécanismes include
Un enregistrement, plus de 10 requêtes DNS	Erreur permanente une fois la limite de requêtes atteinte	Aplatissez ou supprimez des includes ; consultez le guide sur les requêtes SPF
Deux enregistrements DMARC sous _dmarc	La politique peut être ignorée	Conservez un seul enregistrement
Même sélecteur publié deux fois avec des clés différentes	Sélection de clé imprévisible	Supprimez l'ancienne clé ou utilisez un nouveau sélecteur

La fusion est simple en principe : prenez les mécanismes include et ip4 de chaque enregistrement, placez-les dans un seul enregistrement v=spf1, et terminez par un unique qualificateur all. Le plus difficile est le décompte des requêtes, que nous expliquons dans le guide sur l'erreur permanente SPF et dans la gestion de plusieurs prestataires sur un même domaine.

Enregistrements proxifiés : désactivez le proxy DNS pour la messagerie

Certains fournisseurs DNS proposent un mode proxy, souvent représenté par une icône de nuage colorée à côté d'un enregistrement. Dans ce mode, le fournisseur répond aux requêtes sur le nom avec ses propres adresses et fait transiter le trafic web par son réseau. C'est utile pour les sites web et inadapté pour la messagerie.

Si un CNAME lié à la messagerie est proxifié, la requête ne renvoie plus la cible attendue par votre plateforme d'envoi. La vérification échoue, les noms d'hôte de return-path ou de suivi ne se résolvent pas vers le bon serveur, et les certificats HTTPS des domaines de suivi peuvent ne pas être émis. Un nom d'hôte de serveur de messagerie proxifié n'acceptera pas du tout les connexions SMTP, car le proxy gère les ports web et non ceux de la messagerie. Réglez donc tous les enregistrements liés à l'e-mail sur le mode « DNS uniquement » : cibles MX, enregistrements A des serveurs de messagerie, CNAME des noms d'hôte de return-path et de suivi, et CNAME DKIM. Les enregistrements TXT ne sont jamais proxifiés et ne sont donc pas concernés. Notre guide sur les domaines de return-path et de suivi explique pourquoi ces noms d'hôte doivent se résoudre directement vers la plateforme.

Choix du TTL et planification des changements

Le TTL est le nombre de secondes pendant lesquelles un résolveur peut conserver une réponse. Un TTL long réduit le nombre de requêtes et rend l'enregistrement plus résilient si vos serveurs de noms sont brièvement indisponibles. Un TTL court permet de récupérer rapidement après une erreur. La bonne approche consiste à le faire varier selon la phase.

Phase	TTL suggéré	Pourquoi
Création ou test d'un nouvel enregistrement	300 à 600 secondes	Les corrections apparaissent rapidement
Avant un changement planifié	Abaissez le TTL bien en avance, au moins aussi longtemps que le TTL actuel	Les anciens caches expirent avant que vous ne basculiez
Le jour du changement	Gardez-le court	Vous pouvez revenir en arrière
Enregistrements stables	De 3600 secondes à une journée	Moins de requêtes et moins d'exposition aux pannes

Le point essentiel de la planification est que l'abaissement d'un TTL n'a pas d'effet immédiat. Les caches qui détiennent déjà l'enregistrement le conservent pendant l'ancien TTL. Si un enregistrement a un TTL de 86400 secondes, abaissez-le au moins un jour avant le changement. Modifiez ensuite la valeur, patientez, vérifiez, puis relevez de nouveau le TTL.

Propagation et cache négatif

Les modifications DNS ne se diffusent pas depuis un point unique. Il n'existe aucune poussée globale. Ce que l'on appelle la propagation n'est que le temps nécessaire à l'expiration des caches. Les serveurs faisant autorité répondent avec la nouvelle valeur dès que la zone est enregistrée et chargée, et chaque résolveur bascule à la fin de sa copie en cache. Certains résolveurs ignorent les TTL très bas ou conservent les réponses un peu plus longtemps : prévoyez donc une marge.

Il existe un second cache que l'on oublie facilement : le cache négatif. Si un résolveur a demandé un nom qui n'existait pas encore, il mémorise la réponse « introuvable », et la RFC 2308 précise que la durée est fondée sur l'enregistrement SOA (la plus petite valeur entre le TTL du SOA et son champ minimum). Si votre plateforme a vérifié l'enregistrement quelques minutes avant que vous ne l'ajoutiez, l'échec peut rester en cache jusqu'à la fin de ce délai, même si l'enregistrement existe désormais.

Un exemple concret

Imaginons un domaine dont l'enregistrement TXT DKIM a été publié à 10:00 avec un TTL de 3600 secondes et un délai de cache négatif SOA de 900 secondes. À 10:05, la plateforme vérifie trop tôt et obtient « introuvable » : ce résolveur met donc l'échec en cache jusqu'à environ 10:20. À 10:10, vous remarquez une faute de frappe, corrigez la clé et l'enregistrez. Les serveurs faisant autorité donnent désormais la nouvelle réponse. Un résolveur qui a mis en cache le premier enregistrement à 10:00 peut encore servir l'ancien jusqu'à 11:00. Celui qui a mis en cache « introuvable » peut le servir jusqu'à 10:20. Ainsi, un résultat parfaitement propre sur tous les résolveurs peut prendre jusqu'à 11:00, mais une vérification effectuée directement auprès des serveurs faisant autorité réussit dès 10:10. Dans ce cas, vous utilisez le résultat faisant autorité pour confirmer que votre modification est correcte, puis vous attendez la plus longue durée de cache, 60 minutes, avant d'appuyer de nouveau sur le bouton de vérification.

Lorsque la plateforme relance automatiquement les vérifications, vous n'avez peut-être rien à faire. Lorsqu'elle ne vérifie qu'à l'appui d'un bouton, attendez la plus longue période de cache que vous avez calculée. Ne modifiez pas de nouveau l'enregistrement pendant l'attente, car chaque modification relance le compteur des caches qui se rafraîchissent.

Un tableau de diagnostic par symptôme

Symptôme	Cause la plus probable	Premier contrôle	Correction
La plateforme indique que l'enregistrement DKIM est introuvable	Nom doublé, mauvaise zone ou propagation pas encore terminée	Exécutez dig sur le nom exact du sélecteur auprès du serveur faisant autorité	Corrigez le champ d'hôte ou attendez les caches
DKIM est vérifié mais la signature échoue avec une erreur de clé	Clé tronquée ou découpée avec un espace	Assemblez les chaînes TXT et comparez-les à l'original	Saisissez de nouveau en segments sans espaces
SPF renvoie une erreur permanente	Deux enregistrements SPF ou plus de 10 requêtes	Exécutez dig TXT à l'apex et comptez les enregistrements v=spf1	Fusionnez les enregistrements, réduisez les requêtes
L'enregistrement SPF semble ignoré	Guillemet littéral ou espace initial dans la valeur	Cherchez une valeur qui ne commence pas par v=spf1	Supprimez les caractères parasites
Le CNAME refuse de s'enregistrer	Un autre enregistrement existe sous ce nom, ou le nom est l'apex	Listez tous les types d'enregistrements sous ce nom	Supprimez le conflit ou utilisez un sous-domaine
Le CNAME existe mais la vérification échoue	Proxy DNS activé ou cible mal saisie	dig renvoie-t-il la cible attendue ?	Réglez sur « DNS uniquement », corrigez la cible
Fonctionne sur votre ordinateur, échoue sur la plateforme	Caches de résolveurs différents	Interrogez le serveur faisant autorité et deux résolveurs publics	Attendez l'ancien TTL
L'enregistrement existe mais la vérification indique toujours « introuvable »	Cache négatif	Consultez les valeurs SOA et l'heure de la première vérification	Attendez la durée du cache négatif
Le rapport DMARC n'affiche aucune politique	Enregistrement placé sous le mauvais nom	Vérifiez que le nom commence par _dmarc	Déplacez-le sous _dmarc.votredomaine

Les problèmes au niveau des en-têtes, par opposition aux problèmes au niveau des enregistrements, se confirment plus facilement dans le message lui-même. Consultez comment lire les en-têtes d'un e-mail pour comprendre ce que signifient les résultats d'authentification une fois le DNS correct.

Une routine pratique à répéter

1. Identifier. Notez le nom et le type exacts que demande votre plateforme.
2. Localiser. Trouvez les serveurs de noms actifs avec une requête NS et confirmez que vous modifiez bien cette zone.
3. Saisir. Utilisez le nom d'hôte relatif, collez la valeur sans guillemets ajoutés, et ne découpez les longues chaînes que si votre interface l'exige.
4. Relire. Interrogez le serveur faisant autorité et comparez le résultat à l'original.
5. Nettoyer. Supprimez les doublons, les anciens sélecteurs portant le même nom et les types d'enregistrements en conflit.
6. Proxy désactivé. Confirmez que les enregistrements liés à la messagerie sont réglés sur « DNS uniquement ».
7. Attendre intelligemment. Calculez la plus longue durée entre l'ancien TTL et le délai de cache négatif.
8. Vérifier. Lancez la vérification de la plateforme et envoyez un message de test. Consultez votre compte MigoSMTP ou la documentation de l'API pour connaître les noms et valeurs exacts à publier.

Liste de contrôle avant de demander de l'aide

• Le nom de l'enregistrement a été relu auprès du serveur de noms faisant autorité et correspond exactement à ce que demandait la plateforme.
• Aucun suffixe de domaine n'apparaît deux fois dans le nom stocké.
• La valeur ne contient ni guillemets collés, ni sauts de ligne, ni espaces à l'intérieur des longues clés.
• Les longues valeurs TXT sont complètes une fois les chaînes assemblées.
• Un seul enregistrement SPF existe sous ce nom, et le nombre de requêtes respecte la limite.
• Aucun CNAME ne partage son nom avec un autre enregistrement, et aucun CNAME ne se trouve à l'apex.
• Tous les enregistrements liés à la messagerie sont réglés sur « DNS uniquement », sans proxy.
• Vous avez attendu l'ancien TTL et le délai de cache négatif avant de revérifier.
• La zone que vous avez modifiée est bien celle vers laquelle pointent les enregistrements NS.

Pour aller plus loin et sources

• RFC 1035 : Domain Names - Implementation and Specification
• RFC 2181 : Clarifications to the DNS Specification
• RFC 2308 : Negative Caching of DNS Queries (DNS NCACHE)
• RFC 7208 : Sender Policy Framework (SPF)
• RFC 6376 : DomainKeys Identified Mail (DKIM) Signatures