Vérificateur SPF :
votre enregistrement respecte-t-il la limite de 10 requêtes ?
Indiquez un domaine — nous récupérons ses enregistrements TXT, isolons le v=spf1, déployons récursivement chaque include, et comptons les requêtes DNS par rapport au budget de 10 fixé par SPF. Dépasser ce budget fait basculer SPF en permerror en silence — protection coupée, sans rejet, sans avertissement.
Quatre façons dont SPF cesse de protéger sans prévenir
Quand SPF casse, le courrier part quand même — les serveurs destinataires cessent simplement de le vérifier. Chacun de ces quatre cas est invisible depuis votre boîte d’envoi — et évident dans une analyse complète.
La limite de 10 requêtes
Chaque include, a, mx coûte une requête DNS — y compris les includes imbriqués. Le budget est de 10. La requête n° 11 ne dégrade rien : l’enregistrement entier renvoie permerror et SPF s’arrête.
RFC 7208 §4.6.4Le second enregistrement
Deux enregistrements TXT commençant par v=spf1 ne fusionnent pas — les deux deviennent invalides, instantanément. La cause classique : un plugin ou une agence a « ajouté » SPF au lieu de modifier l’enregistrement déjà présent.
plusieurs = permerror+all autorise tout expéditeur
+all signifie « et tous les autres passent aussi ». Cela autorise l’ensemble d’Internet à envoyer des messages en votre nom — spammeurs compris. Un seul caractère le sépare de -all, qui signifie l’inverse.
pire que pas d’enregistrementL’include obsolète
Le prestataire que vous avez quitté en 2023 figure toujours dans votre enregistrement. Si son domaine a disparu, ce sont des requêtes à vide et un permerror. S’il est toujours actif, ses clients actuels peuvent encore envoyer du courrier qui passe pour le vôtre.
à auditer chaque année-all, ~all, ?all et les cas particuliers
Le dernier mécanisme décide du sort du courrier envoyé depuis une IP que vous n’avez pas listée. Quelques cas particuliers règlent le reste.
« Absent de ma liste ? Je rejette. » La fin stricte, la bonne — à condition que la liste qui précède soit complète et que l’enregistrement s’analyse correctement. La rigueur ne compte que si le reste est juste.
« Absent de ma liste ? J’accepte, mais je le signale. » Pensé comme une étape de déploiement, gardé ensuite pour toujours. Avec DMARC en plus, le courrier non autorisé échoue quand même — sans DMARC, c’est un simple haussement d’épaules.
« Absent de ma liste ? Aucun avis. » Strictement équivalent à ne publier aucun SPF — les destinataires n’apprennent rien. Généralement un reste d’un modèle copié-collé.
« Absent de ma liste ? Il passe quand même. » L’ensemble d’Internet est désormais autorisé à envoyer au nom de votre domaine — et un courrier qui devrait avoir l’air falsifié obtient un pass SPF à la place.
Correspondance DNS inverse : lente, peu fiable, et formellement « à ne pas utiliser » (SHOULD NOT) depuis 2014. Elle consomme une requête, peut se tromper de cible en silence, et certains destinataires l’ignorent purement et simplement.
Trop de requêtes, deux enregistrements, une erreur de syntaxe, un include mort — le résultat est le même : les destinataires considèrent votre domaine comme n’ayant aucun SPF valide. Le courrier continue de circuler. Personne ne vous prévient.
Comment fonctionne le budget de 10 requêtes
La RFC 7208 plafonne le nombre de requêtes DNS qu’un destinataire consacre à l’évaluation de votre enregistrement. Ce plafond, c’est tout l’enjeu — et la majeure partie de votre budget est dépensée par les enregistrements d’autres organisations :
- Ce qui consomme le budget : include, a, mx, ptr, exists, redirect — une requête chacun, imbrications comprises.
- Ce qui est gratuit : ip4, ip6 et all — des valeurs littérales, sans DNS nécessaire. C’est pour ça que l’« aplatissement » fonctionne.
- Un include, ce n’est presque jamais une seule requête : celui de Mailgun en vaut 5, celui de Salesforce 2. Un enregistrement qui « n’a pourtant que cinq includes » peut atteindre 11 sans que personne n’y touche.
- Deux requêtes peuvent ne renvoyer aucune réponse — c’est la limite des requêtes à vide. Les includes morts et les fautes de frappe l’épuisent vite, et le résultat est le même permerror.
Où part le budget
par prestataire · revérifié en juillet 2026Ce que vous pouvez vérifier vous-même
Un seul dig renvoie votre enregistrement. Déployer à la main chaque include imbriqué, voilà la partie lente.
Questions fréquentes sur SPF
Saisissez votre domaine ci-dessus. Nous récupérons ses enregistrements TXT, vérifions qu’un seul commence par v=spf1 (en avoir deux est un échec immédiat — ils ne fusionnent pas, ils meurent tous les deux), puis analysons chaque mécanisme selon la RFC 7208 : chaque include est déployé récursivement en arbre, chaque requête DNS est comptée sur le budget de 10, la politique all finale est notée, et chaque plage IP autorisée par votre enregistrement est additionnée dans une seule liste. Gratuit, sans inscription.
Les destinataires qui évaluent SPF exécutent au maximum 10 mécanismes interrogeant le DNS par vérification (RFC 7208 §4.6.4). include, a, mx, ptr, exists et redirect comptent tous, y compris ceux qui se cachent dans les includes de vos prestataires. À la requête n° 11, l’évaluation s’interrompt avec permerror. Rien ne rejette de votre côté ; DMARC considère simplement que votre domaine ne publie aucun SPF. La panne arrive progressivement, une inscription à la fois, et ne s’annonce jamais.
-all est la destination : rejeter ce qui n’est pas à vous. ~all est le trajet : « signaler, sans rejeter ». C’est le bon réglage tant que vous découvrez encore des expéditeurs — cet outil de facturation dont personne n’avait parlé. C’est aussi le plus sûr si un e-mail légitime perdu vous coûte plus cher qu’un e-mail falsifié. Deux réserves : avec DMARC en place, la différence pratique se réduit, car DMARC fait échouer le courrier non autorisé dans les deux cas. Et un -all placé à la fin d’un enregistrement qui dépasse la limite de requêtes, c’est de la rigueur accrochée à un cadavre — le permerror l’emporte.
Non — et le mode d’échec est vicieux. La RFC 7208 précise que plusieurs enregistrements v=spf1 font renvoyer permerror à la vérification : ni « le premier gagne », ni « ils fusionnent » — les deux deviennent invalides. Cela arrive généralement innocemment : un plugin de site, un assistant d’ESP ou un second administrateur « ajoute SPF » sans remarquer l’enregistrement déjà présent. La correction prend une minute : fusionnez tous les mécanismes dans un seul enregistrement, supprimez les autres. Cet outil compte vos enregistrements en tout premier, avant tout le reste, exactement pour cette raison.
Il termine votre enregistrement par « … et tous les autres passent aussi ». Chaque IP d’Internet devient un expéditeur autorisé pour votre domaine : un spammeur qui falsifie votre adresse obtient un pass SPF, et si votre politique DMARC repose sur l’alignement SPF, ce courrier falsifié peut aussi passer DMARC — votre authentification témoigne désormais en faveur de l’attaquant. C’est réellement pire que de ne publier aucun SPF, car l’« absence d’enregistrement » rend les destinataires méfiants, alors que « +all » les rassure. On le rencontre sur le terrain comme une « correction » de délivrabilité malavisée. Si cet outil en trouve un, il ne fera pas dans la nuance.
Seul, non. SPF valide l’expéditeur d’enveloppe (l’adresse utilisée dans la conversation SMTP), pas le champ From : que voit votre destinataire. Un falsificateur peut passer SPF sur son propre domaine tout en affichant le vôtre. Combler cet écart, c’est le rôle de DMARC : il exige que le From visible s’aligne avec ce que SPF ou DKIM ont validé, et indique aux destinataires quoi faire quand ce n’est pas le cas. La pile complète, c’est SPF + DKIM + DMARC, et cet outil s’assure que le volet SPF tient debout, car un permerror ici sabote silencieusement les deux autres.
Par ordre de facilité : retirez ce qui n’envoie rien — a et mx sont des gains gratuits si votre serveur web et vos MX n’envoient jamais de courrier sortant. ptr se retire toujours sans risque. Éliminez les prestataires morts — chaque include doit correspondre à un service que vous payez encore. Séparez par sous-domaine — laissez la newsletter envoyer depuis news.yourdomain.com avec son propre enregistrement et son propre budget. En dernier recours, l’aplatissement : remplacer les includes par leurs plages ip4/ip6 littérales ne coûte aucune requête. Mais cela fige une copie du réseau de vos prestataires — quand ils le renumérotent, votre enregistrement pourrit en silence. N’aplatissez qu’avec un outil ou une surveillance qui revérifie régulièrement.
Continuer l'exploration
Les outils gratuits, c'est un début.
Uptimia veille sur la santé de vos sites.
Disponibilité, SSL, expiration de domaine, vitesse de page, transactions — surveillés depuis 171+ emplacements dans le monde. 30 jours gratuits.