Enregistrement SPF introuvable : pourquoi et comment le corriger

Un vérificateur affiche « no SPF record found », ou l'en-tête d'un message contient spf=none. Les deux signalements disent la même chose : le résolveur a demandé les enregistrements TXT d'un nom précis, et aucun ne commençait par v=spf1. Votre serveur de messagerie n'est pas en cause. La question est de savoir pourquoi la réponse était vide, et cela se résume presque toujours à une vérification, ou une publication, faite au mauvais nom.

Cet article est le parcours de diagnostic pour cette réponse vide. Si votre problème est un enregistrement qui existe mais qui échoue, lisez plutôt les articles sur les recherches DNS trop nombreuses et la limite de 10 recherches.

Ce que « introuvable » signifie vraiment

SPF se trouve dans un enregistrement TXT ordinaire. Un serveur récepteur prend le domaine du message (normalement l'expéditeur de l'enveloppe, aussi appelé adresse de retour ou Return-Path), demande ses enregistrements TXT et ne garde que ceux dont le texte commence par v=spf1. Si cette liste filtrée est vide, le résultat est none. Ce n'est pas une erreur de syntaxe ; c'est l'absence de politique.

C'est différent des deux autres situations avec lesquelles on le confond. Chacune a son propre résultat et sa propre correction.

Cause 1 : l'enregistrement est au mauvais nom

SPF est recherché au domaine utilisé dans le courrier, et nulle part ailleurs. Il n'est pas hérité d'un domaine parent et n'est pas cherché sur www. Un enregistrement publié sur www.example.com ne sert à rien pour le courrier envoyé depuis @example.com, et un enregistrement sur example.com ne sert à rien pour le courrier envoyé depuis @news.example.com.

L'erreur classique se produit dans les interfaces DNS. Pour un enregistrement à la racine (le domaine nu), le champ hôte est généralement @, mais certaines interfaces demandent de le laisser vide ou d'indiquer le domaine complet. Lisez l'aide de l'interface, puis confirmez par une requête plutôt que de vous fier au formulaire.

• Enregistrement sur www ou mail : texte correct, mauvais hôte. Déplacez-le à la racine si vous envoyez depuis @example.com.
• Domaine doublé : une interface qui ajoute la zone automatiquement transforme example.com en example.com.example.com. Interrogez ce nom et vous y trouverez votre enregistrement.
• Mauvais domaine d'envoi : vous avez vérifié example.com, mais l'expéditeur de l'enveloppe est bounce.example.net ou mail.example.com. Le serveur récepteur a examiné ce nom, pas le vôtre.

Cause 2 : vous vérifiez un autre domaine que celui du courrier

L'adresse que les gens voient dans l'en-tête From est une chose. L'expéditeur de l'enveloppe, que SPF évalue, peut en être une autre. Beaucoup de fournisseurs de services de messagerie utilisent un domaine de retour personnalisé, et certains utilisent leur propre domaine par défaut. SPF est alors évalué sur ce nom, et votre propre enregistrement n'est pas du tout consulté pour la vérification.

L'en-tête du message indique quel domaine a été évalué (voir plus bas). S'il s'agit d'un sous-domaine à vous, ce sous-domaine a besoin de son propre enregistrement, même si le domaine parent en a un parfait. Un sous-domaine qui n'envoie jamais peut publier v=spf1 -all.

Cause 3 : le texte n'est pas une chaîne SPF valide

Le vérificateur est strict sur le début de la valeur. Le texte doit commencer par v=spf1, avec un signe égal et sans espace à l'intérieur. Ces quasi-réussites produisent toutes « introuvable » :

• spf1 include:_spf.example.net ~all (le v= manque)
• v=spf include:_spf.example.net ~all (la version doit être spf1)
• v = spf1 ... (espaces autour du signe égal)
• Texte collé avec des guillemets typographiques « intelligents » copiés depuis un document ou une discussion

Les guillemets méritent une remarque. La plupart des interfaces DNS hébergées ajoutent pour vous les guillemets droits, donc en saisir vous-même peut les enregistrer comme caractères littéraux. Si une réponse dig affiche deux couches de guillemets, supprimez ceux que vous avez saisis.

Cause 4 : la zone que vous avez modifiée n'est pas la zone active

Celle-ci piège même les personnes expérimentées. Vous pouvez ajouter un enregistrement TXT parfait dans une interface DNS et ne rien voir dans le DNS public, parce que cette interface n'est pas celle qu'interroge Internet. La raison habituelle est la délégation.

• Registrar ou hébergeur DNS : le domaine est enregistré chez une société, mais ses serveurs de noms pointent vers une autre (un CDN, un hébergeur, un fournisseur DNS distinct). Seule la zone chez les serveurs de noms délégués est active. Les enregistrements ajoutés sur la page DNS propre au registrar, ou dans une zone oubliée chez un ancien fournisseur, sont ignorés.

Trouvez les serveurs de noms délégués avec la recherche NS, puis modifiez la zone exactement chez ce fournisseur. Cela explique souvent mieux que la propagation le classique « je l'ai ajouté il y a une heure et il n'apparaît toujours pas ».

Cause 5 : ancien type d'enregistrement, cache ou délai

Les premiers brouillons de SPF utilisaient un type d'enregistrement dédié (numéro 99, nommé SPF). Ce type est obsolète et les serveurs récepteurs évaluent les enregistrements TXT, donc un enregistrement publié uniquement en type SPF est invisible pour les vérifications modernes. Publiez un enregistrement TXT même si votre fournisseur DNS propose encore un type SPF.

Le délai est le dernier suspect et le plus faible. Si un résolveur a déjà appris que le nom n'avait pas d'enregistrement TXT, il peut continuer à servir cette réponse vide pendant une durée liée aux paramètres de cache négatif de la zone. Interroger directement le serveur de noms faisant autorité lève le doute. Notre article sur la durée de propagation du DNS en explique le mécanisme.

Confirmez ce que le DNS renvoie réellement

Avant de changer quoi que ce soit, posez au DNS la même question que le serveur récepteur. Sous Linux ou macOS :

dig TXT example.com +short
# a healthy answer includes a line like:
# "v=spf1 include:_spf.example.net ~all"

nslookup -type=TXT example.com

Une réponse vide, ou des réponses qui ne contiennent que des éléments comme des jetons de vérification de site, confirme « introuvable ». Pour contourner le cache de votre propre résolveur, interrogez directement un serveur de noms : dig TXT example.com @ns1.example.net +short, en utilisant un serveur de noms obtenu avec la recherche NS. Si cela renvoie l'enregistrement et que votre requête habituelle ne le fait pas, il s'agit du cache. Si aucune des deux ne le renvoie, l'enregistrement n'est pas dans la zone active.

Le vérificateur SPF de ce site interroge les enregistrements TXT du domaine saisi, garde ceux qui commencent par v=spf1 et signale « No SPF record » quand il n'en trouve aucun. S'il en trouve un, il parcourt aussi les include et compte les recherches. La recherche TXT affiche toutes les valeurs TXT d'un nom, ce qui aide quand l'enregistrement est présent mais mal formé, puisque vous voyez le texte brut.

Lisez l'en-tête d'un message en échec

Ouvrez la source originale d'un message délivré et repérez l'en-tête Authentication-Results ajouté par le serveur récepteur. La partie SPF indique le résultat et, en général, le domaine évalué. La formulation de l'en-tête varie selon le serveur récepteur ; considérez donc les exemples comme un modèle, pas comme un format exact.

spf=none (example.com does not designate permitted sender hosts)
spf=fail smtp.mailfrom=example.com
spf=permerror smtp.mailfrom=example.com

• spf=none : aucun enregistrement au domaine évalué. Utilisez cet article.
• spf=fail ou softfail : un enregistrement existe, mais l'IP d'envoi n'est pas autorisée. Ajoutez l'expéditeur ou corrigez la politique.
• spf=permerror : l'enregistrement est cassé, soit à cause de deux enregistrements, soit de trop nombreuses recherches.

Notez le domaine de smtp.mailfrom (ou de Return-Path). C'est lui, et non l'adresse From, que SPF a évalué. Pour lire les en-têtes en détail, voir comment retrouver l'expéditeur d'origine d'un e-mail.

Publiez un enregistrement minimal et sûr

Publiez un seul enregistrement TXT au nom utilisé dans l'expéditeur de l'enveloppe. Un enregistrement est une liste de mécanismes lus de gauche à droite, qui se termine par une valeur par défaut pour tous les autres.

• ip4 / ip6 : autorise une adresse ou une plage, par exemple ip4:203.0.113.25. Ne coûte aucune recherche DNS.
• include : autorise ce que l'enregistrement SPF d'un autre domaine autorise, par exemple include:_spf.example.net. Coûte une recherche.
• a : autorise les adresses IP de l'enregistrement A (ou AAAA) du domaine lui-même. Coûte une recherche.
• mx : autorise les hôtes désignés dans les enregistrements MX du domaine. Coûte une recherche ; inadapté quand votre hôte entrant n'est pas celui qui envoie.
• ~all, -all, ?all : la valeur par défaut. ~all est softfail, -all est fail, ?all est neutre.

Commencez par ~all le temps de vérifier que chaque expéditeur est listé, puis envisagez -all une fois sûr. ?all ne prend aucune position et sert surtout de transition. Une liste correcte compte plus que la terminaison, puisque les serveurs récepteurs évaluent SPF avec DKIM et DMARC.

Repères rapides pour les plateformes courantes

Les menus diffèrent et changent, mais les schémas d'échec se répètent. Vérifiez ces points pour chaque type de configuration.

• Microsoft 365 et Google Workspace : les deux publient un include à copier depuis la console d'administration ou le guide de configuration. Un « introuvable » ici signifie généralement que l'enregistrement a été envoyé au mauvais fournisseur DNS ou au mauvais hôte.
• GoDaddy et autres registrars : si les serveurs de noms ont été remplacés par ceux d'un CDN ou d'un hébergeur, la page DNS du registrar ne fait plus autorité. Modifiez les enregistrements chez le fournisseur indiqué par la recherche NS.
• Cloudflare : quand le domaine utilise les serveurs de noms de Cloudflare, ajoutez l'enregistrement TXT dans l'onglet DNS de Cloudflare.

Ce que font les serveurs récepteurs sans SPF

SPF none n'est pas un rejet automatique. La norme laisse la décision à la politique locale du serveur récepteur, donc les résultats varient. Un courrier sans SPF et sans DKIM ni DMARC pour compenser a plus de chances de paraître suspect, et certains fournisseurs publient des exigences d'authentification pour les expéditeurs en masse. Consultez les règles actuelles des fournisseurs auxquels vous écrivez.

SPF vérifie l'expéditeur de l'enveloppe ; il n'empêche donc pas à lui seul quelqu'un de falsifier votre adresse From visible, ce qui relève de DMARC. Voir SPF, DKIM et DMARC expliqués et comment vérifier un enregistrement SPF.