Enregistrement TXT : définition et usages DNS

Quelles sont les exigences ?

Un TXT contient une ou plusieurs chaînes

La RFC 1035 définit les RDATA TXT comme une ou plusieurs chaînes de caractères. Chaque chaîne commence par un octet de longueur : elle ne peut dépasser 255 octets.

yourdomain.com. 3600 IN TXT "example domain-verification value"

Exemple illustratif. Publiez le nom d’hôte et la valeur exacts fournis par le service qui demande la vérification.

Les logiciels DNS affichent souvent les longues valeurs en chaînes entre guillemets accolées. Les résolveurs renvoient ces chaînes comme morceaux d’un même TXT. Une clé DKIM peut donc apparaître coupée dans un fichier de zone ou une interface sans former plusieurs enregistrements DKIM.

selector1._domainkey.yourdomain.com. 3600 IN TXT (
  "v=DKIM1; k=rsa; p=example-public-key-part-one"
  "example-public-key-part-two"
)

Structure illustrative, pas une clé DKIM utilisable. Générez le vrai sélecteur et la clé publique dans le service d’envoi qui signe. Ne copiez pas le sélecteur, la clé ou la cible CNAME d’une autre organisation.

SPF utilise un TXT à politique SPF unique

SPF publie la politique SPF d’un domaine dans des enregistrements TXT. La RFC 7208 interdit à un nom de domaine d’avoir plusieurs enregistrements qui feraient sélectionner plusieurs enregistrements SPF. Si plusieurs v=spf1 applicables existent, le traitement SPF renvoie permerror.

yourdomain.com. 3600 IN TXT "v=spf1 include:mail.example.net -all"

Exemple illustratif. Les mécanismes include: et le qualificateur final doivent correspondre aux sources autorisées de votre propre domaine d’envoi.

D’autres TXT peuvent exister au même nom pour d’autres usages, mais deux valeurs v=spf1 ne servent pas à combiner des listes d’expéditeurs. Fusionnez les mécanismes autorisés dans la politique SPF unique après avoir vérifié que le nombre de requêtes reste dans les limites de SPF.

DKIM publie une clé publique à un nom de sélecteur

DKIM permet au destinataire de récupérer la clé publique dans le DNS. L’expéditeur place le sélecteur dans la balise s= de son champ DKIM-Signature. Le destinataire interroge :

selector._domainkey.yourdomain.com

Le TXT à ce nom porte un enregistrement de clé DKIM, qui commence souvent par v=DKIM1;. Le sélecteur dépend du service. Une clé publiée rend seulement la vérification possible. Elle ne prouve pas que l’application signe en ce moment avec ce sélecteur.

DMARC publie une politique à _dmarc

DMARC utilise un TXT à _dmarc pour publier la politique et les consignes de rapport d’un domaine.

_dmarc.yourdomain.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com"

Enregistrement DMARC illustratif. L’adresse de rapport et la politique doivent être choisies pour votre domaine et approuvées par l’opérateur responsable. Un DMARC peut être présent et valide alors que les e-mails de production échouent à l’alignement SPF ou DKIM.

Pour ces contrôles associés, voir la rubrique authentification des e-mails.

Quand l’exigence s’applique-t-elle ?

Les TXT font partie du DNS depuis la RFC 1035, publiée en novembre 1987. La RFC 1035 est une norme Internet définitive, pas un brouillon.

Il n’y a pas de date d’effet unique pour tous les usages TXT. Chaque protocole a son document de référence et ses règles de déploiement :

• SPF est défini dans la RFC 7208, publiée en avril 2014. Elle remplace la RFC 4408.
• DKIM est défini dans la RFC 6376, publiée en septembre 2011.
• DMARC est défini dans la RFC 9989, publiée en mai 2026.

Comment mettre l’exigence en œuvre ?

1. Le protocole et le nom propriétaire

Partez du système qui demande l’enregistrement. Il doit indiquer le type, le nom d’hôte et la valeur exacts attendus.

Pour l’authentification, confirmez le domaine de l’adresse From visible, de l’expéditeur d’enveloppe SMTP et du sélecteur DKIM. Un enregistrement au mauvais nom DNS n’est pas trouvé par le protocole visé.

2. Obtenez la valeur exacte du service responsable

Copiez la valeur générée par le fournisseur qui gère la vérification ou la signature. Gardez les limites des chaînes entre guillemets seulement si votre fournisseur DNS les exige.

Ne remplacez pas un SPF existant en ajoutant un second TXT v=spf1. Fusionnez les mécanismes autorisés dans la politique SPF existante après revue de tous les expéditeurs actifs.

Notez la valeur actuelle avant de la changer. L’opérateur a une référence de repli si une coquille ou un expéditeur oublié casse l’authentification.

3. Publiez dans la zone DNS faisant autorité

Ajoutez le TXT au nom d’hôte fourni par le protocole ou le service. Choisissez un TTL adapté au processus de changement de l’organisation.

Les interfaces DNS affichent l’origine de zone de façon différente. L’une demande _dmarc, une autre _dmarc.yourdomain.com. Lisez l’aide du champ chez le fournisseur pour ne pas ajouter deux fois l’origine de zone.

4. Attendez l’expiration du cache

Un changement DNS devient visible quand les serveurs faisant autorité servent la nouvelle zone, mais les résolveurs récursifs peuvent garder l’ancienne réponse jusqu’à expiration de son TTL. L’ancien TTL borne la durée de vie d’une réponse en cache.

Ne comptez pas sur un délai de propagation fixe. Vérifiez la réponse faisant autorité et les résolveurs publics.

5. Confirmez que le service utilise l’enregistrement

Un résultat DNS n’est que le premier niveau. Pour une vérification de domaine, confirmez le statut chez le fournisseur. Pour l’authentification, envoyez un vrai message par l’expéditeur de production exact et inspectez son en-tête Authentication-Results.

Comment valider la conformité ?

Utilisez la recherche d’enregistrement TXT pour voir la réponse TXT publique du nom d’hôte configuré. Comparez le nom propriétaire et le texte renvoyés à la valeur générée avant de changer une politique.

Pour des commandes à copier et comparer les résolveurs, voir le guide des commandes TXT dig et nslookup.

Validez ensuite les niveaux concernés :

• DNS : interrogez le DNS faisant autorité et au moins un résolveur public. Confirmez le nom attendu et la valeur complète.
• Fournisseur : vérifiez le statut actuel du service d’envoi ou de vérification. Un voyant vert ne prouve pas qu’un message de production utilise la configuration.
• Message : envoyez un test par le vrai chemin de production et inspectez Authentication-Results. La RFC 8601 définit le champ d’en-tête des résultats d’authentification.
• DMARC : une fois les rapports accumulés, examinez les données agrégées des sources autorisées et non autorisées du domaine.

Suivez les sources d’envoi derrière vos TXT

Une requête TXT aide à confirmer la valeur publiée. Elle ne montre pas quels expéditeurs de production échouent encore à l’authentification ou à l’alignement après publication.

Palisade est un logiciel DMARC agentique : il analyse les rapports agrégés DMARC, identifie les sources d’envoi et les problèmes d’authentification ou d’alignement, et crée des tickets de correction priorisés. Il peut proposer l’étape DMARC suivante quand les preuves le justifient, et un humain examine les preuves et applique le changement.

Commencez avec Palisade

Palisade ne change pas seul la politique DMARC, ne prouve pas que tout futur message s’authentifiera et ne garantit ni la livraison ni la boîte de réception.