Un SPF ajouté et Google Search Console perdu ? Voici pourquoi

Vous ajoutez un enregistrement SPF pour que vos emails n'atterrissent plus en spam. Une semaine plus tard, Google Search Console indique que votre site est Not verified, alors que personne n'a touché à Search Console. Les deux sont liés plus souvent qu'on ne le croit, et c'est ce qui nous est arrivé.

La réponse courte : le SPF et le code de vérification Google se trouvent tous deux dans l'enregistrement TXT de votre domaine racine. Beaucoup d'interfaces DNS gardent toutes ces valeurs dans un seul enregistrement. Si vous remplacez cet enregistrement par la seule ligne SPF, le code Google disparaît. Search Console le revérifie régulièrement et, s'il manque, votre vérification expire. La solution : remettre l'ancienne valeur à côté du SPF, jamais à sa place.

Pourquoi un changement casse l'autre

L'enregistrement TXT de votre domaine racine (example.com, pas www) est une étagère partagée. On y trouve en général :

• Le SPF, la ligne qui commence par v=spf1 et indique quels serveurs peuvent envoyer des emails pour votre domaine.
• google-site-verification=…, qui prouve à Search Console que le domaine est à vous.
• D'autres preuves de propriété : MS=… pour Microsoft 365, facebook-domain-verification=…, apple-domain-verification=… et similaires.

Certaines interfaces DNS (Cloudflare, par exemple) affichent chaque valeur sur sa propre ligne : en ajouter une laisse les autres tranquilles. D'autres, comme AWS Route 53 et plusieurs bureaux d'enregistrement, affichent un seul enregistrement TXT à plusieurs lignes. Là, enregistrer avec votre seule nouvelle ligne supprime toutes celles que vous n'avez pas retapées. Les guides de configuration email le signalent rarement, car ils partent d'un enregistrement vide.

Google est clair sur la conséquence : pour rester vérifié, ne supprimez pas l'enregistrement DNS, même une fois la vérification réussie. Search Console contrôle périodiquement que le code est toujours là. S'il n'y est plus, vous recevez un avertissement et, après un délai de grâce, la propriété perd ses propriétaires vérifiés.

Ce qui nous est arrivé

Le 19 octobre 2026, nous avons configuré la messagerie Google Workspace sur six domaines que nous gérons : cinq de nos propres produits et une boutique en ligne client. La configuration a remplacé l'enregistrement TXT racine de chaque domaine par la ligne SPF de Workspace. Les emails fonctionnaient parfaitement. Rien ne semblait anormal.

Sept jours plus tard, le 26 octobre, deux de ces domaines affichaient Not verified dans Search Console. En vérifiant les six, nous avons constaté que chacun avait perdu sa valeur google-site-verification. La cause a pris dix minutes à trouver : comparer l'enregistrement TXT actuel avec son contenu une semaine plus tôt.

• Comment nous avons retrouvé les anciennes valeurs : les domaines sont sur AWS Route 53, qui journalise chaque modification DNS dans CloudTrail (conservé 90 jours). Chaque événement ChangeResourceRecordSets contenait encore l'ancien enregistrement, code Google compris.
• La correction : nous avons remis chaque code Google à côté de la ligne SPF, dans le même enregistrement, puis cliqué sur Verify dans Search Console. Les six domaines étaient de nouveau vérifiés le jour même.
• Les dégâts : aucun cette fois, car nous l'avons repéré alors que Google était encore dans son délai de grâce. Sans réaction, nous aurions perdu l'accès aux données de recherche et aux réglages de six sites.

La leçon, inscrite dans notre propre procédure : avant toute modification d'un enregistrement TXT racine, listez son contenu et conservez-le en entier.

Comment vérifier votre propre domaine

Ouvrez un terminal et lancez :

dig TXT example.com +short

Sous Windows : nslookup -type=TXT example.com. Ou utilisez n'importe quel outil de consultation DNS en ligne. Vous devriez voir quelque chose comme :

"v=spf1 include:_spf.google.com ~all"
"google-site-verification=AbC123..."

Vérifiez trois choses :

• Votre code Google est-il là ? Si Search Console est configuré pour ce domaine et qu'il n'y a pas de ligne google-site-verification, la vérification va expirer.
• Y a-t-il exactement une ligne SPF ? Deux lignes commençant par v=spf1 sont une erreur selon la norme SPF (RFC 7208). Les serveurs de réception considèrent alors votre SPF comme cassé. Si vous envoyez via deux services, fusionnez-les en une seule ligne : v=spf1 include:_spf.google.com include:mailgun.org ~all.
• Vos autres preuves sont-elles toujours là ? Microsoft, Meta, Apple et d'autres vérifient aussi leurs codes.

DKIM et DMARC ne sont pas menacés ici : ils ont leurs propres noms (selector._domainkey.example.com et _dmarc.example.com), pas la racine.

Déjà perdu ? Comment le corriger

1. Retrouvez l'ancienne valeur. Consultez l'historique des modifications ou le journal d'audit de votre hébergeur DNS (Route 53 : CloudTrail, conservé 90 jours). Certains bureaux d'enregistrement gardent aussi un historique. Pas d'historique ? Relancez la vérification dans Search Console, qui vous donnera une valeur TXT à ajouter.
2. Ajoutez, ne remplacez pas. Remettez le code Google comme ligne supplémentaire dans le même enregistrement TXT, à côté du SPF et de tout le reste.
3. Attendez le DNS. En général quelques minutes ; au maximum le TTL de l'enregistrement (souvent une heure).
4. Cliquez sur Verify dans Search Console sur la propriété indiquée Not verified.
5. Vérifiez que les emails passent toujours. Envoyez un test vers une adresse Gmail et cherchez spf=pass sous Show original.

Comment l'éviter la prochaine fois

• Avant de modifier un enregistrement TXT, copiez son contenu actuel quelque part.
• Préférez les modifications DNS qui ajoutent une valeur à celles qui remplacent un enregistrement. Dans Route 53, cela veut dire lire d'abord le jeu d'enregistrements, puis enregistrer la liste complète et fusionnée.
• Gardez une courte liste de ce que le TXT racine de chaque domaine doit contenir. Cinq minutes suffisent et vous évitent une semaine de confusion.
• Après toute modification DNS, vérifiez Search Console et envoyez un email de test le jour même.

Les problèmes de domaine, d'email et de DNS font partie de notre aide d'urgence : nous trouvons la cause, la corrigeons et vous expliquons ce qui s'est passé. Pour d'autres soucis d'email, lisez pourquoi les emails de votre site n'arrivent pas.

À lire aussi

• Emails du site non reçus ou en spam : causes et solutions
• Certificat SSL ou nom de domaine expiré : que faire ?
• Le SEO pour les développeurs : ce qu'il faut intégrer dès le premier jour