« SPF Record Not Found » — alors que vous en avez un ? Les 5 vraies causes (2026)

Publié 2026-07-08

Chiffres au 2026-06-29 · méthodologie v7. Données de recensement agrégées sur 261 millions de domaines évalués. Voir comment nous notons.

Si un outil de vérification affiche « SPF record not found » alors que vous êtes sûr d’en avoir publié un, l’enregistrement est généralement invisible plutôt qu’absent : 1 013 416 domaines — environ un sur 138 parmi ceux qui tentent de déployer SPF — publient deux enregistrements SPF ou plus, un PermError (RFC 7208 §3.2) que beaucoup d’outils signalent comme « not found », selon le recensement Defaults.Exposed portant sur 261 millions de domaines.

Il existe cinq vraies causes, toutes corrigeables en une seule session : mauvais hôte, enregistrement en double, mauvais type DNS ou guillemets mutilés, serveurs de noms incohérents, ou collision longueur/CNAME. Ci-dessous : le test de 60 secondes pour chacune, dans l’ordre où les vérifier, puis les étapes de correction.

Êtes-vous sûr que l’enregistrement existe vraiment ?

Commencez par l’hypothèse peu flatteuse, car c’est de loin la plus fréquente : sur les 261 086 232 domaines évalués dans le recensement Defaults.Exposed, 121 145 609 — soit 46,4 % — n’ont aucun enregistrement SPF. Bien des cas « mais je l’ai configuré » se révèlent être un enregistrement ajouté dans une zone de préproduction ou chez un ancien prestataire DNS qui n’est plus autoritaire. Vérifiez chez le prestataire DNS vers lequel pointent réellement vos serveurs de noms (souvent pas votre registrar) la présence d’un enregistrement TXT commençant par v=spf1. S’il n’y est vraiment pas, épargnez-vous l’enquête et allez directement corriger votre enregistrement SPF.

Comment vérifier correctement un enregistrement SPF ?

Les outils de vérification en ligne interrogent le DNS via leur propre résolveur avec cache. Pour voir la vérité, interrogez directement le serveur de noms autoritaire de votre domaine :

# find the authoritative nameservers
dig NS yourdomain.com +short

# ask one of them directly for TXT records
dig TXT yourdomain.com @ns1.yourdnshost.com +short

Sous Windows : nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

Deux règles d’interprétation. Premièrement, comptez les lignes commençant par v=spf1 — le nombre compte autant que le contenu. Deuxièmement, vérifiez que vous avez interrogé le bon nom : les serveurs de réception évaluent SPF sur le domaine figurant dans le Return-Path (RFC5321.MailFrom, l’« enveloppe expéditeur ») — pas sur l’adresse From que voient les destinataires. Si votre outil de newsletter fait rebondir le courrier via bounce.yourdomain.com, un enregistrement parfait à l’apex n’est pas celui que les serveurs de réception consultent.

Quelles sont les cinq vraies causes ?

#	Cause	Le test de 60 secondes	Le correctif
1	Enregistrement au mauvais hôte (sous-domaine vs apex)	`dig TXT` sur le domaine exact de votre Return-Path	Publiez au nom qui envoie réellement
2	Deux enregistrements `v=spf1` ou plus = PermError	`dig TXT` renvoie 2 lignes `v=spf1` ou plus	Fusionnez en un seul enregistrement
3	Publié en type d’enregistrement 99, ou guillemets mutilés	Vérifiez le type de l’enregistrement et les guillemets parasites	Republiez un seul enregistrement TXT propre
4	Caches périmés / serveurs de noms incohérents	Interrogez chaque NS directement ; comparez les réponses	Corrigez le serveur de noms en retard, attendez l’expiration de l’ancien TTL
5	Découpage >255 caractères ou conflit avec un CNAME	Cherchez des fragments de chaîne cassés ou un CNAME sur le même nom	Laissez le prestataire découper correctement les chaînes ; déplacez l’enregistrement hors du nom en CNAME

Données au 2026-06-29.

1. L’enregistrement est-il au mauvais hôte ?

Le grand classique : SPF ajouté sur mail.yourdomain.com alors que le courrier prétend venir de yourdomain.com, ou l’inverse. SPF ne s’hérite pas vers le bas — un enregistrement à l’apex ne dit rien des sous-domaines, et réciproquement. Publiez exactement au nom figurant dans votre Return-Path. Un prestataire qui envoie depuis son propre sous-domaine de rebond a besoin d’un enregistrement sur ce sous-domaine — généralement un CNAME ou un TXT fourni par le prestataire (le guide de configuration SPF chez GoDaddy montre où se trouvent ces champs).

2. Avez-vous deux enregistrements SPF ?

La cause vedette, et le message d’erreur le plus trompeur de l’authentification e-mail. La RFC 7208 §3.2 est catégorique : un domaine doit avoir exactement un enregistrement SPF. Deux ou plus, c’est un PermError — les serveurs de réception considèrent votre SPF comme nul. Certains outils signalent cet état fidèlement (« multiple records found ») ; d’autres signalent l’effet net : no valid SPF record found. Vous voyez un enregistrement dans votre panneau et concluez que l’outil est cassé. Il ne l’est pas — vous avez un enregistrement de trop.

Le recensement a trouvé 1 013 416 domaines portant deux enregistrements SPF ou plus — environ un sur 138 parmi les domaines qui tentent de déployer SPF — chacun avec un SPF de fait désactivé. Cela arrive le plus souvent lors d’un changement de prestataire : l’assistant du nouveau prestataire ajoute un enregistrement neuf au lieu de modifier l’ancien. Le correctif est une fusion, jamais un second enregistrement : combinez tout en une seule ligne v=spf1 … ~all et supprimez le reste. Notre rapport de données deux enregistrements SPF égalent zéro détaille comment un million de domaines en sont arrivés là ; si le problème a commencé après une migration, voir SPF a cessé de fonctionner après un changement de prestataire. Pendant la fusion, ne concaténez pas aveuglément tous les include: — chacun coûte des requêtes DNS face à la limite dure de 10 de SPF, échangeant un « not found » contre un PermError : trop de requêtes DNS.

3. Avez-vous publié le mauvais type d’enregistrement — ou l’interface a-t-elle mutilé la valeur ?

Aux débuts de SPF existait un type d’enregistrement DNS dédié (type 99, littéralement nommé « SPF »). Il a été déprécié : la RFC 7208 exige TXT, et les serveurs de réception n’interrogent pas le type 99. Certains panneaux DNS proposent encore « SPF » dans le menu déroulant des types d’enregistrement ; choisissez-le et votre enregistrement sera réel, bien formé, et invisible. Vérifiez la colonne type et republiez en TXT.

Le cousin plus subtil, ce sont les guillemets. Coller une valeur entourée de guillemets dans un champ qui ajoute ses propres guillemets produit ""v=spf1 …"" — qui ne commence plus par v=spf1, donc pour un vérificateur, il n’existe pas. Votre sortie dig montre la vérité ; le panneau DNS la masque souvent cosmétiquement.

4. Est-ce vraiment « encore en propagation » ?

« Laissez 24 à 48 heures pour la propagation » est le conseil le plus sur-prescrit du DNS. La propagation, ce n’est que des caches qui expirent : une fois le TTL de l’enregistrement écoulé (typiquement 1 heure, rarement plus de 24), tous les résolveurs peuvent voir la nouvelle réponse. Toujours « not found » après 24 heures ? La propagation n’est pas la cause.

Les deux vrais coupables : le cache négatif — un résolveur qui vous a interrogé avant l’ajout de l’enregistrement met en cache la réponse « aucun enregistrement » jusqu’à expiration du TTL négatif — et les serveurs de noms incohérents après une migration, quand le domaine liste encore les serveurs de noms de l’ancien prestataire à côté des nouveaux et que la moitié du monde lit une zone que vous ne modifiez plus. Interrogez directement chaque serveur de noms listé ; si les réponses divergent, vous avez trouvé. Corrigez la délégation NS chez le registrar pour que seul le prestataire que vous éditez réellement soit autoritaire.

5. L’enregistrement est-il trop long, ou bloqué par un CNAME ?

Une chaîne unique dans un enregistrement TXT plafonne à 255 caractères. Les enregistrements SPF plus longs sont légaux mais doivent être découpés en plusieurs chaînes entre guillemets au sein d’un même enregistrement — et les interfaces des prestataires DNS ratent régulièrement ce découpage, tronquant la valeur ou la coupant au milieu d’un mécanisme, si bien qu’elle ne se parse plus. Si votre enregistrement est long, cherchez dans la sortie dig une valeur qui s’arrête brutalement.

Par ailleurs, le DNS interdit un enregistrement TXT sur un nom qui porte déjà un CNAME. Si mail.yourdomain.com est un CNAME vers votre prestataire, vous ne pouvez pas y mettre aussi du SPF — certains panneaux l’acceptent puis ne servent que le CNAME. Placez l’enregistrement là où pointe le CNAME (si vous le contrôlez), ou restructurez pour que le nom émetteur ne soit pas en CNAME. Les prestataires qui gèrent proprement les TXT facilitent les deux — voir le guide de configuration SPF chez Cloudflare.

Comment corriger, étape par étape ?

Lancez le scan gratuit sur defaults.exposed — il lit votre DNS en direct et vous dit dans lequel des cinq états vous êtes avant de toucher à quoi que ce soit.
Confirmez quels serveurs de noms sont autoritaires (dig NS) et qu’ils donnent tous la même réponse.
Interrogez les TXT sur le serveur de noms autoritaire pour le domaine exact du Return-Path.
Comptez les lignes v=spf1 : zéro → publiez-en un ; deux ou plus → fusionnez en un seul.
Vérifiez que le type est TXT, que la valeur commence exactement par v=spf1, et qu’aucun guillemet parasite ni troncature ne s’est glissé.
Attendez l’expiration d’un TTL, puis relancez le scan pour confirmer que tout se résout proprement partout.

Questions fréquentes

Pourquoi l’outil dit-il « not found » alors que je vois l’enregistrement dans mon panneau DNS ? Généralement la cause 2 ou 4 : un second enregistrement v=spf1 rend les deux nuls — un PermError que certains outils signalent comme « not found », l’état dans lequel se trouvent 1 013 416 domaines au 2026-06-29 — ou votre panneau n’est pas le DNS réellement autoritaire.

Combien de temps avant que les outils voient mon correctif ? Un TTL — typiquement une heure, au plus 24. Au-delà, la « propagation » n’est pas l’explication ; repassez les cinq causes en revue, en commençant par la cohérence des serveurs de noms.

Dois-je utiliser le type d’enregistrement « SPF » que propose mon panneau DNS ? Non. Le type 99 est déprécié ; la RFC 7208 n’exige que TXT. Un enregistrement de type 99 est invisible pour les serveurs de réception modernes.

L’enregistrement est trouvé maintenant — pourquoi mon courrier échoue-t-il encore à SPF ? Parce que SPF est vérifié sur le domaine du Return-Path, pas sur l’en-tête From, et que l’enregistrement doit réellement lister les serveurs qui envoient pour vous. Être trouvé n’est que l’étape un ; le guide corriger votre enregistrement SPF couvre la réussite du test.

Ne pas avoir d’enregistrement SPF, est-ce vraiment si courant ? Oui — 121 145 609 domaines, soit 46,4 % des 261 086 232 évalués dans le recensement Defaults.Exposed (au 2026-06-29), ne publient aucun SPF. « Not found » est l’état par défaut d’Internet.

Envoyez le rapport au propriétaire

Une fois l’enregistrement résolu proprement, relancez le scan et transmettez le rapport noté au chef d’entreprise ou au client à qui appartient ce domaine. Il montre, en langage clair, ce qui était cassé, ce que vous avez corrigé, et où en est le domaine désormais — exactement la preuve qu’on leur demandera au renouvellement de la cyberassurance et dans les questionnaires de sécurité fournisseurs. Le rapport est le reçu du travail accompli.

Vérifiez votre enregistrement SPF gratuitement

Voyez dans lequel des cinq états « not found » se trouve votre domaine — en privé, visible du propriétaire uniquement.

Vérifiez votre domaine → · Corriger SPF → · SPF cassé après un changement de prestataire → · Comment nous notons → · Données agrégées uniquement. Données stockées et traitées dans l’UE.