Vérifier un domaine avec un enregistrement TXT : fonctionnement et échecs

Débutant⏱ 3 min de lectureMis à jour le 13 octobre 2026

Google, Microsoft, Meta, Apple et des dizaines d'autres services vous demandent d'« ajouter cet enregistrement TXT pour vérifier votre domaine ». C'est la preuve de contrôle la plus simple qui soit : seul quelqu'un qui peut modifier le DNS du domaine peut publier la chaîne aléatoire qu'on lui a donnée. Quand ça marche, c'est l'affaire de deux minutes. Quand ça ne marche pas, la cause est presque toujours l'une de cinq.

Comment ça marche

Le service vous donne un jeton aléatoire. Vous le publiez dans un enregistrement TXT, le service interroge cet enregistrement via le DNS public et, s'il trouve le jeton, considère que le domaine vous appartient. La plupart utilisent le domaine lui-même (@) ; quelques-uns, un nom dédié.

Service	Nom	Valeur
Google (Search Console, Workspace)	`@`	`google-site-verification=…`
Microsoft 365	`@`	`MS=ms…`
Meta (Facebook, Instagram)	`@`	`facebook-domain-verification=…`
Apple (iCloud+ Custom Email Domain)	`@`	`apple-domain=…`
Atlassian	`@`	`atlassian-domain-verification=…`
Let's Encrypt (DNS-01)	`_acme-challenge`	`<token>`

Étape par étape

0 sur 6 fait

Copiez le jeton exactement, sans espace avant ni après.
Ajoutez l'enregistrement TXT là où le DNS du domaine est réellement hébergé — chez le fournisseur indiqué par ses enregistrements NS, qui n'est pas toujours le registraire.
Dans le champ du nom, saisissez @ (ou laissez vide) pour le domaine lui-même. La plupart des interfaces ajoutent le domaine automatiquement : taper example.com crée example.com.example.com.
Collez la valeur sans guillemets, sauf si l'interface les demande.
Enregistrez, puis vérifiez l'enregistrement avec une recherche TXT avant de cliquer sur « Vérifier ».
Gardez l'enregistrement ensuite si le service le demande : Google et Microsoft le contrôlent de nouveau plus tard.

Plusieurs enregistrements TXT au même nom, aucun problème

Un domaine peut avoir autant d'enregistrements TXT que nécessaire sur @, et chaque service retrouve le sien grâce à son préfixe. Ajoutez chaque jeton comme un enregistrement distinct :

example.com.  3600 IN TXT "google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ"
example.com.  3600 IN TXT "MS=ms48213307"
example.com.  3600 IN TXT "facebook-domain-verification=w7k2p9d4x1q8z3m6n5b0c2v7"
example.com.  3600 IN TXT "v=spf1 include:_spf.google.com ~all"     ; SPF stays a separate record

Attention : Ne collez jamais un jeton de vérification dans votre enregistrement SPF, et ne créez jamais un second enregistrement commençant par v=spf1. SPF est le seul enregistrement TXT qui doit être unique ; les mélanger casse l'authentification de votre courrier.

Pourquoi la vérification indique « enregistrement introuvable »

Mauvais endroit. L'enregistrement a été ajouté chez le registraire, mais les serveurs de noms du domaine pointent vers Cloudflare ou un hébergeur. Vérifiez d'abord les NS — c'est la cause la plus fréquente.
Mauvais nom. L'interface a ajouté le domaine, ce qui donne example.com.example.com, ou l'enregistrement est allé sur www au lieu du domaine.
Trop tôt. Le service a regardé avant que l'enregistrement existe et son résolveur a mis en cache « aucun enregistrement » — pendant la durée de cache négatif du SOA de la zone, souvent une heure. Attendez et réessayez.
Valeur abîmée. Guillemets doublés (""token""), caractère manquant ou espace copié avec le jeton.
Longues valeurs mal découpées. Les chaînes TXT de plus de 255 caractères sont découpées en plusieurs parties entre guillemets ; certaines interfaces le font mal. C'est rare pour les jetons de vérification, fréquent pour les clés DKIM.

# what the world sees — is the token there, exactly once, without extra quotes?
dig +short example.com TXT
# where does the domain's DNS really live? Edit the records there.
dig +short example.com NS

Nettoyez les anciens jetons

Les jetons de services que vous n'utilisez plus ne posent pas de problème technique, mais ils révèlent à qui regarde quels outils vous utilisez — les attaquants s'en servent pour préparer du phishing — et ils alourdissent la réponse TXT. Supprimez un jeton quand vous quittez un service, et gardez ceux que les services revérifient.

Astuce : La recherche TXT de PixDNS liste tous les enregistrements TXT d'un domaine et signale les jetons de vérification connus : on voit facilement lesquels appartiennent à des services encore utilisés.

Rechercher les enregistrements TXT d'un domaine →Suite : les enregistrements TXT →

Questions fréquentes

Puis-je supprimer l'enregistrement de vérification une fois vérifié ?

Seulement si le service indique qu'il s'agit d'un contrôle unique. Google Search Console, Google Workspace et Microsoft 365 le revérifient, et le supprimer peut annuler la vérification.

Un enregistrement TXT de vérification affecte-t-il mon site ou mon courrier ?

Non. Seul le service qui l'a demandé le lit. Les seuls enregistrements TXT qui modifient le traitement du courrier sont SPF, DKIM et DMARC.

Combien d'enregistrements TXT un domaine peut-il avoir ?

Il n'y a pas de limite fixe. Des dizaines fonctionnent ; une réponse TXT très volumineuse est plus lente et peut nécessiter TCP — une raison de plus de supprimer les jetons inutilisés.

Une vérification par CNAME est-elle différente ?

Certains services proposent un CNAME au lieu d'un TXT. Il prouve la même chose, mais un CNAME ne peut pas se trouver à l'apex ni partager son nom avec d'autres enregistrements, d'où le TXT par défaut.

Essayez-le sur votre domaine

Voyez la théorie en pratique — lancez Recherche TXT pour votre propre domaine.

Mis à jour le 13 octobre 2026

Sources