Comment vérifier son enregistrement SPF (et ce qu'il faut regarder)

« On a bien un SPF. » Cette phrase rassure à tort : la présence d'un enregistrement SPF ne dit rien de sa qualité. Un SPF peut exister et pourtant déborder la limite des résolutions, contenir une faute de syntaxe, autoriser le monde entier, ou n'aligner aucune de tes sources. Vérifier son SPF, c'est donc bien plus que confirmer qu'il est là. Ce guide te montre, étape par étape, comment trouver ton enregistrement, le lire correctement, et repérer les problèmes qui sapent silencieusement ta délivrabilité.

Étape 1 : trouver ton enregistrement

Ton SPF est un enregistrement TXT publié à la racine de ton domaine. Pour le voir, tu peux interroger le DNS directement. En ligne de commande :

dig +short TXT ton-domaine.fr

ou, sous Windows :

nslookup -type=TXT ton-domaine.fr

Parmi les enregistrements TXT renvoyés, le SPF est celui qui commence par v=spf1. S'il y en a un, note-le ; s'il y en a deux qui commencent par v=spf1, tu tiens déjà un problème (voir plus bas). S'il n'y en a aucun, ton domaine n'a pas de SPF du tout — c'est la première chose à corriger.

Étape 2 : lire la syntaxe

Un enregistrement SPF se lit de gauche à droite, mécanisme par mécanisme. Exemple :

v=spf1 include:_spf.google.com ip4:203.0.113.0/24 -all

• v=spf1 — la version, obligatoire en tête.
• include:_spf.google.com — autorise les serveurs listés par Google.
• ip4:203.0.113.0/24 — autorise une plage d'adresses en dur.
• -all — la qualification terminale : tout le reste est refusé.

Chaque mécanisme peut être précédé d'un qualificateur (+, -, ~, ?). Vérifie qu'il n'y a pas de fautes courantes : espace manquant, deux-points oubliés, un include qui pointe vers un domaine inexistant. Une seule faute peut faire basculer tout l'enregistrement en erreur.

Étape 3 : compter les résolutions DNS

C'est le contrôle le plus souvent négligé. Chaque include, a, mx, ptr, exists et redirect coûte au moins une résolution DNS, et le total ne doit pas dépasser dix. Au-delà, c'est le PermError, et ton SPF n'est plus évalué. Le piège : les include de prestataires se déplient en plusieurs résolutions chacun, donc le compte « visible » trompe.

Tu ne peux pas faire ce calcul à l'œil sur un enregistrement complexe — il faut déplier l'arbre. C'est exactement ce que fait notre analyseur gratuit : il résout récursivement chaque include et t'affiche le décompte réel. Si tu es proche ou au-dessus de dix, vois la limite de 10 lookups DNS pour corriger.

Étape 4 : examiner la qualification terminale

Regarde ce qui suit le all final :

• -all (hardfail) — l'objectif : ce qui n'est pas listé n'est pas toi.
• ~all (softfail) — un compromis de transition, acceptable mais pas une cible.
• ?all (neutral) — n'affirme rien ; à remplacer.
• +all (pass) — danger : autorise tout le monde. À corriger immédiatement.

Si tu trouves +all, c'est l'urgence absolue : ton domaine s'auto-déclare usurpable. Le détail des qualificateurs est dans les mécanismes -all et ~all.

Étape 5 : vérifier le double enregistrement

Un domaine ne doit avoir qu'un seul enregistrement v=spf1. Si tu en trouves deux (par exemple un ajouté par l'équipe marketing et un autre par l'IT), beaucoup de destinataires considèrent la configuration comme invalide et ignorent les deux — te laissant sans SPF effectif alors que tu te crois couvert. La correction consiste à fusionner les deux en un seul enregistrement, en combinant leurs mécanismes (et en surveillant la limite des dix résolutions au passage).

Étape 6 : confirmer l'alignement, pas seulement le passage

Voici le contrôle le plus subtil, et le plus important pour DMARC. Un SPF qui « passe » techniquement ne sert à rien s'il ne s'aligne pas avec le domaine de ton From:. La plupart des prestataires tiers utilisent leur propre domaine d'enveloppe ; leur SPF passe alors pour eux, pas pour toi, et DMARC n'en tient pas compte. Pour vérifier l'alignement réel, tu dois regarder du côté du destinataire : c'est précisément ce que révèlent tes rapports agrégés, qui affichent, source par source, si SPF s'est aligné. Si « alignement » te paraît flou, lis comment les trois protocoles fonctionnent ensemble.

La méthode rapide : un analyseur

Tu peux faire toutes ces vérifications à la main, mais un bon analyseur les fait en quelques secondes et sans erreur. Passe ton domaine dans notre analyseur gratuit : il confirme l'existence du SPF, valide la syntaxe, déplie l'arbre et compte les résolutions, te montre la qualification terminale, signale un éventuel double enregistrement, et — couplé à tes rapports — t'indique si tes sources s'alignent réellement. C'est le contrôle complet, pas seulement le « il existe ».

Une vérification de bout en bout, en pratique

Déroulons une vérification complète sur un domaine fictif, boutique.fr. Tu lances dig +short TXT boutique.fr et tu obtiens :

"v=spf1 include:_spf.google.com include:shopify.com include:sendgrid.net include:_spf.mailjet.com ~all"

Premier réflexe : un seul v=spf1 ? Oui, bien. Syntaxe ? Correcte. Qualification ? ~all — acceptable, mais on note qu'on vise -all. Maintenant le point critique, le décompte : ces quatre include se déplient. Google ≈ 4 résolutions, Shopify ≈ 2, SendGrid ≈ 1-2, Mailjet ≈ 2. Total : autour de dix, à la limite. Un cinquième prestataire ferait basculer en PermError. Verdict : l'enregistrement « marche » aujourd'hui mais est fragile, et toute nouvelle source devra passer par un sous-domaine.

Dernière étape, l'alignement : tu ouvres tes rapports agrégés et tu constates que le courrier Shopify passe SPF mais ne s'aligne pas (Shopify utilise son propre domaine d'enveloppe). Conclusion concrète : pour que les notifications de commande comptent pour DMARC, il faut activer une signature DKIM alignée côté Shopify — le SPF seul ne suffira pas.

Cette vérification de cinq minutes t'a appris trois choses qu'un simple « le SPF existe » t'aurait cachées : tu frôles la limite des dix, ta qualification est en retrait, et l'une de tes sources clés ne s'aligne pas. C'est exactement la différence entre constater une présence et juger une qualité — et c'est cette différence qui décide si ton courrier arrive.

Une check-list à garder sous la main

Pour un SPF sain, vérifie que :

• il existe un seul enregistrement v=spf1 ;
• la syntaxe est valide (pas de faute, pas d'include mort) ;
• le décompte de résolutions est à dix ou en-dessous ;
• la qualification terminale est -all (ou ~all en transition assumée) ;
• il n'y a pas de +all ni de ptr ;
• tes sources légitimes s'alignent dans les rapports.

Si les six cases sont cochées, ton SPF fait son travail. Sinon, tu sais exactement quoi corriger.

Questions fréquentes

À quelle fréquence vérifier mon SPF ? Au moins à chaque ajout ou retrait d'un prestataire d'envoi, et idéalement lors d'une revue trimestrielle. Les parcs d'envoi dérivent, et un enregistrement sain aujourd'hui peut déborder la limite des dix demain.

Mon SPF passe dans un testeur, est-ce suffisant ? Pas forcément. Beaucoup de testeurs confirment que la syntaxe est valide, mais ne vérifient ni le décompte réel des résolutions (en dépliant les cascades), ni l'alignement avec ton From:. Ce sont justement ces deux points qui font la différence en production.

Pourquoi mon courrier échoue alors que mon SPF « existe » ? Trois causes fréquentes : un PermError par dépassement des dix résolutions, une source légitime non listée, ou un passage SPF qui ne s'aligne pas (le prestataire signe sur son domaine, pas le tien). Tes rapports agrégés tranchent.

Puis-je vérifier le SPF d'un autre domaine ? Oui — le SPF est public. C'est utile pour auditer un fournisseur ou comparer ta posture à celle d'un concurrent. Un analyseur accepte n'importe quel domaine.

Que faire si je n'ai aucun SPF ? Publie-en un, en listant tes vraies sources d'envoi et en terminant par -all (ou ~all le temps de l'inventaire). C'est la première brique de l'authentification, avant DKIM et DMARC.

Faut-il vérifier le SPF de mes sous-domaines séparément ? Oui. Un sous-domaine d'envoi (news., notif.) a son propre enregistrement SPF, indépendant de la racine. Si tu envoies depuis un sous-domaine, vérifie-le comme le domaine principal — et souviens-toi qu'il dispose de son propre budget de dix résolutions, ce qui est souvent un avantage à exploiter.

Le SPF se met-il à jour tout seul quand un prestataire change ses IP ? Seulement si tu l'as laissé en include : c'est tout l'intérêt, le prestataire maintient l'enregistrement pour toi. Si tu as figé ses IP en ip4: (ou aplati ton SPF), non — c'est à toi de suivre, et une vérification périodique devient indispensable.

Laisse Thomas surveiller pour toi

Vérifier son SPF une fois, c'est bien ; le garder sain dans la durée, c'est mieux. Thomas, ton RSSI virtuel, contrôle en continu ton enregistrement — syntaxe, décompte de résolutions, qualification, double enregistrement — et vérifie sur tes rapports que tes sources s'alignent vraiment. Il te prévient quand quelque chose dérive, avant que ton courrier n'en pâtisse.

Analyse ton domaine gratuitement → ou crée un compte pour un SPF surveillé en permanence.