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

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 : chaque include: remplacé par un ip4:/ip6: allège d'autant le 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 les dix du domaine évalué. C'est ainsi qu'on dépasse la limite sans s'en rendre compte — quelques prestataires gourmands suffisent.

Diagnostiquer : combien de résolutions sont consommées ?

Avant de corriger, il faut mesurer : on ne répare pas ce qu'on ne voit pas. Notre analyseur gratuit évalue le SPF, déplie les include en cascade et situe le décompte exact. L'objectif est de visualiser l'arbre de l'enregistrement : chaque include publié, 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é du budget.

Cinq façons de repasser sous la barre

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

1. Supprimer 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. Place au ménage : ne subsistent que les sources qui envoient réellement.
2. Remplacer des include par des ip4:/ip6:. Quand un prestataire publie des plages d'IP stables, elles s'inscrivent en dur à la place de son include. Des résolutions DNS deviennent alors des littéraux qui ne comptent pas. Attention toutefois : si le prestataire change ses IP, il faut suivre.
3. Aplatir l'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éparer les envois par sous-domaine. Plutôt que de tout empiler sur le domaine racine, faire partir le marketing depuis mail.exemple.fr et le transactionnel depuis notif.exemple.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. Éviter le mécanisme ptr. Lent, peu fiable, et déconseillé par la RFC elle-même. S'il traîne encore dans l'enregistrement, il est à retirer.

Et une voie avancée : les macros exists

Les cinq correctifs ci-dessus réduisent le décompte. Il existe une sixième voie, plus technique, qui le contourne : le mécanisme exists combiné à des macros SPF autorise un nombre illimité d'IP en une seule résolution, la décision étant déléguée à une zone DNS pilotée par l'expéditeur. Réservée aux gros émetteurs à parc dynamique et non sans contreparties, cette voie est détaillée dans les macros SPF et le mécanisme exists.

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 la 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, voir les mécanismes -all et ~all.

Vérifier que c'est réglé

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

1. Un nouveau passage dans l'analyseur pour confirmer que le décompte est repassé sous dix et qu'il n'y a plus de PermError. Voir aussi comment vérifier un enregistrement SPF.
2. Une surveillance des 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 : ce PermError de dépassement ne se confond pas avec les 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.

Total : 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ée à 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 le prestataire — au risque de casser la délivrabilité faute de suivi. 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 qu'il était 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érifier le coût avant d'ajouter un prestataire. Chaque nouvel include peut en cacher plusieurs ; son arbre se regarde avant publication, pas après.
• Préférer les sous-domaines dès le départ pour les flux volumineux (marketing, notifications). C'est un budget de dix résolutions par flux, et plus jamais de démêlage en urgence.
• Auditer le 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. C'est un actif à entretenir, pas 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 les factures tombent soudain en indésirable.

Thomas surveille le SPF

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

Analyser un domaine gratuitement ou créer un compte pour garder un SPF sous contrôle.