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

dig +short TXT exemple.fr

nslookup -type=TXT exemple.fr

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

É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 le 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.

Ce calcul ne se fait pas à 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 affiche le décompte réel. Proche ou au-dessus de dix, la correction est détaillée dans la limite de 10 lookups DNS.

Étape 4 : examiner la qualification terminale

Reste à examiner ce qui suit le all final :

• -all (hardfail) — l'objectif : ce qui n'est pas listé n'est pas légitime.
• ~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.

Un +all découvert à cette étape est l'urgence absolue : le 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. Quand il y en a 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 — le domaine se retrouve sans SPF effectif alors que tout le monde le croit 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 du From:. La plupart des prestataires tiers utilisent leur propre domaine d'enveloppe ; leur SPF passe alors pour eux, pas pour le domaine expéditeur, et DMARC n'en tient pas compte. Vérifier l'alignement réel suppose de regarder du côté du destinataire : c'est précisément ce que révèlent les rapports agrégés, qui affichent, source par source, si SPF s'est aligné. Si « alignement » reste flou, tout est dans comment les trois protocoles fonctionnent ensemble.

La méthode rapide : un analyseur

Toutes ces vérifications se font à la main, mais un bon analyseur les enchaîne en quelques secondes et sans erreur. Un passage du domaine dans notre analyseur gratuit confirme l'existence du SPF, valide la syntaxe, déplie l'arbre et compte les résolutions, montre la qualification terminale, signale un éventuel double enregistrement, et — couplé aux rapports — indique si les 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. La commande dig +short TXT boutique.fr renvoie :

"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 : les rapports agrégés montrent 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 a révélé trois choses qu'un simple « le SPF existe » aurait cachées : la limite des dix est frôlée, la qualification est en retrait, et l'une des 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 le courrier arrive.

Le cache DNS, à ne pas oublier au moment de corriger

Un dernier piège, découvert en général au pire moment : le DNS est mis en cache. Une fois l'enregistrement SPF corrigé, les serveurs destinataires peuvent continuer d'évaluer l'ancienne version jusqu'à expiration du TTL — parfois plusieurs heures. Deux conséquences pratiques. D'abord, il ne faut pas conclure trop vite qu'une correction « ne marche pas » : le serveur autoritatif de la zone (celui de l'hébergeur DNS) sert toujours la version fraîche et se consulte en premier, avant tout test depuis un résolveur public encore susceptible de servir l'ancienne. Ensuite, à l'approche d'un changement sensible — migration de prestataire, passage à -all — le TTL de l'enregistrement s'abaisse quelques jours avant : en cas d'erreur, la correction ou le retour arrière se propagera d'autant plus vite, et la fenêtre d'exposition restera courte.

Une check-list à garder sous la main

Pour un SPF sain, six points à valider :

• 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 ;
• les sources légitimes s'alignent dans les rapports.

Si les six cases sont cochées, le SPF fait son travail. Sinon, la liste des corrections est déjà écrite.

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 le 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 sur celui de l'expéditeur). Les 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 sa posture à celle d'un concurrent. Un analyseur accepte n'importe quel domaine.

Que faire si je n'ai aucun SPF ? En publier un, listant les vraies sources d'envoi et 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. Tout sous-domaine réellement émetteur se contrôle comme le domaine principal — et 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 s'il est resté en include : c'est tout l'intérêt, le prestataire maintient l'enregistrement à jour. Une fois ses IP figées en ip4: (ou le SPF aplati), non — le suivi revient à l'administrateur, et une vérification périodique devient indispensable.

Thomas surveille en continu

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

Analyser un domaine gratuitement ou créer un compte pour un SPF surveillé en permanence.