L'erreur SPF « too many DNS lookups » signifie que l'évaluation de votre enregistrement SPF dépasse la limite de 10 recherches DNS imposée par la RFC 7208. Le résultat devient alors un permerror : votre politique SPF ne peut plus être interprétée correctement par le serveur qui la vérifie.
Le piège est que le nombre de recherches DNS n'est pas simplement le nombre de include: visibles dans votre enregistrement. Un seul include: peut appeler un autre SPF qui en appelle plusieurs autres. C'est cette arborescence complète qu'il faut compter et corriger.
SPF « too many DNS lookups » : ce que signifie l'erreur
SPF indique quels serveurs sont autorisés à envoyer des emails pour un domaine. Lorsqu'un serveur destinataire reçoit un message, il lit l'enregistrement TXT SPF du domaine utilisé dans l'identité MAIL FROM, puis suit les mécanismes nécessaires pour savoir si l'adresse IP d'envoi est autorisée.
La RFC 7208, section 4.6.4, impose une limite globale de 10 termes provoquant des recherches DNS pendant cette évaluation. Si cette limite est dépassée, le résultat SPF doit être permerror.
Un SPF peut sembler court et pourtant dépasser la limite. Quatre ou cinq include: visibles peuvent suffire si les enregistrements appelés contiennent eux-mêmes plusieurs recherches DNS.
Un permerror n'est pas un simple avertissement de mise en forme. Cela signifie que la politique SPF publiée ne peut pas être évaluée normalement. Le traitement final du message dépend ensuite du serveur destinataire et des autres mécanismes d'authentification, notamment DKIM et DMARC.
Pour replacer SPF dans l'ensemble de l'authentification email, consultez notre guide complet SPF, DKIM et DMARC.
Quels mécanismes SPF comptent dans les 10 recherches DNS ?
Selon la RFC, les mécanismes include, a, mx, ptr et exists, ainsi que le modificateur redirect, consomment le budget de recherches DNS. En revanche, ip4, ip6 et all ne sont pas comptés dans cette limite.
| Élément SPF | Compte dans la limite ? | Point d'attention |
|---|---|---|
include: |
Oui | Les recherches imbriquées du SPF appelé s'ajoutent au total. |
a |
Oui | Déclenche une résolution DNS du nom concerné. |
mx |
Oui | Compte dans la limite globale et peut aussi provoquer des résolutions A ou AAAA supplémentaires. |
ptr |
Oui | Compte dans la limite, mais la RFC 7208 déconseille désormais de publier ce mécanisme. |
exists |
Oui | Utilise le DNS pendant l'évaluation. |
redirect= |
Oui | Le SPF redirigé doit aussi être pris en compte. |
ip4: / ip6: |
Non | Pas de recherche DNS pour une adresse ou plage directement déclarée. |
all |
Non | Termine généralement la politique SPF. |
Microsoft rappelle une nuance importante : le nombre de recherches DNS peut être différent du nombre de requêtes DNS, et avoir moins de 10 instructions include: ne garantit donc pas de rester sous la limite.
Cette ligne n'affiche que quatre include:. Pourtant, le décompte réel dépend de ce que chacun de ces domaines appelle à son tour. C'est pourquoi il faut examiner l'arborescence, pas simplement compter les mots include.
Comment diagnostiquer un SPF qui dépasse 10 recherches DNS
Récupérez l'enregistrement SPF publié
Interrogez le TXT de votre domaine et repérez la chaîne qui commence par v=spf1. Vérifiez d'abord qu'il n'existe qu'un seul enregistrement SPF pour le domaine concerné : plusieurs SPF distincts provoquent eux aussi un permerror.
Dépliez chaque include:
Utilisez par exemple Google Admin Toolbox Check MX. Google recommande cet outil pour contrôler le nombre de recherches et rappelle que les recherches imbriquées comptent elles aussi dans la limite de 10.
Associez chaque source à un service réellement utilisé
Pour chaque include:, identifiez le service qui envoie effectivement des messages avec votre domaine : Microsoft 365, Google Workspace, CRM, plateforme d'emailing, application métier, formulaire du site ou serveur SMTP. Une entrée dont personne ne connaît plus l'usage doit être investiguée avant d'être conservée.
Contrôlez après chaque modification
Ne remplacez pas plusieurs éléments d'un seul coup. Corrigez une source, republiez le TXT, attendez sa propagation selon votre TTL puis refaites le test. Cette méthode limite le risque de supprimer par erreur un expéditeur légitime.
Comment corriger l'erreur sans casser vos envois
La correction la plus sûre consiste à réduire les recherches inutiles avant de chercher à raccourcir artificiellement le SPF.
- Supprimez les services qui n'envoient plus. Google recommande d'enlever les
include:des tiers qui ne sont plus actifs et les mécanismes dupliqués. - Évitez les doublons. Deux mécanismes peuvent parfois autoriser la même infrastructure. Garder les deux consomme inutilement le budget DNS.
- Utilisez
ip4:ouip6:uniquement quand les adresses sont stables et officiellement documentées. Microsoft précise que cette méthode réduit les recherches, mais oblige à surveiller les changements d'adresses du fournisseur. - Séparez certains flux sur des sous-domaines. Un service marketing ou transactionnel peut utiliser son propre sous-domaine d'envoi et donc son propre SPF, au lieu d'empiler tous les prestataires sur le domaine principal.
- Ne faites pas de « flattening » manuel sans maintenance. Transformer des
include:en listes d'IP peut résoudre le compteur aujourd'hui mais devenir faux demain si le fournisseur modifie son infrastructure.
Après la modification, envoyez un message de test et vérifiez les résultats SPF, DKIM et DMARC dans les en-têtes. Un domaine peut être sous la limite des 10 recherches tout en ayant encore un problème d'alignement ou une source d'envoi oubliée.
Cas concret : un SPF devenu trop complexe au fil du temps
Voici un cas typique rencontré sur une messagerie professionnelle dont le domaine utilisait progressivement plusieurs services d'envoi. Au fil des années, des prestataires avaient été ajoutés au SPF sans que les anciens soient systématiquement retirés.
À première vue, l'enregistrement ne contenait que quatre include:. Pourtant, leur analyse complète faisait apparaître des appels SPF imbriqués : certains fournisseurs interrogeaient à leur tour plusieurs domaines. Le nombre total de recherches DNS dépassait alors la limite autorisée, avec pour conséquence un résultat SPF en permerror.
Le premier travail consiste à identifier à quoi correspond chaque include:. Dans cet exemple, l'un d'eux correspondait à un ancien service qui n'était plus utilisé. Sa suppression a permis de simplifier la politique SPF. Les autres sources d'envoi ont ensuite été contrôlées une par une afin de vérifier qu'elles étaient toujours nécessaires.
La leçon est simple : une erreur « too many DNS lookups » n'est pas forcément due à un SPF visuellement très long. Elle est souvent la conséquence de plusieurs années d'ajouts successifs et d'include: imbriqués. Avant toute optimisation plus complexe, commencez donc par faire l'inventaire des services qui envoient encore réellement des emails pour votre domaine.
Sources officielles vérifiées
Sources vérifiées le 14 septembre 2026.
- RFC 7208, section 4.6.4 : DNS Lookup Limits
- Google Workspace Admin Help : Troubleshoot SPF issues
- Microsoft Learn : configurer SPF et résoudre les recherches DNS excessives
- Yahoo Sender Hub : exigences d'authentification des expéditeurs
Questions fréquentes
Combien de recherches DNS un enregistrement SPF peut-il utiliser ?
La RFC 7208 fixe à 10 le nombre maximal de mécanismes et modificateurs SPF qui provoquent des recherches DNS pendant une évaluation. Au-delà, le résultat doit devenir permerror. Ce plafond concerne notamment include, a, mx, ptr, exists et redirect.
Un include: SPF compte-t-il toujours pour une seule recherche ?
Non. Le include: lui-même consomme une recherche, mais l'enregistrement SPF qu'il appelle peut contenir d'autres mécanismes provoquant leurs propres recherches. Les appels imbriqués s'ajoutent donc au total, ce qui explique pourquoi quelques include: visibles peuvent suffire à dépasser la limite.
Quels éléments SPF ne comptent pas dans la limite de 10 ?
Les mécanismes ip4, ip6 et all ne provoquent pas de recherche DNS pendant l'évaluation SPF et ne sont donc pas comptés dans cette limite. Les adresses IP peuvent aider à réduire les recherches, mais uniquement si elles sont stables, documentées et maintenues.
Faut-il aplatir son SPF pour supprimer l'erreur ?
Pas automatiquement. Remplacer des include: par des adresses IP peut réduire les recherches, mais ces IP peuvent changer. Commencez par supprimer les services inutilisés et les doublons. Si vous utilisez ensuite des ip4 ou ip6, prévoyez une surveillance des changements publiés par le fournisseur.
Peut-on publier plusieurs enregistrements SPF sur le même domaine ?
Non. Un domaine ou sous-domaine doit publier un seul enregistrement SPF commençant par v=spf1. Si plusieurs enregistrements SPF sont publiés pour le même nom, l'évaluation peut retourner permerror. Les différentes sources d'envoi doivent donc être regroupées dans une seule politique.
Pour vérifier que SPF reste cohérent avec les autres mécanismes d'authentification, consultez aussi notre guide complet SPF, DKIM et DMARC.
Une fois l'authentification de votre domaine vérifiée, vous pouvez tester AntiSpammeur pendant 14 jours sur votre propre messagerie. L'essai ne remplace pas la correction SPF : il vous permet d'évaluer le filtrage entrant sur votre domaine.
Tester mon domaine gratuitement