Recherche TXT

Lire les enregistrements texte libres d'un domaine

Guide

Une recherche TXT affiche les enregistrements texte libres rattachés à un domaine : jetons de vérification, politiques SPF, et autres informations lisibles par des machines qui ne rentrent dans aucun autre type d'enregistrement.

Qu'est-ce qu'un enregistrement TXT ?

Un enregistrement TXT (texte) est une entrée DNS qui contient du texte libre associé à un domaine ou un sous-domaine. La RFC 1035 a défini ce type d'enregistrement pour des notes lisibles par un humain ; la RFC 1464 a ensuite formalisé une convention "attribut=valeur" pour que les logiciels puissent aussi les interpréter. Dans la pratique, la quasi-totalité des enregistrements TXT rencontrés aujourd'hui sont destinés à être lus par des machines : jeton de vérification, politique SPF, ou clé publique DKIM.

Un domaine peut porter un nombre quelconque d'enregistrements TXT, et un même enregistrement peut lui-même être découpé en plusieurs chaînes entre guillemets. Les résolveurs DNS recollent ces morceaux avant de transmettre l'enregistrement à l'application, si bien que de l'extérieur un TXT apparaît comme une valeur continue même quand le fichier de zone le stocke en plusieurs fragments.

  • N'importe quel nom de la zone peut porter des enregistrements TXT : l'apex, un sous-domaine, ou un nom préfixé par underscore comme _dmarc ou selecteur._domainkey
  • Un domaine porte généralement plusieurs TXT sans rapport entre eux en même temps : un pour SPF, un ou plusieurs pour la vérification de site, parfois un pour les indications de politique DMARC
  • TXT est le type "fourre-tout" : les nouveaux protocoles le réutilisent plutôt que de faire enregistrer un type DNS dédié auprès de l'IANA

Usages courants des enregistrements TXT

Trois usages couvrent la grande majorité des TXT rencontrés en pratique.

  • Vérification de domaine - Google Search Console, Microsoft 365 et des services équivalents demandent d'ajouter un TXT contenant un jeton qu'ils génèrent, pour prouver le contrôle de la zone DNS avant d'activer un service
  • SPF (Sender Policy Framework) - un TXT commençant par "v=spf1" liste les serveurs autorisés à envoyer des emails au nom du domaine ; les serveurs destinataires le comparent à l'IP de l'expéditeur
  • Clés publiques DKIM - des TXT publiés sur un sous-domaine sélecteur (par exemple selector1._domainkey.exemple.fr) exposent la clé publique utilisée pour vérifier la signature DKIM d'un message

Syntaxe d'un enregistrement TXT

La valeur d'un TXT est constituée d'une ou plusieurs chaînes entre guillemets. Chaque chaîne est limitée à 255 octets par le format binaire du DNS (RFC 1035) ; une bibliothèque de résolution recolle ces chaînes en une seule valeur avant de la retourner, donc les applications n'ont jamais à faire ce découpage elles-mêmes.

Un enregistrement SPF typique ressemble à ceci dans un fichier de zone (les registrars français comme OVHcloud ou Gandi utilisent le même format) :

Ligne de fichier de zoneSignification
exemple.fr. IN TXT "v=spf1 include:_spf.google.com ~all"Autorise Google Workspace à envoyer des emails, échec souple pour le reste
exemple.fr. IN TXT "google-site-verification=abc123XYZ"Jeton de propriété du domaine pour un service Google
_dmarc.exemple.fr. IN TXT "v=DMARC1; p=none; rua=mailto:d@exemple.fr"Enregistrement de politique DMARC (sous le sous-domaine _dmarc, pas à l'apex)
selector1._domainkey.exemple.fr. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."Clé publique DKIM pour le sélecteur "selector1"

Limites de taille d'un enregistrement TXT

Deux limites comptent et il est facile de les confondre. Une chaîne unique à l'intérieur d'un TXT est plafonnée à 255 octets par le format binaire - c'est une limite protocolaire stricte, pas un choix de politique. Un TXT peut dépasser 255 octets au total en répartissant la valeur sur plusieurs chaînes adjacentes entre guillemets, que les résolveurs réassemblent de façon transparente ; c'est pour cela qu'une longue clé DKIM est souvent écrite en deux segments consécutifs ou plus dans le fichier de zone.

La réponse DNS globale en UDP est historiquement plafonnée autour de 512 octets sans EDNS0, même si pratiquement tous les résolveurs modernes négocient des réponses plus grandes ou basculent automatiquement en TCP, ce qui limite les problèmes pratiques pour une poignée de TXT. Cela peut compter quand un domaine accumule de nombreux jetons de vérification de fournisseurs différents en plus de SPF et DKIM - certains hébergeurs DNS avertissent lorsqu'une zone approche ces seuils.

Lire les résultats d'une recherche TXT

La recherche regroupe tous les enregistrements TXT trouvés sous le badge de type TXT et affiche un compteur. Chaque entrée indique le nom de domaine sur lequel il a été trouvé et la valeur reconstituée : l'outil recolle les segments entre guillemets de la même façon qu'une bibliothèque de résolution, donc ce qui s'affiche correspond exactement à ce que lit un serveur de messagerie ou un script de vérification. Un résultat "aucun enregistrement trouvé" signifie que le nom n'a réellement aucun TXT, pas que la recherche a échoué - beaucoup de sous-domaines n'en ont jamais.

Quand plusieurs TXT existent pour le même nom (fréquent sur un domaine qui cumule SPF et deux ou trois jetons de vérification), chacun apparaît comme une entrée distincte, ce qui permet de repérer lequel correspond à la politique SPF et lesquels sont des jetons de vérification sans rapport.

Questions fréquentes

Combien d'enregistrements TXT un même nom peut-il porter ?

Un même nom peut en porter beaucoup en même temps : SPF, DKIM, une politique DMARC sur _dmarc et plusieurs chaînes de vérification cohabitent souvent sous le même domaine. Le résolveur les renvoie tous, et chaque système ne retient que le préfixe qui le concerne (un serveur mail ne lit que le "v=spf1", une AC ne lit que son jeton de vérification). La seule exception est qu'un nom ne doit jamais porter plus d'un enregistrement SPF valide.

Pourquoi mon enregistrement TXT apparaît-il coupé en deux morceaux dans l'éditeur de zone ?

Les enregistrements TXT sont composés de chaînes entre guillemets plafonnées à 255 octets chacune. Une valeur plus longue doit s'étendre sur deux chaînes ou plus dans le fichier de zone. La plupart des hébergeurs DNS masquent ce détail et permettent de coller une seule longue valeur, en la découpant silencieusement pour vous.

Les enregistrements TXT ont-ils un TTL comme les autres enregistrements DNS ?

Oui, les TXT suivent le même mécanisme de TTL que n'importe quel autre type d'enregistrement. Un TTL court (quelques minutes) est courant juste après l'ajout d'un enregistrement de vérification ou SPF, pour pouvoir corriger une erreur et repropager rapidement ; il est souvent remonté une fois l'enregistrement confirmé fonctionnel.

Puis-je supprimer un vieux TXT de vérification une fois un service validé ?

Généralement oui, mais mieux vaut vérifier la documentation du fournisseur au préalable. Certains services (certaines fonctionnalités de Google Workspace, par exemple) ne contrôlent le jeton qu'au moment de la vérification et il est sans risque de le retirer ensuite ; d'autres recontrôlent périodiquement l'enregistrement pour confirmer la propriété continue et désactivent l'intégration s'il disparaît.

Un enregistrement TXT est-il la même chose qu'un enregistrement DMARC ou DKIM ?

DMARC et DKIM sont tous les deux publiés sous forme d'enregistrements TXT : DMARC toujours sur un nom commençant par _dmarc, DKIM sur un sous-domaine sélecteur se terminant par _domainkey. TXT est le type d'enregistrement sous-jacent ; DMARC et DKIM sont des conventions sur ce qu'il contient et où il est placé.

Pourquoi deux services différents me demandent-ils d'ajouter des TXT aux jetons presque identiques ?

Chaque fournisseur de vérification génère son propre jeton opaque et attend son propre préfixe (google-site-verification=, MS=, facebook-domain-verification=, etc.). Ils coexistent sans problème comme enregistrements TXT distincts sur le même nom, tant que chacun conserve son propre enregistrement au lieu d'écraser celui d'un autre fournisseur.

Outils liés