Recherche TXT
Lisez chaque TXT d’un domaine ou nom d’hôte, avec SPF, DMARC, DKIM, BIMI et jetons de vérification identifiés et testés : gratuit, sans compte.
Qu’est-ce qu’une recherche TXT ?
Cette recherche TXT interroge le DNS public pour un nom d’hôte et renvoie chaque chaîne TXT publiée, étiquetée selon le protocole ou service qui la lit. L’authentification e-mail repose sur ces chaînes : SPF est un TXT du domaine d’envoi, les clés DKIM des TXT sous un sélecteur, DMARC un TXT sur _dmarc, et BIMI, MTA-STS et TLS-RPT ont chacun leur nom d’hôte. Idem pour les jetons de vérification que Google, Microsoft, Apple et bien d’autres font publier. Une recherche brute montre les chaînes ; celle-ci dit aussi quel protocole lit chacune, si elle est sur le bon hôte et si deux d’entre elles se contredisent.
Lire votre résultat
| Résultat | Signification | Que faire |
|---|---|---|
| Entrée SPF | Une chaîne commençant par v=spf1 : les hôtes autorisés à envoyer pour ce domaine, et quoi faire des autres. | Vérifiez qu’il finit par ~all ou -all et liste chaque service d’envoi. Le test SPF compte ses requêtes DNS face à la limite de dix. |
| Entrée DMARC | Une chaîne v=DMARC1. Utile seulement sur _dmarc.yourdomain.com ; ailleurs, ignorée. | Lisez la balise p=. none ne fait que rapporter ; quarantine et reject protègent vraiment. |
| Clé publique DKIM | Une chaîne v=DKIM1 ou p= sur selector._domainkey.yourdomain.com. Un p= vide : clé révoquée. | Vérifiez la clé avec le test DKIM, qui sonde aussi les sélecteurs courants si vous ignorez le vôtre. |
| BIMI, MTA-STS, TLS-RPT | Indicateurs de politique sur default._bimi, _mta-sts et _smtp._tls. | Chacun a son test, qui valide ce qu’une chaîne DNS ne peut pas : le logo, la politique HTTPS, l’adresse de rapport. |
| Jeton de vérification | Une preuve de propriété pour un service tiers. L’outil nomme le service si le préfixe est connu. | Rien, sauf si un jeton nomme un service abandonné. Le retirer ne casse rien de déjà vérifié. |
| Deux SPF ou deux DMARC | Plusieurs v=spf1 sur un nom, ou plusieurs v=DMARC1 sur _dmarc. Les destinataires y voient une erreur, pas un choix. | Fusionnez-les en un seul. D’ici là, SPF renvoie permerror et DMARC est traité comme absent. |
| Aucun TXT | Le nom résout sans publier de TXT, ou ne résout pas du tout. | Vérifiez l’orthographe. Domaine racine qui envoie : publiez SPF ; sous-domaine qui n’envoie pas : c’est normal. |
Où vit chaque enregistrement e-mail
L’erreur la plus fréquente : chercher les TXT du domaine racine et conclure que DMARC manque. Il n’y est pas car les destinataires ne l’y cherchent jamais. Chaque protocole interroge un nom d’hôte précis, et la recherche ne montre que celui demandé :
- SPF :
yourdomain.com, le domaine de l’enveloppe. - DMARC :
_dmarc.yourdomain.com. - DKIM :
selector._domainkey.yourdomain.com, un par clé. - BIMI :
default._bimi.yourdomain.com. - MTA-STS :
_mta-sts.yourdomain.com, et TLS-RPT :_smtp._tls.yourdomain.com.
Chaque résultat finit par des recherches en un clic des autres hôtes du domaine : le tableau complet tient en cinq clics, pas cinq noms tapés.
Ce que la recherche prouve
Elle prouve ce que le DNS public renvoie pour ce nom, et repère les erreurs visibles dans les chaînes : un second SPF, un DMARC sur le mauvais hôte, une clé DKIM avec balise p= vide, un SPF finissant par +all. Elle ne juge pas un enregistrement sur de vrais e-mails. Un SPF parfait peut oublier le service qui envoie vos factures, et une clé DKIM en DNS ne prouve pas que le serveur signe avec. Le test SPF, le test DKIM et le test DMARC valident chacun leur enregistrement balise par balise une fois publié.
De la lecture des entrées à leur justesse
Une recherche est l’instantané d’un nom d’hôte. Les enregistrements qui fondent la confiance dérivent : une équipe adopte un outil d’envoi que le SPF ne couvre plus, un fournisseur change de sélecteur DKIM, un DMARC reste à p=none un an faute de lire les rapports. Palisade transforme les rapports agrégés DMARC en flux priorisé : identifiez chaque source d’envoi du domaine, voyez ce dont chacune a besoin et menez le domaine vers l’application sur preuves, pas au hasard.
Pour les MSP, c’est multi-tenant : SPF, DKIM et DMARC de chaque domaine client testés, corrigés et appliqués depuis une console, avec un prix par domaine client dont le prix unitaire baisse à l’échelle.
Tests et termes liés
Le logiciel DMARC qui fait le travail
Palisade transforme les rapports DMARC en tâches priorisées (expéditeurs, enregistrements) : chaque chaîne SPF, DKIM et DMARC affichée est celle qui doit y être.
Audit de domaine gratuit, sans carte. Une carte lance l’essai de 15 jours.
Base de connaissances e-mail
Qu’est-ce qu’une recherche TXT ?
Cette recherche TXT interroge le DNS public pour un nom d’hôte et renvoie chaque chaîne TXT publiée, étiquetée selon le protocole ou service qui la lit. Les TXT portent les politiques SPF, clés DKIM, politiques DMARC, pointeurs BIMI et jetons de vérification de services comme Google Workspace et Microsoft 365. L’outil lance la requête puis étiquette chaque chaîne selon le système qui la lit.
Pourquoi mon DMARC n’apparaît-il pas quand je cherche mon domaine ?
Parce que DMARC n’est pas publié sur le domaine lui-même. Les destinataires le lisent sur _dmarc.yourdomain.com : une recherche de yourdomain.com ne le renvoie jamais. Saisissez _dmarc.yourdomain.com ici, ou suivez les liens d’hôtes liés sous chaque résultat. Idem pour DKIM, sur selector._domainkey.yourdomain.com, et BIMI, sur default._bimi.yourdomain.com.
Comment lire un TXT avec dig ou nslookup ?
Sous macOS ou Linux, lancez dig TXT example.com, et ajoutez +short pour n’afficher que les valeurs. Sous Windows, lancez nslookup -type=TXT example.com, ou Resolve-DnsName -Name example.com -Type TXT dans PowerShell. Remplacez example.com par le nom exact, comme _dmarc.example.com. Vous obtenez les mêmes chaînes brutes, sans classement. Toutes les commandes, options et variantes PowerShell sont dans le guide dig et nslookup ci-dessous.
Combien de TXT un domaine peut-il avoir ?
Le DNS ne limite pas le nombre de TXT sur un nom, mais les protocoles, si. SPF autorise un seul enregistrement v=spf1 (RFC 7208), DMARC un seul v=DMARC1 sur _dmarc (RFC 9989, qui remplace la RFC 7489). Deux SPF renvoient permerror, que DMARC compte comme échec SPF ; deux DMARC font ignorer la requête, et le domaine est traité comme sans politique. Les jetons de vérification n’ont pas de limite ; un domaine actif en porte souvent dix ou plus.
Pourquoi mon TXT est-il découpé en plusieurs chaînes ?
La RFC 1035 limite une chaîne TXT à 255 octets. Au-delà, il faut plusieurs chaînes dans un même enregistrement, que résolveurs et serveurs mail rejoignent. Les longs SPF et les clés DKIM 2048 bits en ont souvent besoin. La plupart des DNS découpent seuls une longue valeur ; cet outil montre en combien de chaînes chaque enregistrement est publié, pour distinguer un découpage correct d’une troncature.
Quels résolveurs DNS sont utilisés ?
Les requêtes passent par le résolveur public de Google (8.8.8.8), puis celui de Cloudflare (1.1.1.1). Vous voyez à peu près ce que voit un tiers, et non le cache du résolveur de votre bureau. Un changement tout récent peut donc n’apparaître qu’à l’expiration du TTL sur ces résolveurs.
Que sont tous ces jetons de vérification dans mes TXT ?
Des chaînes comme google-site-verification=..., MS=ms... ou apple-domain-verification=... sont des preuves de propriété. Un service vous en fait publier une, puis la lit pour confirmer que vous contrôlez le domaine. Sans danger si vous les gardez, et l’outil nomme le service des plus courantes. Elles forment aussi l’inventaire discret des services reliés un jour à ce domaine.
Une recherche TXT dit-elle si mes e-mails sont authentifiés ?
Elle dit ce qui est publié : nécessaire, pas suffisant. Un SPF parfait ne sert à rien pour un message envoyé d’un serveur non listé, et une clé DKIM en DNS ne prouve pas que le serveur signe avec. Les constats signalent les problèmes de structure des enregistrements. Le passage réel de vos e-mails se lit dans les rapports agrégés DMARC, ce que lit Palisade.
Pourquoi ne vois-je aucun TXT ?
Soit le nom d’hôte est mal écrit, soit le domaine n’est pas enregistré, soit ses serveurs de noms ne répondent pas, soit il n’en publie vraiment aucun. Un domaine racine sans TXT n’a pas de SPF, ce qui compte s’il envoie. Un sous-domaine sans TXT est normal, sauf s’il envoie en son nom. Vérifiez l’orthographe : l’oubli du tiret bas de _dmarc est la cause la plus fréquente.
Chaque balise et mécanisme de DMARC, SPF et DKIM, expliqués au même endroit.
DMARC
- vVersion
- La balise Version est indispensable dans un DMARC et doit valoir strictement « DMARC1 ». Si la valeur est incorrecte ou la balise absente, l’enregistrement DMARC n’est pas valide et il est ignoré.
- pPolitique DMARC
- La balise de politique DMARC accepte trois valeurs pour le courrier qui échoue : none ne demande aucune application, quarantine un traitement suspect, reject le rejet. Les destinataires décident en dernier et peuvent filtrer ou rejeter via d’autres contrôles en p=none. Les rapports agrégés se demandent à part, via la balise rua.
- ruaDestination des rapports agrégés
- La destination des rapports agrégés est une URI « mailto: », que les fournisseurs de messagerie (ESP) utilisent pour envoyer les rapports agrégés. La balise n’est pas obligatoire, mais sans elle vous ne recevez aucun rapport.
- rufDestination forensique
- La destination des rapports forensiques (d’échec) est une URI « mailto: », que les fournisseurs de messagerie (ESP) utilisent pour livrer les rapports d’échec. La balise n’est pas obligatoire, mais sans elle vous ne recevez aucun rapport.
- spSous-domaines
- Par défaut, la politique des sous-domaines hérite de la balise de politique du domaine principal (p=), décrite plus haut, sauf mention contraire. Comme pour le domaine, les valeurs possibles sont « none », « quarantine » ou « reject ». Cette option reste toutefois peu utilisée en pratique.
- adkimAlignement DKIM
- Cette balise fixe l’alignement de la signature DKIM, c’est-à-dire la correspondance entre le domaine DKIM et le domaine d’origine du « Header From ». Valeurs possibles : « r » (relaxed) et « s » (strict). Par défaut, « r » accepte une correspondance partielle entre ces domaines, tandis que « s » exige qu’ils soient identiques.
- aspfAlignement SPF
- Cette balise fixe l’alignement SPF, c’est-à-dire la compatibilité entre le domaine SPF (l’expéditeur) et le domaine du « Header From ». Deux valeurs : « r » (relaxed) et « s » (strict). Par défaut, « r » tolère une correspondance partielle entre les domaines. À l’inverse, « s » exige une correspondance exacte des domaines.
- foOptions forensiques
- Les options des rapports forensiques sont « 0 », « 1 », « d » et « s ». Par défaut, « 0 » déclenche un rapport seulement quand les alignements SPF et DKIM échouent tous deux. « 1 » en déclenche un dès que SPF ou DKIM ne passe pas. « d » produit un rapport pour les échecs de validation DKIM, « s » pour les problèmes SPF. Pour recevoir ces rapports forensiques, il faut renseigner la balise « ruf ».
- rfFormat des rapports
- Le format des rapports d’échec peut valoir « afrf » ou « iodef », les deux seules options autorisées.
- pctPourcentage (historique)
- L’ancienne balise Pourcentage demandait d’appliquer quarantine ou reject à une partie seulement du courrier en échec DMARC. La RFC 9989 a retiré pct, l’application partielle étant mise en œuvre de façon inégale. Les nouveaux enregistrements l’omettent et échelonnent via les rapports agrégés, des politiques entières et des sous-domaines à faible volume.
- riFréquence des rapports
- L’intervalle des rapports indique, en secondes, la fréquence des rapports XML. La valeur standard est 86400 secondes, soit un rapport par jour. Notez toutefois que, quel que soit l’intervalle indiqué, les fournisseurs d’accès (FAI) envoient en général ces rapports selon leur propre calendrier, le plus souvent une fois par jour également.
SPF
- v
- La balise de version doit valoir « spf1 », exclusivement. Une version fausse ou absente fait ignorer l’enregistrement SPF.
- ip4
- Cette balise liste les adresses IPv4 autorisées à envoyer pour le domaine.
- ip6
- Cette balise indique les adresses IPv6 autorisées à envoyer au nom du domaine.
- a
- La balise A valide l’expéditeur via l’adresse IP du domaine, le domaine courant par défaut s’il n’est pas précisé.
- mx
- La balise MX valide l’enregistrement MX du serveur mail, le domaine courant par défaut s’il n’est pas précisé.
- ptr
- La balise PTR lance un contrôle PTR des noms d’hôte des IP clientes, déconseillé par la RFC 7208 (trop de requêtes DNS).
- exists
- La balise exists vérifie la présence d’un enregistrement A sur le domaine indiqué.
- include
- La balise include est essentielle à un SPF exact : elle confirme aux destinataires que chaque domaine ou sous-domaine listé envoie légitimement.
- all
- La balise all est obligatoire, en fin d’enregistrement SPF : ses qualificateurs (~, +, -, ?) disent aux destinataires comment traiter les sources non autorisées.
DKIM
- v
- La balise de version indique la version de DKIM, qui doit toujours valoir 1.
- p
- La balise de clé publique, une chaîne créée à la configuration DKIM, ne doit pas être vide pour rester valide.
- t
- Cette balise liste des indicateurs séparés par deux-points ; seuls « y » et « s » sont définis, les autres doivent être ignorés.
- s
- Cette balise précise les types de service concernés. Les serveurs destinataires ignorent les types absents ou inconnus.
- h
- Cette balise indique les algorithmes de hachage permis (tous par défaut). Les destinataires ignorent ceux qu’ils ne connaissent pas ; l’expéditeur fixe la liste.
- n
- Cette balise est un champ de note facultatif pour les administrateurs, à n’utiliser qu’au besoin.