SPF "Too Many DNS Lookups" : le guide complet pour corriger la limite de 10 lookups
Par CaptainDNS
Publié le 3 mars 2026
- La RFC 7208 impose un maximum de 10 DNS lookups par évaluation SPF, au-delà, le résultat est
permerroret vos emails échouent - Les mécanismes
include,a,mx,redirectetexistscomptent chacun comme un lookup,ip4etip6ne comptent pas - Avec 3-4 providers email (Google Workspace, SendGrid, Mailchimp), vous atteignez facilement 9-12 lookups
- 5 méthodes pour corriger : supprimer les mécanismes inutiles, remplacer par des IP directes, SPF flattening, SPF macros, sous-domaines dédiés
- Il existe aussi une limite de 2 void lookups (mécanismes qui ne retournent aucun résultat) souvent ignorée
Votre enregistrement SPF contient une dizaine d'include: pour couvrir tous vos providers email. Un jour, vous ajoutez un nouveau service et vos emails commencent à être rejetés. Le diagnostic révèle un permerror : vous avez dépassé la limite de 10 DNS lookups imposée par la RFC 7208.
Ce problème touche la majorité des organisations qui utilisent plus de 3 providers email. Google Workspace seul consomme déjà 4 lookups. Ajoutez SendGrid, Mailchimp et un serveur MX dédié, et vous frôlez la limite avant même d'avoir configuré votre dernier outil marketing.
Ce guide explique exactement comment fonctionne la limite de 10 lookups, comment compter les vôtres, et détaille 5 méthodes concrètes pour corriger le problème, de la plus simple à la plus robuste.
Qu'est-ce que la limite de 10 DNS lookups SPF ?
Ce que dit la RFC 7208
La RFC 7208, section 4.6.4 impose une limite stricte : l'évaluation d'un enregistrement SPF ne doit pas générer plus de 10 requêtes DNS. Cette limite existe pour protéger les serveurs de réception contre les attaques par amplification DNS. Sans elle, un attaquant pourrait publier un SPF avec des centaines d'include: imbriqués et forcer les serveurs à effectuer des milliers de requêtes.
La limite s'applique de manière récursive : si votre SPF inclut _spf.google.com, et que ce dernier inclut lui-même 3 autres domaines, chaque inclusion compte dans le total de 10.
Quels mécanismes comptent comme un lookup ?
| Mécanisme | Compte comme lookup | Explication |
|---|---|---|
include: | Oui | Résolution du SPF du domaine cible |
a | Oui | Résolution de l'enregistrement A/AAAA |
mx | Oui | Résolution MX puis A/AAAA de chaque serveur MX |
redirect= | Oui | Résolution du SPF du domaine cible |
exists: | Oui | Vérification d'existence du domaine |
ip4: | Non | Adresse IP directe, pas de requête DNS |
ip6: | Non | Adresse IP directe, pas de requête DNS |
all | Non | Mécanisme terminal, pas de requête |
Le piège principal : le mécanisme mx peut consommer plusieurs lookups. Si votre domaine possède 3 serveurs MX, le mécanisme mx génère 1 lookup MX + 3 lookups A, soit 4 requêtes pour un seul mécanisme.
Comment compter les DNS lookups de votre enregistrement SPF ?
La méthode la plus fiable consiste à résoudre manuellement l'arbre SPF. Prenons un exemple concret avec captaindns.com :
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all
Comptage étape par étape :
| # | Mécanisme | Lookups générés |
|---|---|---|
| 1 | include:_spf.google.com | 1 |
| 2 | → include:_netblocks.google.com | 1 |
| 3 | → include:_netblocks2.google.com | 1 |
| 4 | → include:_netblocks3.google.com | 1 |
| 5 | include:sendgrid.net | 1 |
| 6 | include:servers.mcsv.net | 1 |
| 7 | mx (résolution MX de captaindns.com) | 1 |
| Total | 7 |
Avec 7 lookups, cet enregistrement laisse une marge de 3. L'ajout de HubSpot (1 lookup) et d'un second serveur MX (1 lookup) porterait le total à 9, encore dans la limite.
Plutôt que de compter manuellement, utilisez notre SPF Record Check qui affiche le décompte exact et signale tout dépassement.
Que se passe-t-il quand vous dépassez la limite ?
Quand l'évaluation SPF atteint le 11e lookup, le serveur de réception arrête immédiatement l'évaluation et retourne un résultat permerror. Les conséquences sont directes :
- Le SPF est considéré comme invalide : pas simplement échoué, mais structurellement cassé
- DMARC échoue en cascade : si votre politique DMARC repose sur SPF pour l'alignement, elle échoue aussi
- Les emails sont rejetés ou mis en spam : Gmail, Outlook et Yahoo appliquent strictement cette limite
- L'erreur est silencieuse : vos emails partent sans erreur côté envoi, seul le destinataire voit le rejet
Le problème est insidieux : tant que vous ne dépassez pas la limite, tout fonctionne. Le jour où vous ajoutez un include: de trop, tous vos emails sont potentiellement affectés, pas seulement ceux du nouveau provider.
5 méthodes pour corriger l'erreur "too many DNS lookups"
Méthode 1 : Supprimer les mécanismes inutiles
Commencez par identifier les include: qui ne correspondent plus à des services actifs. Un provider d'email transactionnel que vous avez cessé d'utiliser il y a 6 mois consomme toujours un ou plusieurs lookups.
# Avant : 11 lookups (trop)
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net include:spf.brevo.com mx ~all
# Après suppression de Brevo (inutilisé) : 9 lookups
v=spf1 include:_spf.google.com include:sendgrid.net include:servers.mcsv.net mx ~all
Vérifiez chaque include: : ce service envoie-t-il encore des emails pour captaindns.com ? Si la réponse est non, supprimez-le.
Méthode 2 : Remplacer include par ip4/ip6
Si un service utilise des adresses IP fixes et documentées, vous pouvez remplacer son include: par les adresses IP directes. Les mécanismes ip4: et ip6: ne comptent pas comme lookups.
# Avant : include du serveur mail (1 lookup)
v=spf1 include:mail.captaindns.com include:_spf.google.com ~all
# Après : remplacement par l'IP du serveur (0 lookup ajouté)
v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all
Attention : cette méthode ne convient que pour les serveurs dont vous contrôlez les IP. Ne remplacez jamais les include: de Google ou Microsoft par leurs IP, celles-ci changent régulièrement sans préavis.
Méthode 3 : SPF flattening (aplatissement)
Le SPF flattening résout automatiquement tous les include:, a, mx et redirect en adresses IP directes. Le résultat est un enregistrement SPF composé uniquement de ip4: et ip6:, qui ne génèrent aucun lookup.
Avantages :
- Résolution immédiate du problème de lookups
- Compatible avec tous les serveurs de réception
- Résultat vérifié et prêt à publier
Inconvénient :
- Les IP des providers changent, vous devez re-aplatir régulièrement (mensuel recommandé)
Méthode 4 : SPF macros
Les SPF macros (%{i}, %{d}, %{s}) permettent de construire des enregistrements dynamiques qui redirigent l'évaluation vers des sous-domaines spécifiques sans consommer de lookups supplémentaires. Cette approche avancée est détaillée dans un prochain article de cette série.
v=spf1 include:%{i}._spf.captaindns.com ~all
Le serveur de réception remplace %{i} par l'IP de l'expéditeur, ce qui cible un enregistrement SPF spécifique. Résultat : 1 seul lookup au lieu de plusieurs include:.
Méthode 5 : Sous-domaines dédiés
Au lieu de tout envoyer depuis le domaine principal, affectez un sous-domaine à chaque provider :
| Sous-domaine | Provider | SPF dédié |
|---|---|---|
captaindns.com | Google Workspace | include:_spf.google.com (4 lookups) |
news.captaindns.com | Mailchimp | include:servers.mcsv.net (1 lookup) |
transac.captaindns.com | SendGrid | include:sendgrid.net (1 lookup) |
Chaque sous-domaine a son propre enregistrement SPF avec un compteur de lookups indépendant. Créez les SPF de chaque sous-domaine avec notre SPF Generator.
Void lookups : la deuxième limite à connaître
La RFC 7208 définit une seconde limite souvent ignorée : le nombre maximum de void lookups est fixé à 2. Un void lookup se produit quand un mécanisme DNS ne retourne aucun résultat (réponse NXDOMAIN ou vide).
Exemples de void lookups :
- Un
include:domaine-inexistant.comqui retourne NXDOMAIN - Un
asur un domaine sans enregistrement A - Un
exists:qui ne correspond à aucune entrée
Au-delà de 2 void lookups, le résultat est également permerror. Vérifiez que tous vos include: pointent vers des domaines existants et correctement configurés.
Plan d'action recommandé
- Comptez vos lookups actuels : vérifiez le nombre exact de DNS lookups de votre SPF publié
- Identifiez les mécanismes inutiles : supprimez les
include:de providers que vous n'utilisez plus - Choisissez votre méthode de correction : flattening pour un résultat immédiat, sous-domaines pour une solution structurelle, macros pour une approche avancée
- Testez avant de publier : validez le nouvel enregistrement avant de modifier votre zone DNS
- Surveillez régulièrement : les SPF des providers changent, revérifiez tous les mois
FAQ
Qu'est-ce que la limite de 10 DNS lookups SPF ?
La RFC 7208 impose qu'un enregistrement SPF ne génère pas plus de 10 requêtes DNS lors de son évaluation. Chaque mécanisme include:, a, mx, redirect et exists compte comme un lookup. Les mécanismes ip4: et ip6: ne comptent pas car ils contiennent directement l'adresse IP sans nécessiter de résolution DNS.
Comment savoir combien de DNS lookups mon SPF utilise ?
Résolvez manuellement chaque mécanisme de votre SPF en comptant les include:, a, mx, redirect et exists, y compris ceux des sous-includes. Par exemple, include:_spf.google.com consomme à lui seul 4 lookups car Google imbrique 3 sous-includes. Un outil d'analyse SPF automatise ce comptage et affiche le total exact.
Que se passe-t-il si mon SPF dépasse 10 lookups ?
Le serveur de réception retourne un résultat permerror et considère votre SPF comme invalide. Vos emails risquent d'être rejetés ou classés en spam. Si DMARC est configuré, il échoue aussi en cascade car l'alignement SPF ne peut pas être vérifié.
Le mécanisme mx compte-t-il comme un seul lookup ?
Non. Le mécanisme mx génère d'abord un lookup MX pour obtenir la liste des serveurs mail, puis un lookup A/AAAA pour chaque serveur retourné. Un domaine avec 3 serveurs MX consomme potentiellement 4 lookups pour un seul mécanisme mx.
Qu'est-ce que le SPF flattening ?
Le SPF flattening consiste à remplacer tous les mécanismes qui génèrent des lookups (include:, a, mx, redirect) par les adresses IP directes qu'ils résolvent (ip4:, ip6:). Le résultat est un SPF équivalent qui ne consomme aucun lookup DNS.
Qu'est-ce qu'un void lookup ?
Un void lookup se produit quand un mécanisme DNS retourne une réponse vide (NXDOMAIN ou aucun enregistrement). La RFC 7208 limite les void lookups à 2. Au-delà, le résultat est permerror, même si le total de lookups reste sous 10.
Faut-il utiliser le flattening ou les sous-domaines ?
Le flattening est la solution la plus rapide mais nécessite une maintenance mensuelle car les IP des providers changent. Les sous-domaines offrent une solution structurelle durable qui isole chaque provider avec son propre compteur de lookups. Pour les organisations avec plus de 5 providers, les sous-domaines sont recommandés.
Glossaire
- DNS lookup : requête DNS effectuée lors de l'évaluation d'un enregistrement SPF pour résoudre un mécanisme comme
include:oumx. - Permerror : erreur permanente retournée quand un SPF est structurellement invalide, notamment quand il dépasse la limite de 10 lookups.
- SPF flattening : technique qui remplace les mécanismes SPF nécessitant des lookups par les adresses IP directes qu'ils résolvent.
- Void lookup : requête DNS qui ne retourne aucun résultat (NXDOMAIN ou réponse vide). Limité à 2 par la RFC 7208.
- RFC 7208 : spécification officielle du protocole SPF (Sender Policy Framework) qui définit les règles d'évaluation et les limites de lookups.
Aplatissez votre enregistrement SPF maintenant : utilisez notre SPF Flattener pour résoudre tous vos includes en adresses IP directes et respecter la limite de 10 lookups.
📚 Guides SPF connexes
- SPF Flattening vs SPF Macros : quelle approche choisir pour respecter la limite de 10 lookups ?
- SPF PermError : comprendre, diagnostiquer et corriger (à venir)
