La RFC 7208 limite à 10 le nombre de lookups DNS qu'un enregistrement SPF peut déclencher lors de sa vérification. Au-delà, le résultat est permerror et l'ensemble du SPF est considéré comme invalide — même s'il est par ailleurs correctement écrit. C'est une des pannes de délivrabilité les plus fréquentes, et l'une des plus difficiles à repérer sans outil dédié, car l'enregistrement DNS lui-même reste syntaxiquement valide.

Qu'est-ce qui compte comme un lookup DNS

Chaque mécanisme suivant déclenche un lookup DNS lors de l'évaluation SPF, un par occurrence :

Les mécanismes ip4: et ip6: ne comptent pas comme des lookups DNS : ce sont des adresses littérales, pas des résolutions.

Le piège des includes imbriqués

Le calcul ne s'arrête pas à votre propre enregistrement. Si vous incluez _spf.google.com, et que cet enregistrement inclut lui-même d'autres domaines, chacun de ces includes imbriqués compte aussi dans votre total de 10. Un enregistrement qui semble court en apparence (3-4 includes) peut facilement dépasser la limite si l'un des domaines inclus est lui-même complexe.

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org include:spf.protection.outlook.com ~all

Cet exemple à 4 includes peut sembler raisonnable, mais chaque service tiers peut ajouter 2 à 4 lookups supplémentaires via ses propres includes internes — le total réel dépasse souvent 10 avec seulement 3 ou 4 services combinés.

Comment vérifier votre total actuel

Le calcul manuel est fastidieux et sujet à erreur, puisqu'il demande de résoudre récursivement chaque include. Un vérificateur SPF automatisé fait ce calcul et affiche le nombre exact de lookups consommés, en plus de repérer les éventuelles boucles de résolution.

Comment rester sous la limite

Supprimez les expéditeurs inutilisés. Chaque service ajouté « au cas où » consomme un budget de lookups partagé et limité — retirez ceux qui ne sont plus utilisés depuis longtemps.

Préférez ip4:/ip6: quand c'est possible. Si un service tiers documente ses adresses IP fixes en plus de son mécanisme include:, utiliser les adresses IP directement ne consomme aucun lookup.

Évitez d'empiler les redirections en chaîne. redirect= remplace entièrement votre enregistrement par celui d'un autre domaine — utile dans certains cas de mutualisation, mais chaque redirection ajoute un lookup, et les chaînes de redirection restent soumises à la même limite de 10.

Consolidez, ne dupliquez pas. Un domaine ne doit avoir qu'un seul enregistrement v=spf1. Fusionnez toujours les nouveaux expéditeurs dans l'enregistrement existant plutôt que d'ajouter un second enregistrement, qui serait de toute façon considéré comme invalide.

Ce qui se passe si vous dépassez la limite

Le résultat SPF devient permerror. Selon la politique du serveur receveur, cela peut être traité de façon aussi stricte qu'un échec SPF direct — votre enregistrement, aussi bien intentionné soit-il, devient inefficace. Pire, ce type d'échec est silencieux : rien dans votre configuration ne signale visuellement le problème tant que vous ne testez pas explicitement le nombre de lookups consommés.