SPF : trop de requêtes DNS — réduire en toute sécurité et réussir les contrôles

octobre 26, 2025 • février 3, 2026 • Lecture : 29 min • Views: 7

Cet article vous a aidé ?

Votre messagerie sortante est « configurée », votre DNS semble « correct », et pourtant la délivrabilité s’effondre du jour au lendemain parce que SPF renvoie un permerror : trop de requêtes DNS. Le marketing jure que rien n’a changé. Le support jure que tout a changé. Il vous revient d’être l’adulte dans la pièce.

C’est un de ces échecs qui ressemble à un problème de mise en forme mineur jusqu’à ce que vous vous rappeliez que c’est de l’authentification. Les récepteurs ne négocient pas l’authentification. Ils jugent, en silence, à grande échelle.

Ce que signifie réellement « trop de requêtes DNS »

SPF (Sender Policy Framework) est évalué par le serveur de réception. Lorsqu’il voit un message prétendant provenir de user@yourdomain, il récupère l’enregistrement SPF de votre domaine (un enregistrement TXT commençant par v=spf1) et juge si l’IP d’envoi est autorisée.

Pendant l’évaluation, certains mécanismes SPF obligent le récepteur à interroger le DNS. La spécification limite le nombre de mécanismes basés sur le DNS qui peuvent être développés. Si l’évaluation nécessite plus de 10 requêtes DNS, le récepteur doit s’arrêter et renvoyer un permerror (erreur permanente). « Permanente » signifie ici : n’essayez pas de réexécuter ; la politique est cassée.

Donc « trop de requêtes DNS » n’est pas un avertissement. C’est le récepteur qui refuse de continuer à faire vos devoirs.

Détail opérationnel important : le compte de requêtes n’est pas « combien de TXT vous voyez personnellement ». C’est combien de requêtes DNS le récepteur pourrait devoir effectuer après avoir suivi les includes, redirect et résolu les cibles A/MX. Les include peuvent exploser de façon récursive. Une plateforme marketing qui semble anodine peut entraîner la moitié de l’univers SaaS.

Blague n°1 : SPF est le seul endroit où « encore un include » semble inoffensif jusqu’à ce que ce soit toute votre personnalité et que Gmail cesse de vous répondre.

Faits et contexte utiles en réunion

SPF précède DMARC. SPF a été créé pour réduire l’usurpation d’émetteur bien avant que DMARC ne fasse de « l’alignement » un terme de comité.
La limite de 10 requêtes est une friction volontaire. Les récepteurs ne peuvent pas laisser les expéditeurs forcer une récursion DNS sans limite ; c’est une mesure de contrôle des ressources et des abus.
L’évaluation SPF se fait chez le récepteur. Le fait que votre MTA sortant « passe SPF » dans ses logs n’est pas autoritatif. Seule l’évaluation du récepteur compte.
Certains mécanismes ne coûtent pas de requêtes. Les sémantiques de ip4, ip6, all et exists importent ; seuls certains déclenchent des requêtes DNS.
Les include sont le coupable habituel. Les fournisseurs livrent des snippets SPF avec include: parce que c’est pratique pour eux, pas parce que c’est économique pour vous.
Les récepteurs varient en mise en cache et comportement du résolveur. La spécification est claire sur la limite, mais le chemin qui mène à l’atteindre peut différer selon la mise en cache DNS et les paramètres de récursion.
Les erreurs SPF peuvent tuer la délivrabilité en silence. Certains récepteurs traitent le permerror comme un échec, d’autres comme neutre avec un impact sur le score anti-spam. Dans les deux cas, vous perdez.
Un domaine peut avoir plusieurs enregistrements TXT, mais SPF ne devrait pas. Plusieurs enregistrements SPF au même nom peuvent provoquer « permerror: multiple SPF records », une défaillance distincte mais tout aussi irritante.

Mode opératoire pour un diagnostic rapide

C’est l’ordre qui permet de trouver le goulot le plus vite, sans vous lancer dans une fouille archéologique DNS de plusieurs jours.

Première étape : confirmer le mode d’échec du point de vue du récepteur

Consultez un échantillon réel d’en-têtes provenant d’un récepteur qui a rejeté ou classé le mail en spam.
Extrait le résultat SPF : pass, fail, neutral, softfail, temperror, permerror.
Si c’est un permerror avec « too many DNS lookups » (ou « exceeded maximum DNS lookups »), vous avez un problème d’expansion SPF, pas un problème de propagation DNS.

Deuxième étape : calculer le nombre de requêtes pour votre enregistrement SPF

Récupérez le TXT SPF actuel et énumérez les mécanismes.
Suivez include et redirect de façon récursive.
Comptez les mécanismes déclenchant des DNS : include, a, mx, ptr (ne pas utiliser), exists, redirect.

Troisième étape : identifier les include fournisseurs inutiles ou redondants

Listez chaque système qui envoie réellement des mails avec votre domaine : votre MTA, Microsoft 365/Google Workspace, ticketing, CRM, marketing automation, facturation, plateforme RH, etc.
Mappez ces systèmes aux mécanismes SPF. Retirez ceux qui n’envoient pas en tant que votre domaine ou qui peuvent être transférés sur un sous-domaine.

Quatrième étape : corrigez en commençant par la réduction la moins risquée

Remplacez a/mx par des ip4/ip6 explicites lorsque c’est stable.
Regroupez les include redondants (certains fournisseurs incluent d’autres fournisseurs que vous incluez déjà).
Utilisez des sous-domaines pour les expéditeurs à forte rotation et alignez DMARC en conséquence.

Mécanismes SPF qui consomment le budget de requêtes

Tout dans SPF ne coûte pas de requêtes. Le budget est consommé par les requêtes DNS effectuées pendant l’évaluation.

Mécanismes qui déclenchent généralement des requêtes DNS

include: coûte au moins une requête pour l’SPF du domaine inclus ; peut cascader.
redirect= similaire à include en termes de requêtes ; transfère l’évaluation vers un autre enregistrement.
a et mx : coûtent des requêtes pour résoudre les cibles A/AAAA ou MX puis leurs A/AAAA.
exists: coûte une requête DNS pour le nom généré.
ptr: coûte plusieurs requêtes et est fortement déconseillé ; de nombreux évaluateurs le traitent sévèrement. Ne l’utilisez pas.

Mécanismes qui ne consomment pas le quota de requêtes DNS

ip4, ip6 : plages IP directes dans l’enregistrement. Pas de DNS requis.
all : mécanisme terminateur (-all, ~all, etc.). Pas de DNS requis.

Pourquoi « seulement 10 » est problématique à l’ère du SaaS moderne

Dix requêtes était généreux lorsqu’« votre système de messagerie » signifiait un ou deux MTA et peut‑être un fournisseur de secours. En 2026, votre empreinte e-mail est un zoo : le produit envoie l’onboarding, la finance envoie les reçus, les RH envoient les mises à jour, le marketing envoie des campagnes, et une demi-douzaine d’outils envoient des notifications. SPF devient un espace de noms partagé sans modèle de propriété. C’est comme ça qu’on atteint 11 requêtes sans que personne ne s’en aperçoive.

Auditez votre SPF comme un SRE

Ne traitez pas SPF comme une chaîne. Traitez-le comme un graphe de dépendances avec domaines de défaillance.

Inventaire des expéditeurs, pas des fournisseurs

Commencez par « qui envoie réellement des mails en utilisant @yourdomain dans le RFC5321 MAIL FROM (envelope from) ? » C’est cela que SPF évalue. Un fournisseur peut envoyer un mail affichant votre domaine dans l’en‑tête From tout en utilisant son propre domaine d’enveloppe. Dans ce cas, SPF pour votre domaine racine est sans objet, et vous payez le budget de requêtes pour rien.

Séparez les expéditeurs à forte rotation

Les plateformes marketing changent fréquemment d’IP et de contenu d’include. Les MTA transactionnels (les vôtres ou un fournisseur stable) sont relativement stables. Mettre tout dans un seul enregistrement SPF couple des taux de changement sans rapport. Utilisez des sous‑domaines pour isoler la rotation : m.yourdomain pour le marketing, notify.yourdomain pour le produit, billing.yourdomain pour la facturation, etc. Alignez ensuite DMARC (ou utilisez des politiques DMARC distinctes par sous‑domaine) selon votre tolérance au risque.

Privilégiez les IP explicites quand vous les contrôlez

Si vous exploitez des MTA sortants avec des IP d’egress stables, utilisez ip4/ip6. Les include servent à déléguer à un tiers. La délégation est pratique, mais c’est aussi donner à quelqu’un d’autre le droit de dépenser votre budget de requêtes.

Soyez prudent avec l’« aplatissement »

Aplatir consiste à résoudre les includes et convertir les plages IP résultantes en ip4/ip6 explicites dans votre enregistrement. Cela réduit les requêtes, mais crée une obligation de maintenance : si le fournisseur change ses plages IP, vous devez mettre à jour votre SPF. C’est sûr uniquement si vous pouvez l’automatiser ou accepter le risque de dérive périodique.

Blague n°2 : Aplatir le SPF manuellement, c’est comme éditer à la main une table de routage : ça forge le caractère, surtout sous forme de regret.

Tâches pratiques avec commandes, sorties et décisions

Ce sont les tâches de terrain que vous pouvez exécuter depuis une machine Linux avec des outils standards. Chaque tâche indique quoi rechercher et la décision à prendre. Supposez que vous testez example.com ; remplacez par votre domaine.

Tâche 1 : Récupérer les enregistrements TXT du domaine et repérer les candidats SPF

cr0x@server:~$ dig +noall +answer TXT example.com
example.com.     300 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
example.com.     300 IN TXT "google-site-verification=abc123"

Ce que ça signifie : SPF est la chaîne TXT commençant par v=spf1. Si vous voyez plus d’un v=spf1 TXT au même nom, c’est un permerror différent (multiple SPF records).

Décision : Confirmez qu’il y a exactement un enregistrement SPF au domaine organisationnel (ou intentionnellement sur un sous-domaine). S’il y en a plusieurs, consolidez d’abord.

Tâche 2 : Vérifier les enregistrements SPF multiples (fréquent après un « nettoyage DNS »)

cr0x@server:~$ dig +short TXT example.com | grep -c "v=spf1"
1

Ce que ça signifie : Nombre d’enregistrements SPF retournés. Tout chiffre supérieur à 1 est problématique.

Décision : Si >1, fusionnez en un seul enregistrement et supprimez les autres. Les récepteurs peuvent traiter le multiple comme permerror même si l’ensemble combiné serait valide.

Tâche 3 : Extraire la chaîne SPF exacte pour analyse

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g' | grep '^v=spf1'
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all

Ce que ça signifie : Vous avez le contenu brut sans guillemets.

Décision : Sauvegardez cette chaîne dans vos notes d’incident. Traitez les changements SPF comme des changements de code : conservez un diff avant/après.

Tâche 4 : Énumérer rapidement les includes

cr0x@server:~$ dig +short TXT _spf.google.com | sed 's/"//g'
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

Ce que ça signifie : Un include peut s’étendre en plusieurs includes. C’est comme ça qu’on épuise le budget.

Décision : Construisez un graphe d’includes. Si votre enregistrement racine inclut déjà deux fournisseurs et que chacun se développe en 3–6 includes, vous êtes probablement proche de la limite.

Tâche 5 : Vérifier si vous utilisez des mécanismes coûteux (mx/a/ptr)

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g' | grep '^v=spf1' | tr ' ' '\n' | egrep '^(a|mx|ptr|exists)'
mx

Ce que ça signifie : Ce SPF utilise mx, ce qui coûte des requêtes DNS (résolution MX + A/AAAA) pendant l’évaluation.

Décision : Si vous n’avez pas besoin de mx/a, supprimez-les. Si vous en avez besoin, envisagez de les remplacer par des plages IP explicites.

Tâche 6 : Inspecter les cibles MX et leurs enregistrements A/AAAA (coût en requêtes)

cr0x@server:~$ dig +noall +answer MX example.com
example.com. 300 IN MX 10 mail1.example.com.
example.com. 300 IN MX 20 mail2.example.com.

cr0x@server:~$ dig +noall +answer A mail1.example.com
mail1.example.com. 300 IN A 203.0.113.10

Ce que ça signifie : Si SPF utilise mx, l’évaluateur peut devoir résoudre ces noms. Cela consomme des requêtes.

Décision : Si les hôtes MX servent uniquement à la réception et non à l’envoi, n’utilisez pas mx dans SPF. SPF sert à autoriser l’envoi, pas le routage entrant.

Tâche 7 : Vérifier quelle IP votre messagerie sortante utilise réellement

cr0x@server:~$ grep -R "client-ip" -n /var/log/mail.log | tail -n 3
/var/log/mail.log:98765: ... client-ip=198.51.100.24 ...
/var/log/mail.log:98766: ... client-ip=198.51.100.24 ...
/var/log/mail.log:98767: ... client-ip=198.51.100.24 ...

Ce que ça signifie : Vos logs peuvent révéler l’IP d’egress utilisée pour la livraison SMTP (dépend du MTA et du format des logs).

Décision : Si vous contrôlez l’IP et qu’elle est stable, autorisez-la explicitement avec ip4:198.51.100.24 et réduisez la dépendance aux mécanismes DNS.

Tâche 8 : Compter les requêtes avec un vérificateur SPF dédié (outil local)

cr0x@server:~$ spfquery -ip 198.51.100.24 -sender test@example.com -helo mail.example.com
pass (SPF result: pass) smtp.mailfrom=test@example.com

Ce que ça signifie : spfquery évalue SPF de façon similaire aux récepteurs. Toutes les builds n’affichent pas le nombre de requêtes, mais c’est utile pour des contrôles fonctionnels.

Décision : Utilisez‑le pour valider qu’un SPF candidat passe encore pour les expéditeurs connus après modification. Si ça bascule en fail/neutral, vous avez cassé l’autorisation.

Tâche 9 : Tracer les chemins de résolution DNS et les TTL (la mise en cache compte)

cr0x@server:~$ dig +trace TXT example.com | tail -n 8
example.com.     300 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
;; Query time: 42 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Sat Jan 03 12:00:00 UTC 2026
;; MSG SIZE  rcvd: 164

Ce que ça signifie : Vous pouvez voir les TTL et si la délégation est saine. Le TTL influence la fréquence à laquelle les récepteurs doivent refetcher les enregistrements, mais il ne change pas la limite dure de 10 requêtes.

Décision : Si les TTL sont extrêmement bas (comme 30s) pour les enregistrements liés à SPF, envisagez de les augmenter pour réduire la rotation et les échecs DNS intermittents. Cela ne résoudra pas « trop de requêtes », mais réduira les temperror.

Tâche 10 : Détecter le risque « enregistrement SPF trop long » lors de l’aplatissement

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g' | grep '^v=spf1' | wc -c
142

Ce que ça signifie : Nombre de caractères de la chaîne SPF actuelle (approximatif). Les chaînes TXT ont des contraintes de taille ; les fournisseurs et récepteurs peuvent avoir des limites d’implémentation. De plus, les réponses DNS peuvent atteindre les limites UDP si vous exagérez.

Décision : Si l’aplatissement transforme votre SPF en un zoo d’IP de 1 800 caractères, reconsidérez. Plus court n’est pas seulement plus joli ; c’est plus fiable sur DNS.

Tâche 11 : Vérifier les boucles accidentelles via redirect/include

cr0x@server:~$ dig +short TXT spf-a.example.com | sed 's/"//g'
v=spf1 include:spf-b.example.com -all

cr0x@server:~$ dig +short TXT spf-b.example.com | sed 's/"//g'
v=spf1 include:spf-a.example.com -all

Ce que ça signifie : C’est une boucle. Les évaluateurs atteindront les limites ou échoueront.

Décision : Cassez la boucle immédiatement. Les graphes SPF doivent être acycliques. Si vous avez besoin de contenu partagé, utilisez un enregistrement partagé unique inclus par d’autres, pas des références circulaires.

Tâche 12 : Valider que chaque include tiers est toujours vivant et résolvable

cr0x@server:~$ dig +noall +answer TXT spf.vendor-example.net
spf.vendor-example.net. 300 IN TXT "v=spf1 ip4:203.0.113.0/24 -all"

Ce que ça signifie : Les fournisseurs abandonnent parfois des noms SPF. Si une cible d’include renvoie NXDOMAIN ou expire, les récepteurs peuvent renvoyer temperror ou permerror selon leur comportement.

Décision : Si la cible d’include ne résout pas de façon fiable, supprimez‑la ou remplacez‑la par un mécanisme supporté. Votre SPF ne doit pas dépendre d’un nom DNS fournisseur abandonné.

Tâche 13 : Repérer l’antipattern « inclure tout »

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g' | grep '^v=spf1' | tr ' ' '\n' | grep '^include:' | sort
include:_spf.google.com
include:mailgun.org
include:spf.protection.outlook.com
include:sendgrid.net
include:spf.salesforce.com
include:spf.zendesk.com

Ce que ça signifie : Ce domaine essaie d’autoriser la moitié d’internet. Certains de ces services n’envoient peut‑être même pas avec votre domaine en envelope-from.

Décision : Remettez en question chaque include avec des preuves : « Montrez‑moi un message dont le envelope-from est notre domaine et qui provient de ce fournisseur. » Retirez les includes non nécessaires.

Tâche 14 : Vérification rapide d’un SPF réduit candidat avant publication (nom de mise en scène)

cr0x@server:~$ dig +short TXT spf-test.example.com | sed 's/"//g'
v=spf1 ip4:198.51.100.24 include:spf.protection.outlook.com -all

cr0x@server:~$ spfquery -ip 198.51.100.24 -sender test@spf-test.example.com -helo mail.example.com
pass (SPF result: pass) smtp.mailfrom=test@spf-test.example.com

Ce que ça signifie : Vous pouvez tester un enregistrement SPF candidat sur un sous‑domaine avant de modifier la production. SPF s’applique par nom de domaine, donc vous pouvez répéter l’opération.

Décision : Mettez toujours en scène quand c’est possible. Publiez sur spf-test, validez, puis intégrez le domaine réel pendant une fenêtre de changement contrôlée.

Stratégies de réduction sans mettre la messagerie en danger

Il n’existe que quelques façons honnêtes de passer sous la limite de requêtes. Quiconque promet un « compresseur » SPF magique aplatisse, supprime l’autorisation ou cache les requêtes ailleurs.

1) Supprimez ce que vous n’utilisez pas (le gain le plus simple)

La plupart des SPF gonflés portent des includes morts : fournisseurs que vous avez abandonnés, pilotes oubliés, unités régionales faisant leur propre chose. SPF n’a pas d’avertissement « include inutilisé ». Il faut de la discipline.

Comment faire en sécurité :

Collectez une semaine d’échantillons sortants pour chaque système. Regardez le Return-Path et l’identité SPF authentifiée chez les récepteurs.
Ne conservez que les includes pour les systèmes qui utilisent réellement votre domaine en envelope-from.
Si un fournisseur envoie avec son propre domaine de rebond, cessez de l’autoriser au domaine racine. Cela ne sert à rien.

2) Déplacez les expéditeurs à forte rotation vers des sous-domaines

C’est la solution adulte. Elle vous donne des enregistrements SPF indépendants et des domaines de défaillance séparés.

Exemple :

example.com : mail corporate (M365), relais internes.
m.example.com : SPF de la plateforme marketing (et DKIM/DMARC alignés sur ce sous-domaine).
notify.example.com : fournisseur de notifications produit.

À surveiller : l’alignement DMARC. Si vous utilisez DMARC avec alignement strict, assurez‑vous que le domaine visible From correspond au domaine envelope-from ou au d= DKIM approprié. Sinon vous « réparerez SPF » et échouerez toujours DMARC.

3) Remplacez `mx` et `a` par des IP explicites quand c’est stable

mx et a sont populaires parce qu’ils sont paresseux et auto‑mis à jour quand les IP changent. Ils coûtent aussi des requêtes et peuvent autoriser involontairement des hôtes que vous ne vouliez pas autoriser.

Règle pratique : Si l’ensemble d’IP change rarement et que vous pouvez le gérer, utilisez ip4/ip6. Si l’ensemble change souvent et que vous ne pouvez pas automatiser, n’aplatissez pas ; isolez avec des sous‑domaines.

4) Regroupez les include redondants

Il est courant d’inclure à la fois un domaine « parent » et un « enfant » du même fournisseur parce que différentes docs disent différentes choses. Parfois l’un inclut déjà l’autre. Parfois deux fournisseurs incluent la même infrastructure sous‑jacente. Vous payez deux fois le budget.

Méthode : Développez les includes et cherchez les chevauchements. Si include:spf1.vendor se développe en include:spf2.vendor, vous pourriez n’avoir besoin que d’un seul—selon le produit que vous utilisez réellement.

5) Utilisez `redirect=` quand vous voulez vraiment une politique canonique

redirect= n’est pas une astuce pour économiser des requêtes ; ça en coûte toujours. Ce que ça vous donne, c’est le contrôle de la politique : un enregistrement devient autoritatif, et les autres mécanismes sont ignorés après l’application du redirect.

Cas d’usage : vous gérez de nombreux domaines vanity qui doivent partager le même SPF que votre domaine principal. Publiez des enregistrements minimaux sur les domaines vanity avec v=spf1 redirect=example.com et gérez la politique en un seul endroit.

6) Aplatir — uniquement avec automatisation et garde‑fous

Aplatir peut être correct quand :

vous avez un ou deux fournisseurs tiers,
ils publient des plages IP stables,
vous pouvez rafraîchir et republier automatiquement,
vous testez avant le déploiement.

Aplatir est risqué quand vous le faites une fois, à la main, pendant un incident, puis que vous l’oubliez pendant neuf mois. Ce n’est pas de l’ingénierie. C’est du folklore.

7) Ne « résolvez » pas le problème en adoucissant `-all` en `~all`

Changer le qualificateur final ne change rien au nombre de requêtes. Ça change l’application. Parfois c’est approprié pendant une migration, mais ce n’est pas une correction pour un permerror. Si vous obtenez un permerror, le récepteur peut ne même pas atteindre le mécanisme all.

Une citation opérationnelle pour rester honnête

Idée paraphrasée, attribution : W. Edwards Deming affirmait qu’on ne peut pas gérer ce qu’on ne mesure pas. Le nettoyage SPF est un travail axé sur la mesure.

Trois mini-récits d’entreprise du terrain

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise moyenne utilisait Microsoft 365 pour le mail corporate et une plateforme marketing pour les campagnes. Quelqu’un a ajouté un nouveau système de ticketing qui « envoie des mails en votre nom », et la doc d’onboarding du fournisseur disait d’ajouter un include SPF au domaine racine.

L’hypothèse : « Les include SPF coûtent peu, et les récepteurs mettent en cache de toute façon. » Ce n’est pas ainsi que fonctionne SPF. La limite de requêtes est un plafond dur pendant l’évaluation ; la mise en cache peut aider la latence, mais elle ne vous donne pas plus de dix requêtes.

Le lundi matin, les e-mails de réinitialisation de mot de passe ont commencé à arriver en spam chez un grand fournisseur de boîtes grand public. Personne n’a vu de bounces. Il n’y en avait pas beaucoup. Le fournisseur acceptait le mail mais pénalisait les échecs d’authentification dans son scoring. L’équipe sécurité a vu les données agrégées DMARC se dégrader, mais elles arrivaient en retard et n’étaient pas liées à une alerte.

À midi, la file de support ressemblait à une attaque par déni de service menée par des humains confus. Les ingénieurs ont vérifié l’application, puis le MTA, puis les paramètres TLS. Finalement, quelqu’un a collé des en‑têtes complets dans le chat, et là c’était clair : spf=permerror (too many DNS lookups).

La correction a été ennuyeuse : retirer l’include du système de ticketing, car il n’utilisait pas le domaine de l’entreprise en envelope-from. Ils ont activé DKIM pour le domaine de rebond du ticketing et mis à jour la stratégie d’alignement DMARC. La délivrabilité est revenue. La leçon : n’approuvez jamais un include SPF sans preuve d’utilisation en envelope-from.

Mini-récit 2 : L’optimisation qui a mal tourné

Une organisation globale a décidé de « nettoyer le DNS » et réduire la dépendance aux tiers. Quelqu’un a proposé d’aplatir tous les includes SPF en plages IP explicites au domaine racine. C’était élégant : zéro include, requêtes minimales, problème résolu pour toujours.

Ils ont aplati agressivement. L’enregistrement a gonflé avec des dizaines de plages IP, proche des limites pratiques de taille de réponse DNS. Il était toujours publié, en grande partie. Certains résolveurs ont commencé à tronquer les réponses. Certains récepteurs ont retenté en TCP et ont réussi. D’autres ont expiré. Le mode d’échec était intermittent et exaspérant.

Pire : un fournisseur a changé ses plages IP sortantes. Le include SPF du fournisseur se serait mis à jour automatiquement. L’enregistrement aplati ne l’a pas fait. En un week‑end, une partie du flux marketing a commencé à échouer SPF, et DMARC a commencé à échouer pour ces messages. Une « amélioration de fiabilité » s’est transformée en piège de maintenance.

Le plan de reprise a été de désaplatir pour les fournisseurs à forte rotation, les déplacer vers des sous‑domaines, et ne garder des IP explicites que pour les MTA propres de l’organisation. Le design résultant avait un peu plus de requêtes que le rêve aplati, mais restait sous 10 et n’exigeait pas d’héroïsme chaque trimestre.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Une entreprise avec une posture e‑mail étonnamment mature traitait SPF comme de la configuration en tant que code. Chaque changement DNS passait en revue, et ils avaient une simple vérification pré‑merge : calculer la profondeur d’expansion SPF et l’estimation d’usage des requêtes pour tout enregistrement modifié.

Quand l’entreprise a acquis une autre marque, le marketing a demandé « ajoutez juste leur include plateforme à notre SPF racine pour qu’ils puissent envoyer depuis le domaine principal ». L’ingénieur en revue a demandé un message d’exemple et le comportement envelope-from du fournisseur. Il s’est avéré que la plateforme utilisait par défaut bounces.brand-vendor.tld pour SMTP MAIL FROM.

Ils ont refusé l’include sur le domaine racine. À la place, ils ont configuré m.example.com avec son propre SPF, DKIM et politique DMARC. Le domaine principal est resté petit : Microsoft 365 plus les relais corporate. Les requêtes sont restées sous le budget. La fusion n’a pas créé d’incident de délivrabilité.

Pas de feux d’artifice. Pas d’appel d’astreinte. C’est bien le but.

Erreurs courantes : symptôme → cause → correction

1) Symptôme : « spf=permerror (too many DNS lookups) » dans les en‑têtes

Cause racine : L’évaluation SPF a dépassé la limite de 10 requêtes DNS à cause de chaînes d’include et/ou des mécanismes mx/a.

Correction : Supprimez les includes inutilisés ; remplacez mx/a par des IP explicites quand c’est pertinent ; déplacez des expéditeurs vers des sous‑domaines ; évitez d’aplatir sauf si automatisé.

2) Symptôme : SPF passe parfois, parfois temperrors

Cause racine : Timeouts DNS ou NXDOMAIN intermittents pour des domaines inclus ; TTL faibles ; DNS fournisseur fragile ; problèmes de résolveur.

Correction : Augmentez les TTL pour vos enregistrements SPF ; retirez ou remplacez les includes peu fiables ; assurez la santé de votre DNS autoritatif ; envisagez la redondance des serveurs autoritatifs.

3) Symptôme : « permerror: multiple SPF records »

Cause racine : Plus d’un enregistrement TXT au même propriétaire commence par v=spf1.

Correction : Fusionnez les mécanismes en un seul enregistrement SPF. Laissez les autres TXT inchangés.

4) Symptôme : Vous coupez des includes et soudainement un flux critique échoue SPF

Cause racine : Vous avez supprimé un include qui autorisait en fait un expéditeur utilisant votre domaine en envelope-from, ou vous avez mal identifié le domaine évalué (racine vs sous‑domaine).

Correction : Identifiez le flux défaillant depuis les en‑têtes ; réautorisez le fournisseur correct ; envisagez de déplacer cet expéditeur sur un sous‑domaine dédié pour éviter un couplage futur.

5) Symptôme : L’enregistrement SPF « semble court », mais atteint toujours la limite de requêtes

Cause racine : Includes imbriqués : l’enregistrement est court parce que vous avez délégué la complexité ailleurs.

Correction : Développez les includes et comptez les requêtes sur l’arbre complet de dépendances. Réduisez à la source en éliminant les includes ou en isolant les expéditeurs.

6) Symptôme : Le récepteur indique permerror, mais vos vérifications internes indiquent pass

Cause racine : Environnement d’évaluation différent : mise en cache, comportement du résolveur, ou votre outil n’applique pas les mêmes limites ; possibilité aussi de vérifier la mauvaise identité (MAIL FROM vs HELO).

Correction : Validez contre des en‑têtes réels de récepteur ; confirmez quel domaine est évalué ; utilisez plusieurs outils et confirmez l’expansion des requêtes.

7) Symptôme : Après l’aplatissement, vous avez des échecs sporadiques chez certains récepteurs

Cause racine : Réponses TXT SPF surdimensionnées provoquant une troncature ou des problèmes de fragmentation DNS ; ou plages IP aplaties obsolètes.

Correction : Cessez d’aplatir tout. Utilisez des sous‑domaines pour les fournisseurs dynamiques. Gardez le SPF racine compact et stable.

Listes de contrôle / plan étape par étape

Plan de changement : réduire le SPF sans casser la messagerie

Collecter des preuves : pour chaque système sortant, capturez des en‑têtes d’au moins deux récepteurs (un grand public, un corporate). Identifiez le domaine envelope-from et l’IP d’envoi.
Inventorier les dépendances SPF actuelles : développez les cibles include et redirect ; listez tous les domaines impliqués.
Compter les consommateurs de requêtes : identifiez les mécanismes causant des requêtes DNS (include, a, mx, exists, redirect). Estimez le pire cas.
Supprimer le poids mort : supprimez les includes pour les fournisseurs qui n’utilisent pas votre domaine en MAIL FROM.
Isoler la rotation : créez des sous‑domaines pour les plateformes marketing/notification et déplacez les identités d’envoi. Publiez un SPF séparé par sous‑domaine.
Privilégier les IP explicites pour les MTA propriétaires : remplacez a/mx par ip4/ip6 pour les IP sortantes stables.
Mettre en scène l’enregistrement : publiez le SPF candidat sur spf-test.example.com et exécutez des vérifications pour toutes les IP d’expéditeur attendues.
Déployer avec une horloge : effectuez le changement DNS en fenêtre contrôlée ; tenez compte du TTL (si TTL = 300s, prévoyez quelques minutes pour la convergence, mais planifiez plus long).
Surveiller les signaux des récepteurs : suivez les métriques de délivrabilité, les bounces et les tendances DMARC agrégées. Confirmez les résultats SPF dans des en‑têtes échantillonnés.
Documenter la propriété : faites valider les changements SPF par une équipe ou un processus unique. « N’importe qui peut ajouter un include » est la cause de ce problème récurrent.

Checklist opérationnelle : avant d’approuver un nouvel include SPF

Avons‑nous un échantillon d’en‑têtes prouvant que le fournisseur utilise notre domaine en envelope-from ?
Combien de requêtes cet include ajoutera‑t‑il une fois développé (includes imbriqués inclus) ?
Pouvons‑nous utiliser un sous‑domaine au lieu du domaine racine ?
Pouvons‑nous autoriser par IP (si stable) au lieu de déléguer via include ?
DKIM est‑il configuré pour le domaine visible From afin de préserver DMARC même si SPF a des problèmes ?
Quel est le plan de rollback (valeur TXT précédente sauvegardée, TTL connu) ?

FAQ

1) Qu’est‑ce qui compte exactement dans la limite de 10 requêtes DNS ?

Les mécanismes qui nécessitent des requêtes DNS pendant l’évaluation : include, redirect, a, mx, ptr et exists. La limite porte sur le nombre de ces mécanismes interactifs évalués, y compris ceux tirés via includes.

2) Si j’augmente le TTL, est‑ce que ça résout « trop de requêtes DNS » ?

Non. Le TTL peut réduire les timeouts DNS et améliorer la stabilité, mais il ne change pas le plafond dur de 10 requêtes défini par la spec. Il peut aider contre les temperror, pas contre le permerror dû au nombre de requêtes.

3) Est‑ce que `redirect=` est meilleur que `include:` pour la limite de requêtes ?

Pas intrinsèquement. Les deux peuvent coûter des requêtes. redirect est utile pour centraliser la politique, surtout quand de nombreux domaines partagent un SPF. Ce n’est pas une échappatoire au budget de requêtes.

4) Pourquoi ne pas simplement passer de `-all` à `~all` ?

Parce que les échecs liés à la limite de requêtes empêchent souvent l’évaluateur d’atteindre le mécanisme all. Même s’il l’atteint, changer l’application ne réduit pas les requêtes. Cela réduit juste votre résistance à l’usurpation.

5) Puis‑je publier SPF dans plusieurs enregistrements TXT et laisser les récepteurs les combiner ?

Non. Plusieurs enregistrements SPF au même nom entraînent généralement un permerror. Vous pouvez avoir plusieurs TXT pour d’autres usages, mais un seul doit être votre politique SPF.

6) Dois‑je aplatir SPF ?

Parfois. L’aplatissement convient quand vous pouvez automatiser le rafraîchissement et la publication, et quand l’enregistrement résultant reste dans des limites pratiques de taille DNS. Si vous ne pouvez pas automatiser, préférez des sous‑domaines et moins d’include.

7) Comment les sous‑domaines aident‑ils avec la limite de requêtes ?

La limite s’applique par évaluation SPF. Si le marketing envoie en utilisant bounce@m.example.com, le récepteur évalue SPF pour m.example.com, pas pour example.com. Cela vous donne des budgets séparés de 10 requêtes et isole les changements.

8) Que faire si nous devons utiliser de nombreux fournisseurs et ne pouvons pas passer sous 10 ?

Il vous faut alors de l’architecture, pas de l’héroïsme : consolidez les fournisseurs, déplacez des flux vers des sous‑domaines, et assurez‑vous que DKIM est solide pour que DMARC puisse passer même quand SPF est contraint. Vérifiez aussi si certains systèmes peuvent cesser d’utiliser votre domaine comme envelope-from.

9) L’IPv6 rend‑elle cela plus facile ou plus difficile ?

Ni l’un ni l’autre, directement. Les mécanismes ip6 ne coûtent pas de requêtes DNS. Mais les fournisseurs dual‑stack peuvent augmenter la taille de l’enregistrement si vous aplatissez tout. Gardez‑le propre et n’autorisez que ce que vous utilisez.

10) Quelle est la différence entre SPF fail et SPF permerror ?

Fail signifie que l’enregistrement a été évalué et que l’IP n’était pas autorisée. Permerror signifie que l’enregistrement lui‑même est cassé (trop de requêtes, enregistrements multiples, syntaxe invalide). Le permerror est souvent traité comme un signal négatif sérieux.

Conclusion : prochaines étapes durables

Corriger « SPF trop de requêtes DNS » relève moins de l’astuce que de refuser que votre domaine racine devienne une décharge pour chaque checklist SaaS. Gardez le SPF racine petit, stable et propriétaire. Poussez la rotation vers des sous‑domaines. Utilisez des IP explicites quand vous les contrôlez. Déléguez seulement quand c’est nécessaire — et comptez le coût.

Prochaines étapes :

Récupérez votre SPF actuel et développez chaque include en liste de dépendances.
Pour chaque include, prouvez qu’il est nécessaire avec des en‑têtes réels montrant votre domaine en MAIL FROM.
Déplacez le marketing et les expéditeurs à forte rotation vers des sous‑domaines dédiés avec leur propre SPF/DKIM/DMARC.
Remplacez les mécanismes mx/a par ip4/ip6 pour les MTA sortants stables.
Mettez en scène et testez sur un sous‑domaine, puis déployez avec un plan de rollback et de surveillance.