Erreur SPF « too many DNS lookups » : comprendre et corriger la limite des 10

C'est l'une des erreurs SPF les plus frustrantes, parce qu'elle frappe silencieusement : ton enregistrement est syntaxiquement correct, tes serveurs sont les bons, et pourtant SPF échoue. La cause est presque toujours la même : tu as dépassé la limite de dix résolutions DNS. Au-delà, les serveurs destinataires renvoient un PermError, et ton SPF cesse d'être évalué — comme s'il n'existait pas. Ce guide explique d'où vient cette limite, ce qui compte vraiment dans le décompte, comment diagnostiquer le problème, et surtout comment repasser sous la barre des dix sans casser ta délivrabilité.

Ce que dit vraiment l'erreur

Quand un serveur reçoit un message, il évalue ton enregistrement SPF pour vérifier que l'IP émettrice est autorisée. Cette évaluation peut déclencher des requêtes DNS — par exemple pour résoudre un include:. La RFC 7208 fixe un plafond strict : pas plus de dix résolutions DNS pendant toute l'évaluation. Atteins onze, et le résultat n'est ni pass ni fail, mais PermError (erreur permanente).

Le piège, c'est l'effet de cet état. Pour DMARC, un SPF en PermError ne s'aligne pas et ne passe pas. Si DKIM ne rattrape pas le coup, ton message échoue à DMARC — et selon ta politique, il part en indésirable ou il est refusé. Tu peux donc avoir un courrier parfaitement légitime rejeté à cause d'un enregistrement SPF devenu trop gourmand. C'est pourquoi cette erreur mérite une correction rapide, pas un haussement d'épaules.

Pourquoi cette limite existe

Elle n'est pas arbitraire. Sans plafond, un enregistrement SPF malicieux (ou simplement mal fichu) pourrait déclencher une cascade de requêtes DNS à chaque message reçu — un levier d'amplification idéal pour un déni de service contre les serveurs destinataires. La limite des dix résolutions borne ce coût et protège l'infrastructure de messagerie mondiale. En clair : la contrainte qui t'embête est aussi ce qui empêche que SPF devienne une arme.

Ce qui compte (et ce qui ne compte pas) dans les dix

C'est le cœur du sujet, et la source de la plupart des malentendus. Comptent dans la limite les mécanismes qui exigent une résolution DNS :

• include: — chaque include coûte au moins une résolution, et souvent plus s'il en contient d'autres en cascade.
• a et mx — résolvent des enregistrements A/MX.
• ptr — résolution inverse (à éviter, voir plus bas).
• exists: et le modificateur redirect= — comptent aussi.

Ne comptent pas : les mécanismes qui n'exigent aucune requête :

• ip4: et ip6: — des adresses littérales, zéro résolution.
• all — le mécanisme terminal (-all, ~all).

La conséquence est limpide : plus tu remplaces des include: par des ip4:/ip6:, plus tu allèges ton décompte. Et attention aux include en cascade : un include:_spf.fournisseur.com peut lui-même contenir trois ou quatre include, qui comptent tous dans tes dix. C'est ainsi qu'on dépasse la limite sans s'en rendre compte — quelques prestataires gourmands suffisent.

Diagnostiquer : combien de résolutions consommes-tu ?

Avant de corriger, mesure. Tu ne peux pas réparer ce que tu ne vois pas. Notre analyseur gratuit évalue ton SPF, déplie les include en cascade et te dit où tu en es du décompte. L'objectif est de visualiser l'arbre de ton enregistrement : chaque include que tu publies, et tout ce qu'il entraîne derrière lui. Une fois cet arbre sous les yeux, les coupables sautent aux yeux — typiquement un ou deux gros prestataires qui, à eux seuls, consomment la moitié de ton budget.

Cinq façons de repasser sous la barre

Voici les corrections, de la plus simple à la plus structurante :

1. Supprime les include inutiles. Le plus évident, et le plus souvent oublié. Cet outil que le marketing a testé il y a deux ans et n'utilise plus ? Son include traîne encore. Fais le ménage : ne garde que les sources qui envoient réellement.
2. Remplace des include par des ip4:/ip6:. Si un prestataire publie des plages d'IP stables, tu peux les inscrire en dur à la place de son include. Tu transformes des résolutions DNS en littéraux qui ne comptent pas. Attention toutefois : si le prestataire change ses IP, tu dois suivre.
3. Aplatis ton enregistrement (SPF flattening). Le flattening consiste à résoudre une fois pour toutes les include et à les remplacer par les ip4:/ip6: correspondants. Puissant, mais à manier avec méthode (les IP des prestataires évoluent). On lui consacre un guide entier : le SPF flattening, c'est quoi.
4. Sépare tes envois par sous-domaine. Plutôt que de tout empiler sur ton domaine racine, fais partir le marketing depuis mail.ton-domaine.fr et le transactionnel depuis notif.ton-domaine.fr. Chaque sous-domaine a son propre budget de dix résolutions, indépendant. C'est souvent la solution la plus durable pour les gros expéditeurs.
5. Évite le mécanisme ptr. Lent, peu fiable, et déconseillé par la RFC elle-même. S'il traîne dans ton enregistrement, retire-le.

L'erreur à ne pas commettre en corrigeant

En cherchant à réduire le décompte, certaines équipes passent leur SPF en ~all (softfail) « pour être tranquilles », voire le suppriment. Mauvaise idée. Affaiblir la qualification terminale (-all → ~all, ou pire +all) n'a aucun effet sur le décompte des résolutions — ça ne corrige rien — mais ça affaiblit ta protection. Le bon réflexe est de réduire le nombre de résolutions, pas de baisser la garde. Pour la différence entre -all et ~all, vois les mécanismes -all et ~all.

Vérifier que c'est réglé

Une fois ton enregistrement allégé, deux contrôles :

1. Repasse-le dans l'analyseur pour confirmer que le décompte est repassé sous dix et qu'il n'y a plus de PermError. Vois aussi comment vérifier ton enregistrement.
2. Surveille tes rapports agrégés : une source qui échouait à SPF par dépassement devrait désormais passer (et s'aligner). C'est la preuve définitive que la correction a porté.

Un mot connexe : ne confonds pas ce PermError de dépassement avec d'autres erreurs permanentes (syntaxe invalide, double enregistrement). Le détail des cas est dans la PermError, ce que ça signifie.

Un exemple concret : anatomie d'un dépassement

Prenons un enregistrement réaliste, celui d'une PME qui a empilé ses outils au fil des ans :

v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com
  include:_spf.salesforce.com include:servers.mcsv.net include:spf.protection.outlook.com -all

À première vue, six include — on pourrait croire à six résolutions. La réalité est plus lourde, car chaque include se déplie :

• include:_spf.google.com → 1, mais il contient lui-même plusieurs include (_netblocks, _netblocks2, _netblocks3) → ~4 au total.
• include:spf.protection.outlook.com → 1, plus ses propres sous-include → ~2-3.
• include:_spf.salesforce.com, sendgrid.net, mailchimp.com, servers.mcsv.net → 1 à 2 chacun.

Additionne : on dépasse facilement douze ou treize résolutions. Résultat : PermError, et tout le courrier de cette PME — y compris ses vraies factures via Salesforce — risque la quarantaine.

La correction tient en deux gestes. D'abord, servers.mcsv.net et mailchimp.com font doublon (même fournisseur) : on en retire un. Ensuite, on déplace le marketing (Mailchimp) sur un sous-domaine news.pme.fr avec son propre SPF. Le domaine racine retombe à six ou sept résolutions, sous la barre, et chaque flux garde son budget. Aucun courrier légitime perdu, et plus de PermError.

Questions fréquentes

La limite des dix concerne-t-elle aussi DKIM ? Non. DKIM n'a pas cette contrainte — c'est une spécificité de SPF, lié à la façon dont il résout les autorisations en DNS. D'ailleurs, dans les déploiements réels, l'alignement DKIM est souvent plus robuste que SPF, justement parce qu'il échappe à ce genre de plafond (voir comment les trois protocoles fonctionnent ensemble).

Combien de résolutions « coûte » un include ? Au minimum une, pour le résoudre. Mais s'il contient lui-même des include, a ou mx, ceux-là s'ajoutent. Un seul include de prestataire peut en consommer trois ou quatre à lui seul.

Le flattening est-il la meilleure solution ? Pas toujours. Il règle le décompte, mais il fige des IP qui peuvent changer chez ton prestataire — au risque de casser ta délivrabilité si tu ne suis pas. Pour beaucoup d'organisations, faire le ménage des include inutiles et séparer par sous-domaine suffit, sans la dette de maintenance du flattening.

Pourquoi mon enregistrement « marchait » avant ? Parce que tu étais sous la barre. Chaque nouveau prestataire ajouté pousse le décompte vers le haut ; un jour, un include de trop fait basculer en PermError. C'est un seuil, pas une dégradation progressive.

Prévenir plutôt que guérir

Le PermError n'arrive jamais par surprise quand on garde l'œil sur le décompte. Trois habitudes l'évitent durablement :

• Vérifie le coût avant d'ajouter un prestataire. Chaque nouvel include peut en cacher plusieurs ; regarde son arbre avant de le publier, pas après.
• Préfère les sous-domaines dès le départ pour les flux volumineux (marketing, notifications). Tu t'offres un budget de dix résolutions par flux, et tu n'auras jamais à tout démêler en urgence.
• Audite ton SPF périodiquement. Les parcs d'envoi dérivent : un outil arrive, un autre part sans qu'on retire son include. Un contrôle trimestriel suffit à garder l'enregistrement propre.

La règle d'or : un enregistrement SPF est vivant. Traite-le comme un actif à entretenir, pas comme une ligne qu'on publie une fois pour toutes — les quelques minutes par trimestre passées ici coûtent bien moins cher qu'une journée à chercher pourquoi tes factures tombent soudain en indésirable.

Laisse Thomas surveiller ton SPF

Le décompte SPF dérive avec chaque nouvel outil branché à ton domaine. Thomas, ton RSSI virtuel, déplie ton enregistrement, repère les include gourmands et inutiles, propose la correction la plus sûre pour ton cas (ménage, sous-domaines, ou flattening maîtrisé), et te prévient avant que tu ne franchisses la limite — pas après que ton courrier a commencé à tomber.

Analyse ton domaine gratuitement → ou crée un compte pour garder ton SPF sous contrôle.