Outil gratuit
Quels enregistrements TXT porte ce domaine ?
Tous les TXT d'un nom, rangés par ce qu'ils font — SPF, DKIM, DMARC, preuves de propriété — et le DMARC est allé chercher là où il se trouve vraiment. Sans inscription, sans e-mail à laisser.
Le fourre-tout du DNS, et rien n'y est étiqueté
L'enregistrement TXT n'a pas de rôle propre : c'est un champ libre que tout le monde s'est mis à utiliser. Un domaine d'entreprise en porte facilement vingt ou trente, dont la plupart sont des jetons de vérification laissés par des services qu'on n'utilise plus. Le SPF, lui, est quelque part au milieu — et c'est le seul qui décide si le courrier part ou non.
Le DMARC n'est jamais où on le cherche
C'est l'erreur numéro un de cette consultation : on interroge le domaine, on ne voit pas de DMARC, et on en conclut qu'il n'y en a pas. Le DMARC ne vit pas sur le domaine, il vit sur « _dmarc » devant le domaine. L'outil va donc le chercher là, et l'affiche dans le même tableau sous son vrai nom — les enregistrements sont aussi rangés pour que le SPF ne soit pas la vingt-neuvième ligne.
Le tiroir fourre-tout
Six lignes en vrac, et chacune sa place exacte
Un enregistrement TXT peut contenir n'importe quoi : c'est la case où l'on range tout ce qui n'a pas de case à soi. Ce qui compte, ce n'est pas son contenu, c'est le NOM auquel il est posé. Cliquez sur une ligne pour la ranger.
En vrac (6)
SPF
Doit être posé à
example.com
Les serveurs autorisés à envoyer du courrier pour ce domaine.
DMARC
Doit être posé à
_dmarc.example.com
Ce qu'il faut faire des messages qui échouent aux contrôles.
DKIM
Doit être posé à
selecteur._domainkey.example.com
La clé publique qui vérifie la signature des messages.
Preuve de propriété
Doit être posé à
example.com
Le jeton qu'un service vous demande de poser pour prouver que le domaine est bien à vous.
Rien du tout
Doit être posé à
n'importe où
Un TXT peut contenir du texte libre. Personne ne le lit, et il ne gêne personne.
Un DMARC posé à example.com au lieu de _dmarc.example.com ne sera jamais lu par personne. Le contenu est bon, l'adresse est fausse : c'est l'erreur la plus fréquente de cette famille.
Trois règles d'écriture
Trois nombres, et la moitié des TXT ratés disparaissent
Aucun des trois n'est une convention : ce sont des limites de format, et l'interface de votre hébergeur ne les rappelle jamais.
255car.
Un fragment, pas un mot de plus
Au-delà, la valeur est refusée par l'interface ou tronquée sans avertissement. Un enregistrement plus long se publie en plusieurs fragments que le lecteur recolle — et un espace ajouté entre deux casse une clé DKIM.
1SPF
Un seul par nom, jamais deux
Avec deux enregistrements « v=spf1 », la vérification échoue au lieu de cumuler les autorisations. C'est l'erreur qu'on commet en ajoutant un service d'envoi.
6formats
Reconnaissables au premier mot
SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI : six standards de messagerie qui vivent tous dans un TXT, se lisent à leur préfixe, et ne se posent pas au même endroit.
La limite de 255 caractères par fragment vient de la définition du format TXT (RFC 1035) ; la règle du SPF unique, de la RFC 7208. Les six formats sont ceux que ce contrôle sait nommer.
Lire le résultat
Le tableau donne chaque enregistrement avec, quand il l'annonce lui-même, ce qu'il est. Un TXT sans étiquette n'est pas suspect : c'est simplement un contenu qu'aucune norme ne permet de reconnaître à coup sûr.
- Rien à signaler — un SPF, un seul
- Un unique enregistrement commence par « v=spf1 ». C'est ce que la norme exige, et c'est l'état recherché.
- Rien à signaler — un DMARC trouvé
- Un enregistrement a été trouvé sur « _dmarc » devant le domaine. Il s'affiche dans le tableau sous ce nom-là, pour qu'on ne le confonde pas avec les TXT du domaine lui-même.
- À surveiller — aucun TXT
- Ce nom ne porte aucun enregistrement texte. Sur un sous-domaine c'est courant ; sur un domaine qui envoie du courrier, cela veut dire qu'il n'a ni SPF, ni preuve de propriété déposée.
- Problème — plusieurs SPF
- Deux enregistrements ou plus commencent par « v=spf1 ». La norme n'en admet qu'un : face à deux, la vérification ne choisit pas, elle échoue — et les messages sont traités comme non authentifiés.
- Problème — le nom n'existe pas
- Aucun serveur de noms ne connaît ce nom. Ce n'est pas qu'il n'a pas de TXT : c'est qu'il n'est pas déclaré.
- Indéterminé — aucun SPF trouvé
- Le nom porte des TXT, mais aucun ne commence par « v=spf1 ». Sur un domaine qui n'envoie rien, c'est sans conséquence ; sur les autres, plus rien ne dit aux destinataires qui a le droit d'écrire en son nom.
- Indéterminé — un enregistrement en plusieurs morceaux
- Un TXT dépasse 255 caractères : il est publié en plusieurs fragments que le résolveur recolle avant de les lire. C'est normal, prévu par la norme, et sans effet sur le contenu.
- Indéterminé — pas de réponse à temps
- Le résolveur n'a rien rendu dans le délai imparti. Cela arrive sur une zone lente et ne dit rien du domaine.
Les erreurs qu'on voit le plus souvent
Un second SPF a été créé pour ajouter un service
Ce qui la provoque : on veut autoriser un nouvel outil d'envoi, et l'interface propose « ajouter un enregistrement ». On se retrouve avec deux lignes « v=spf1 ». La norme n'en admet qu'une, et la présence de deux fait échouer la vérification entière — pire que s'il n'y en avait aucune.
Le geste qui corrige : fusionner : un seul enregistrement, avec tous les services énumérés dedans, et un seul « all » à la fin.
Le DMARC a été créé sur le domaine au lieu de « _dmarc »
Ce qui la provoque : l'enregistrement est syntaxiquement parfait, mais personne ne va le lire là. Les serveurs destinataires interrogent « _dmarc » devant le domaine, et uniquement cet endroit.
Le geste qui corrige : créer l'enregistrement avec « _dmarc » comme nom d'hôte. Certaines interfaces demandent « _dmarc » seul, d'autres le nom complet : les deux existent, il faut lire ce que le champ attend.
La valeur a été collée avec ses guillemets
Ce qui la provoque : la documentation du fournisseur montre la valeur entre guillemets parce que c'est ainsi qu'elle s'écrit dans un fichier de zone. Recopiée telle quelle dans un formulaire qui les ajoute lui-même, elle se retrouve avec des guillemets DANS son contenu, et plus rien ne la reconnaît.
Le geste qui corrige : coller la valeur sans guillemets, puis relire l'enregistrement tel qu'il est réellement publié — c'est ce que rend l'outil ci-dessus.
Une clé DKIM de plus de 255 caractères a été refusée
Ce qui la provoque : un TXT est fait de fragments de 255 caractères au maximum. Une clé publique de 2048 bits dépasse cette longueur et doit être publiée en plusieurs fragments. Certaines interfaces le font seules, d'autres refusent la valeur ou la tronquent en silence.
Le geste qui corrige : utiliser un champ qui accepte la découpe, ou publier la clé en fragments. Une clé tronquée ne produit aucune erreur visible : simplement, toutes les signatures échouent.
Le jeton de vérification a été supprimé après la vérification
Ce qui la provoque : on prouve la propriété d'un domaine, on obtient l'accès, et on fait le ménage. Or plusieurs services revérifient périodiquement et retirent l'accès si l'enregistrement a disparu — au pire moment, celui où l'on en a besoin.
Le geste qui corrige : laisser en place les jetons des services encore utilisés, et ne retirer que ceux dont on a délibérément fermé le compte.
Reconnaître un TXT à ce par quoi il commence
La plupart des enregistrements annoncent eux-mêmes ce qu'ils sont, dans leurs premiers caractères. C'est la seule façon fiable de trier les vingt lignes d'un domaine d'entreprise — et cela dit aussi où chacun doit être publié.
| Commence par | Ce que c'est | Où il doit se trouver |
|---|---|---|
| v=spf1 | SPF — la liste des serveurs autorisés à envoyer au nom du domaine. | Sur le domaine lui-même. Un seul, jamais deux. |
| v=DKIM1 | DKIM — la clé publique qui permet de vérifier la signature des messages. | Sur « <sélecteur>._domainkey » devant le domaine. Un par sélecteur. |
| v=DMARC1 | DMARC — ce que les destinataires doivent faire des messages qui échouent aux deux contrôles précédents. | Sur « _dmarc » devant le domaine. Jamais sur le domaine. |
| v=STSv1 | MTA-STS — impose une connexion chiffrée à la remise du courrier. | Sur « _mta-sts » devant le domaine, accompagné d'un fichier servi en HTTPS. |
| v=TLSRPTv1 | TLS-RPT — l'adresse à laquelle envoyer les rapports d'échec de chiffrement. | Sur « _smtp._tls » devant le domaine. |
| v=BIMI1 | BIMI — l'emplacement du logo affiché à côté des messages, quand la messagerie le prend en charge. | Sur « default._bimi » devant le domaine. Exige un DMARC appliqué. |
| google-site-verification= | La preuve que vous contrôlez le domaine, déposée pour les services Google. | Sur le domaine. À conserver tant que le service est utilisé. |
| MS= | La même preuve, pour les services Microsoft. | Sur le domaine. |
| _acme-challenge | La preuve demandée pour émettre un certificat par validation DNS. | Sur « _acme-challenge » devant le nom à certifier. Posée et retirée automatiquement à chaque renouvellement. |
Chacun de ces formats est défini par sa propre spécification : SPF par la RFC 7208, DKIM par la RFC 6376, DMARC par la RFC 7489, MTA-STS par la RFC 8461, TLS-RPT par la RFC 8460, la validation de certificat par la RFC 8555. BIMI est une spécification en cours, déjà appliquée par plusieurs messageries.
Les règles d'écriture d'un TXT
Elles expliquent la plupart des enregistrements « pourtant corrects » qui ne fonctionnent pas. Aucune ne produit de message d'erreur : l'enregistrement est accepté, il est simplement ignoré.
| Règle | Ce qu'elle impose | Ce qui arrive si on l'ignore |
|---|---|---|
| 255 caractères | Un fragment de TXT ne peut pas dépasser 255 caractères. | La valeur est refusée par l'interface, ou tronquée sans avertissement. |
| Plusieurs fragments | Un enregistrement plus long se publie en plusieurs fragments, que le lecteur recolle bout à bout, sans espace. | Un espace ajouté entre deux fragments casse une clé DKIM. |
| Un seul SPF | Un nom ne peut porter qu'un enregistrement commençant par « v=spf1 ». | Avec deux, la vérification échoue au lieu de cumuler les autorisations. |
| Pas de guillemets dans la valeur | Les guillemets délimitent la chaîne dans un fichier de zone ; ils ne font pas partie du contenu. | L'enregistrement publié commence par un guillemet et n'est plus reconnu. |
| Le nom compte | Le SPF va sur le domaine, le DMARC sur « _dmarc », le DKIM sur un sélecteur. | Un DMARC publié au mauvais endroit n'est jamais lu, et rien ne le signale. |
| La casse est indifférente | « v=spf1 » et « V=SPF1 » se valent pour la lecture. | Rien. C'est l'un des rares points sur lesquels on ne peut pas se tromper. |
| Plusieurs TXT autorisés | Un même nom peut porter autant d'enregistrements texte qu'on veut, sauf la limite d'un seul SPF. | Rien — mais au-delà de quelques dizaines, la réponse grossit et finit par imposer une seconde requête. |
La limite de 255 caractères par fragment et la concaténation viennent de la définition même du format TXT (RFC 1035). La règle du SPF unique est posée par la RFC 7208.
Questions fréquentes
À quoi sert un enregistrement TXT ?
À rien en particulier, et c'est précisément son usage : c'est un champ de texte libre attaché à un nom de domaine. Il a été détourné pour porter presque tout ce qui doit se prouver publiquement — l'autorisation d'envoyer du courrier, la clé qui signe les messages, la propriété d'un domaine, la validation d'un certificat.
Pourquoi mon DMARC n'apparaît-il pas quand j'interroge mon domaine ?
Parce qu'il n'y est pas. Le DMARC se publie sur « _dmarc » devant le domaine, et c'est le seul endroit où les serveurs destinataires vont le lire. L'outil ci-dessus interroge les deux noms et affiche chacun sous le sien.
Peut-on avoir deux enregistrements SPF ?
Non, et c'est pire que de n'en avoir aucun. Face à deux enregistrements, la vérification n'en choisit pas un : elle s'arrête en erreur, et les messages sont traités comme non authentifiés. Pour autoriser plusieurs services d'envoi, il faut les énumérer dans un enregistrement unique.
Un TXT peut-il dépasser 255 caractères ?
L'enregistrement, oui ; chacun de ses fragments, non. Au-delà de 255 caractères, la valeur se publie en plusieurs morceaux que le lecteur recolle. Les clés DKIM de 2048 bits sont dans ce cas, et c'est la raison pour laquelle certaines interfaces les refusent.
Puis-je supprimer un jeton de vérification une fois la vérification faite ?
Pas sans risque. Plusieurs services revérifient périodiquement la présence de leur enregistrement et retirent l'accès s'il a disparu. Le ménage se fait service par service, en ne retirant que les jetons de comptes qu'on a réellement fermés.
Combien de temps avant qu'un TXT modifié soit pris en compte ?
Le temps que la précédente réponse sorte de la mémoire des résolveurs, c'est-à-dire la durée de vie déclarée sur l'enregistrement. Tant qu'elle court, certains serveurs lisent l'ancienne valeur et d'autres la nouvelle — d'où les vérifications de propriété qui échouent pendant quelques heures puis réussissent seules.
Puis-je supprimer un enregistrement TXT que je ne reconnais pas ?
Pas avant d'avoir établi à quoi il sert. Les jetons de vérification doivent rester tant que le service est utilisé : plusieurs revérifient périodiquement et retirent l'accès quand la preuve a disparu. Deux catégories se retirent sans risque — une preuve « _acme-challenge » oubliée après un renouvellement de certificat, et une valeur qui ne commence par aucun format connu.
J'ai créé mon TXT et le service ne le voit toujours pas
Trois horloges différentes peuvent l'expliquer. La plus fréquente est la mémoire d'une réponse négative : si le nom a été interrogé avant d'exister, les résolveurs ont retenu « ce nom n'existe pas » pour la durée inscrite dans l'enregistrement d'origine de la zone, sans rapport avec la durée de vie que vous venez de choisir. Vient ensuite le rythme de revérification propre au service, que le DNS ne commande pas.
Les TXT d'un domaine d'entreprise : lesquels peut-on supprimer ?
Le tableau plus haut dit ce que chaque ligne est. Celui-ci répond à la question qu'on se pose vraiment devant une zone héritée de quelqu'un d'autre : qu'est-ce que j'ai le droit d'enlever ?
example.com
Garderv=spf1 include:_spf.example.net ~allPosé par : l'administrateur de la messagerie. Supprimé, les messages partis de votre domaine perdent leur autorisation et finissent en indésirables, quand ils ne sont pas refusés. C'est la ligne la plus dangereuse à toucher, parce que son absence ne se voit qu'à la réception.
_dmarc.example.com
Garderv=DMARC1; p=quarantine; rua=mailto:rapports@example.comPosé par : l'administrateur de la messagerie. Elle dit aux destinataires quoi faire des messages qui échouent aux contrôles. Sans elle, plus aucune politique et plus aucun rapport : la visibilité disparaît avant le problème.
selecteur1._domainkey.example.com
Garderv=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…Posé par : le fournisseur de messagerie, souvent automatiquement. Chaque sélecteur correspond à une clé en service. Supprimer celui d'un service encore utilisé rend les signatures invérifiables du jour au lendemain, sans le moindre message côté expéditeur.
example.com
Demander avantgoogle-site-verification=…Posé par : celui qui a rattaché le domaine à un service, il y a peut-être trois ans. Tant que le service est utilisé, le jeton doit rester : plusieurs services revérifient périodiquement et retirent l'accès quand la preuve a disparu. On ne l'enlève qu'après avoir établi que plus personne ne s'en sert.
example.com
Demander avantMS=…Posé par : le même, pour un autre service. Même raisonnement. Sur une zone héritée, ces deux ou trois lignes sont celles dont plus personne ne sait à quoi elles servent : c'est une raison de les documenter, pas de les supprimer.
_acme-challenge.example.com
Retirerjeton-de-validation-temporairePosé par : l'automate qui renouvelle un certificat. Une preuve de ce type ne vit que le temps d'une émission, quelques minutes. Si elle est encore là des semaines après, c'est qu'un renouvellement n'a pas nettoyé derrière lui. Sans effet, mais sans usage.
example.com
Retirernote laissée par un prestataire, sans format connuPosé par : personne ne sait. Une valeur qui ne commence par aucun format connu n'est lue par aucun logiciel. Elle ne gêne pas, sauf qu'elle allonge la réponse et brouille la lecture de toutes les autres.
Les valeurs ci-dessus sont des exemples construits sur les domaines réservés à la documentation (RFC 2606) ; les clés et les jetons sont tronqués et n'appartiennent à personne. Les formats cités sont définis par les RFC 7208 (SPF), 6376 (DKIM), 7489 (DMARC) et 8555 (validation de certificat par le DNS).
255 caractères : pourquoi une clé DKIM se publie en deux morceaux
C'est la limite qui explique le plus d'enregistrements « refusés sans raison », et elle ne vient pas de votre hébergeur : elle est dans la définition même du format.
La valeur dépasse la taille d'un fragment
Un enregistrement texte est fait d'un ou plusieurs fragments, et chacun est précédé d'un compteur tenant sur un seul octet. Un fragment ne peut donc pas dépasser 255 caractères. Une clé publique de 2 048 bits en fait à elle seule environ 390.
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA… ← environ 390 caractèresElle est coupée en deux fragments
Rien n'est perdu : la valeur est publiée en deux morceaux consécutifs, dans le même enregistrement. Dans un fichier de zone, cela s'écrit avec deux chaînes entre guillemets, séparées par un espace.
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC" "AQ8AMIIBCgKCAQEA…"Le lecteur les recolle sans rien ajouter
Celui qui lit l'enregistrement met les fragments bout à bout, sans espace ni séparateur. C'est pour cela qu'un espace ajouté « pour faire propre » entre les deux morceaux casse la clé : la valeur reconstituée n'est plus la bonne, et la signature devient invérifiable.
Ce que vous avez à faire, en pratique
Presque rien. La plupart des interfaces coupent la valeur toutes seules quand on la colle. Celles qui refusent en bloc affichent un message sur la longueur : il faut alors saisir les fragments à la main, et ne rien insérer entre eux. Le contrôle en haut de cette page affiche la valeur déjà recollée — si un espace apparaît au milieu de la clé, il est dans la zone.
La taille maximale d'un fragment et la règle de concaténation viennent de la définition du format texte dans la RFC 1035, § 3.3.14 ; l'obligation de recoller les fragments sans espace intermédiaire est rappelée par la RFC 6376, § 3.6.2.2.
Le champ « nom » : là où tout se perd
La valeur d'un TXT se copie-colle, elle est donc rarement fausse. Le nom, lui, se saisit à la main dans une interface qui a ses habitudes — et un enregistrement parfait posé au mauvais nom n'est lu par personne, sans le moindre message d'erreur.
Le nom complet a été saisi dans un champ relatif
Vous saisissez
_dmarc.example.comCe qui est publié
_dmarc.example.com.example.comLa plupart des interfaces attendent la partie gauche du nom et complètent avec le domaine. Il fallait écrire « _dmarc » seul. L'enregistrement existe, il est valide, et il se trouve à un endroit où aucun logiciel n'ira le chercher.
Le champ a été laissé vide pour un DMARC
Vous saisissez
(champ vide), ou @Ce qui est publié
example.comVide ou « @ » désignent le domaine lui-même. C'est juste pour un SPF ou un jeton de vérification ; c'est faux pour un DMARC, qui doit vivre sur « _dmarc », et pour une clé DKIM, qui doit vivre sur un sélecteur suivi de « ._domainkey ».
Le sélecteur DKIM a été recopié sans son suffixe
Vous saisissez
selecteur1Ce qui est publié
selecteur1.example.comIl manque « ._domainkey ». Le nom attendu est « selecteur1._domainkey », et le vérificateur ne cherchera nulle part ailleurs : il construit lui-même ce nom à partir du sélecteur annoncé dans la signature du message.
L'enregistrement a été posé sur « www »
Vous saisissez
wwwCe qui est publié
www.example.comUn SPF ou un DMARC posé sur « www » ne protège rien : le domaine d'un expéditeur est celui qui figure après l'arobase, et personne n'envoie de courrier depuis « www ». Le contrôle en haut de cette page interroge le nom que vous lui donnez — tapez le domaine tel qu'il apparaît dans vos adresses.
« Combien de temps avant que ça marche » : trois horloges, pas une
La plupart des attentes inexpliquées viennent de la deuxième, que personne ne regarde parce qu'elle n'est pas réglée par l'enregistrement qu'on vient de créer.
La durée de vie de l'enregistrement
Celle que vous avez choisie
Elle ne s'applique qu'à partir du moment où un résolveur a obtenu une réponse positive. Sur un nom qui n'existait pas encore, elle n'a rien réglé du tout.
La mémoire d'une réponse négative
Fixée par la zone
Si quelqu'un — ou un service de vérification — a interrogé le nom avant que vous ne le créiez, le résolveur a mémorisé « ce nom n'existe pas ». Il s'y tiendra pour la durée inscrite dans l'enregistrement d'origine de la zone, sans rapport avec la durée de vie que vous venez de choisir. C'est l'attente la plus fréquente, et la plus déroutante : l'enregistrement est visible pour vous, invisible pour le service.
Le cycle du service qui vérifie
Inconnue de vous
Une console qui attend une preuve de propriété a son propre rythme de revérification, sans rapport avec le DNS. Tant qu'elle n'a pas reposé la question, votre enregistrement peut être parfait et le bouton rester rouge. Reposer la question manuellement, quand c'est possible, coupe court.
La mémorisation des réponses négatives est définie par la RFC 2308 : sa durée est fixée par l'enregistrement d'origine de la zone, et la norme juge adaptées des valeurs d'une à trois heures, problématiques celles qui dépassent la journée. Le dernier nombre rendu par « dig SOA example.com +short » donne cette valeur ; la durée retenue est la plus petite entre elle et la durée de vie de l'enregistrement d'origine lui-même.
L'erreur la plus coûteuse
Le nom compte plus que la valeur
Une valeur juste au mauvais nom ne produit aucune erreur : elle n'est simplement jamais lue.
Le domaine lui-même
SPF, et les preuves de contrôle déposées pour Google ou Microsoft. C'est le seul endroit où l'on regarde spontanément — d'où l'encombrement._dmarc devant le domaine
DMARC, et jamais ailleurs. Publié sur le domaine, il n'est lu par personne, et aucun outil ne vous le dira.sélecteur._domainkey
DKIM, un par sélecteur. Le sélecteur est choisi par le service qui signe vos messages : il apparaît dans l'en-tête des messages envoyés._acme-challenge
La preuve demandée pour émettre un certificat par validation DNS. Posée et retirée automatiquement — si elle traîne, c'est qu'une émission a échoué.
Un DMARC publié au mauvais endroit n'est jamais lu, et rien ne le signale.