Un enregistrement SPF qui demande plus de dix requêtes DNS est cassé, mais pas de la façon dont la plupart des guides le décrivent. L’évaluation s’arrête au premier mécanisme qui correspond au serveur qui se connecte, et un expéditeur reconnu par le deuxième terme n’atteint donc jamais le douzième. Dépasser la limite signifie que l’enregistrement peut renvoyer une erreur permanente, et le fait pour tout expéditeur non reconnu plus tôt. L’ordre décide qui est touché.
Cette distinction compte parce qu’elle change la correction. Si la limite cassait chaque message, vous le verriez immédiatement. Au lieu de cela, elle casse les expéditeurs placés à la fin de votre enregistrement, c’est-à-dire d’ordinaire la plateforme ajoutée le plus récemment et vérifiée le plus rarement.
include dit au destinataire d’aller consulter un autre enregistrement
Le mécanisme include ne recopie pas l’enregistrement d’un autre domaine dans le vôtre. Il dit au serveur destinataire d’évaluer l’enregistrement SPF de cet autre domaine comme une vérification distincte et d’en utiliser le résultat : si l’adresse IP qui se connecte y réussit, le include correspond et l’évaluation s’arrête.
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Cet enregistrement dit : consulte la liste de Google, puis celle de SendGrid, puis applique ~all à tout ce qui n’a correspondu à aucune des deux. Chaque include remet au destinataire un nouvel enregistrement à analyser, qui peut lui-même contenir d’autres termes include, et c’est là que part le budget.
Le mot induit en erreur sur un point précis. include ne renvoie qu’une réussite ou une absence de correspondance. Un -all à l’intérieur d’un enregistrement inclus ne rejette pas votre courrier ; il signifie seulement que cet enregistrement n’a pas correspondu, et l’évaluation se poursuit avec votre terme suivant. Seul le all de votre propre enregistrement décide du résultat.
Cinq mécanismes dépensent le budget, et trois sont gratuits
La RFC 7208, section 4.6.4, plafonne une évaluation SPF à dix termes qui interrogent le DNS. Dépasser ce plafond est une erreur permanente de niveau MUST, pas un avertissement souple.
| Terme | Coûte une requête |
|---|---|
include | Oui, plus tout ce qu’il contient |
a | Oui |
mx | Oui |
ptr | Oui, et il est obsolète |
exists | Oui |
ip4 | Non |
ip6 | Non |
all | Non |
exp | Non |
Deux détails de ce tableau sont souvent rapportés de travers. Un terme mx coûte une requête pour le terme, pas une par enregistrement MX renvoyé, et un enregistrement qui liste cent adresses IP avec ip4 ne dépense absolument rien. Ce second point est toute la base de l’aplatissement SPF.
La macro %{p} est elle aussi imputée au même budget de dix, parce que son expansion exige une requête inverse.
Le décompte porte sur les termes évalués, pas sur les domaines nommés
C’est la règle qui fait qu’un enregistrement coûte plus cher qu’il n’en a l’air. La limite compte chaque terme interrogeant le DNS qu’un destinataire évalue pendant une vérification, et un domaine atteint par deux branches différentes est évalué deux fois.
Si votre enregistrement inclut deux prestataires et que tous deux incluent le même domaine d’infrastructure partagée, tout le sous-arbre de ce domaine est payé deux fois. Compter les noms de domaine distincts donne un nombre inférieur à celui qu’atteindra un destinataire, et c’est pourquoi un enregistrement qui ressemble sur le papier à six requêtes peut produire un permerror en pratique.
Deux cas voisins ont la même nature :
- Une boucle est une erreur permanente, pas une branche à ignorer. Si A inclut B et que B inclut A, un destinataire ne s’arrête pas discrètement : il fait échouer l’enregistrement.
- Les termes placés après
allne sont jamais évalués.allcorrespond toujours, donc tout ce qui le suit est du code mort et ne coûte rien. Unredirectposé à côté d’unallest inerte pour la même raison.
Au-delà de la limite, ce sont les expéditeurs de la fin qui échouent
Un destinataire évalue vos termes dans l’ordre et s’arrête à la première correspondance. Un seul enregistrement cassé produit donc trois issues différentes selon qui envoie.
- Un expéditeur reconnu avant l’épuisement du budget réussit normalement. Rien n’est cassé pour lui, et rien n’apparaît dans vos journaux.
- Un expéditeur reconnu après la dixième requête reçoit une erreur permanente. La plupart des destinataires traitent un permerror comme un échec et non comme un enregistrement absent, et DMARC ne voit donc aucune réussite SPF.
- Un expéditeur absent de votre enregistrement atteint votre terme
all, exactement comme prévu, si l’évaluation survit jusque-là.
Le symptôme concret est donc que le courrier d’une seule plateforme se met soudain à échouer l’authentification alors que tout le reste paraît correct. Si cette plateforme a été ajoutée à la fin de l’enregistrement, elle est la première à passer par-dessus bord.
Cela veut aussi dire qu’une correction peut être gratuite. Déplacer votre expéditeur au plus gros volume en tête de l’enregistrement ne réduit pas le total, mais fait en sorte que cet expéditeur soit reconnu avant que le budget ne soit dépensé. Cela achète du temps, cela ne règle rien.
Comment trouver le vrai chiffre
Compter à la main n’est pas fiable, parce que vous ne pouvez pas voir dans l’enregistrement d’un prestataire sans le résoudre, et parce que les prestataires modifient le leur sans vous prévenir. Passez le domaine dans un outil de vérification SPF gratuit, qui parcourt l’arbre entier, résout chaque include de façon récursive et rapporte le total qu’un destinataire atteindrait réellement, plutôt que le nombre de termes que vous avez saisis.
Ce qu’il faut regarder dans le résultat :
- Le total face à la limite de dix. Tout ce qui dépasse signifie que l’enregistrement peut produire un permerror.
- Quelle branche coûte cher. Un prestataire est le plus souvent responsable de l’essentiel du coût, et les prestataires diffèrent énormément.
- Les sous-arbres dupliqués. Une infrastructure partagée atteinte deux fois est le dépassement caché le plus courant.
- Les requêtes vides. Un terme qui ne résout vers rien dispose de son propre budget distinct, et un
includepointant vers un domaine sans enregistrement SPF est une erreur permanente dès la première occurrence. - Tout ce qui suit
all. Les termes morts sont inoffensifs, mais ils signalent en général un enregistrement édité par plusieurs personnes qui ne l’ont pas lu.
Sur les domaines que nous testons pour le Unspam 2026 Email Deliverability Benchmark, 93 % publient un enregistrement SPF valide : le défaut courant dans ce domaine n’est donc pas un enregistrement absent, mais un enregistrement qui a discrètement dépassé son budget.
Quatre façons de repasser sous dix
À peu près par ordre de préférence.
Retirez ce que vous n’utilisez plus. La plupart des enregistrements en dépassement portent un prestataire par lequel plus personne n’envoie depuis deux ans. C’est gratuit, c’est définitif, et c’est presque toujours possible.
Remplacez un include par des plages ip4 là où le prestataire en publie de stables. Un terme ip4 ne coûte rien. Le revers est que la maintenance vous revient : quand le prestataire change d’adresses IP, votre courrier échoue et personne ne vous le dit. Ne le faites que là où le prestataire documente une plage stable et s’engage à signaler les changements.
Déplacez l’envoi vers un sous-domaine. Votre plateforme marketing peut envoyer depuis mail.example.com avec son propre enregistrement SPF et son propre budget de dix. C’est la correction structurelle, elle passe à l’échelle, et elle sépare au passage les réputations.
Aplatissez l’enregistrement avec un service. L’aplatissement SPF résout chaque include et publie à votre place la liste d’adresses IP obtenue, en la rafraîchissant automatiquement. Cela fonctionne, et cela fait de la disponibilité d’un tiers une dépendance de l’authentification de votre courrier. Traitez-le comme la dernière option, pas comme la première.
Si vous construisez un enregistrement plutôt que d’en réparer un, un générateur d’enregistrement SPF produit un enregistrement de départ correct, et notre guide des enregistrements SPF couvre la syntaxe en entier.
Que vérifier une fois l’enregistrement sous la limite
Une réussite SPF est nécessaire mais ne suffit pas à elle seule, parce que DMARC exige que le domaine SPF s’aligne avec l’adresse de votre en-tête From, et parce que SPF casse au réacheminement quel que soit le soin apporté à l’enregistrement. Notre guide de l’authentification des e-mails explique comment les trois enregistrements dépendent les uns des autres et pourquoi c’est DKIM, et non SPF, qui survit à une liste de diffusion.
Revérifiez le total chaque fois que vous ajoutez une plateforme d’envoi, puis de nouveau quelques mois plus tard même si vous n’avez rien changé, car le décompte inclut les enregistrements des prestataires et ceux-ci bougent sous vos pieds. Pour voir à quoi ressemble un vrai message chez un destinataire, avec le résultat SPF à côté de tout ce qui décide du placement, faites un test de spam gratuit.
