Un enregistrement SPF (Sender Policy Framework) qui renvoie « too many DNS lookups » a dépassé le plafond de 10 requêtes fixé par la RFC 7208. Les serveurs de messagerie destinataires considèrent alors l'enregistrement entier comme invalide, et pas seulement la partie au-delà de la limite. La solution consiste à aplatir ou à regrouper vos mécanismes include: pour ramener le nombre total de requêtes sous 10, sans supprimer par mégarde une source d'envoi.
Pourquoi la limite de 10 requêtes DNS SPF existe
La RFC 7208 §4.6.4 plafonne l'évaluation SPF à 10 requêtes DNS par vérification, et tout enregistrement qui en nécessite davantage doit renvoyer une permerror. Il ne s'agit pas d'un simple avertissement : une permerror signifie que le système destinataire ne peut pas déterminer votre politique de manière fiable. Il se rabat donc sur ses règles locales, ce qui conduit souvent à classer le message en spam ou à le rejeter purement et simplement.
Les mécanismes et modificateurs comptabilisés dans le budget de 10 requêtes sont :
includeamxptrexistsredirect
Les mécanismes qui ne comptent pas, car ils se résolvent sans requête DNS :
ip4ip6all
Cette distinction est tout le principe de l'« aplatissement » (flattening) : remplacez les mécanismes nécessitant une requête par les plages IP vers lesquelles ils finissent par se résoudre, et le nombre de requêtes baisse sans modifier ce qui est réellement autorisé.
Pourquoi les enregistrements dépassent si facilement la limite
La plupart des domaines n'en arrivent pas là en ajoutant volontairement dix services d'envoi. Une poignée d'intégrations courantes suffit :
- Google Workspace ou Microsoft 365 pour la messagerie principale
- Un outil de helpdesk (Zendesk, Freshdesk) pour les réponses au support
- Une plateforme marketing (Mailchimp, HubSpot) pour les campagnes
- Un service d'envoi transactionnel (SendGrid, Mailgun, Postmark) pour les e-mails applicatifs
- Un CRM ou un outil de signature électronique qui envoie aussi en votre nom
Chacun est généralement ajouté via un seul include:, mais de nombreux grands fournisseurs imbriquent leurs propres includes sur plusieurs niveaux. Ajouter trois ou quatre services populaires peut à lui seul représenter 8 à 10 requêtes, surtout une fois comptabilisées les chaînes d'include imbriquées et les éventuels mécanismes mx ou a.
WarningUn enregistrement peut sembler correct dans un éditeur de texte et pourtant échouer en production, car le compte des 10 requêtes inclut chaque
includeimbriqué résolu de manière récursive, et pas seulement ceux visibles dans votre propre enregistrement TXT.
Il existe aussi une limite distincte de 2 requêtes vides (void lookups) : une requête vide est une requête qui renvoie NXDOMAIN ou aucune réponse. Des cibles include: obsolètes ou mal saisies, liées à un service que vous n'utilisez plus, peuvent déclencher cette limite même si votre nombre de requêtes visible semble inférieur à 10.
Comment vérifier le nombre de requêtes DNS de votre SPF
Commencez par récupérer l'enregistrement brut et parcourez chaque include: à la main, ou passez-le dans notre générateur SPF gratuit, qui valide un enregistrement et signale les mécanismes qui lui font dépasser la limite. Vous pouvez aussi inspecter le DNS sous-jacent avec notre outil de recherche DNS pour voir précisément vers quoi se résout chaque include: avant de décider quoi aplatir.
Un enregistrement en passe de poser problème ressemble souvent à ceci :
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net include:sendgrid.net include:mailgun.org include:helpscoutemail.com ~all
Six mécanismes include:, chacun pouvant en imbriquer d'autres : c'est une façon tout à fait réaliste de dépasser 10 requêtes avec seulement quelques services.
Aplatissement SPF : remplacer les includes par des plages IP
Aplatir consiste à résoudre chaque include: jusqu'aux plages ip4/ip6 vers lesquelles il pointe actuellement, puis à les inscrire en dur dans votre enregistrement avec des mécanismes ip4:/ip6: à la place de include:. Comme les mécanismes IP sont gratuits (ils ne comptent pas dans la limite), un enregistrement comportant une douzaine de plages IP peut rester largement sous les 10 requêtes.
v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.10 ip6:2001:db8::/32 include:_spf.google.com ~all
Cet exemple aplatit les expéditeurs de faible priorité en adresses IP et ne conserve en include: actif que le fournisseur dont les plages changent le plus (Google, ici). En effet, les fournisseurs font évoluer leurs plages d'envoi, et un enregistrement entièrement aplati exige une mise à jour manuelle à chaque changement.
TipAplatissez les fournisseurs qui modifient rarement leurs plages IP, et laissez en mécanismes
include:ceux qui les changent fréquemment (grands ESP, plateformes de messagerie cloud) : vous trouverez ainsi le bon équilibre entre nombre de requêtes et effort de maintenance.
Regrouper plutôt qu'aplatir
Si l'aplatissement vous semble trop fragile à maintenir pour votre équipe, commencez par regrouper :
- Supprimez les entrées
include:des services par lesquels vous n'envoyez plus. - Fusionnez les mécanismes en double : deux instructions
include:pointant vers le même fournisseur sous-jacent s'additionnent vite. - Vérifiez si un service propose un include SPF unique et plus restreint que celui par défaut, qui embarque une infrastructure sans rapport.
- Assurez-vous de ne pas avoir plus d'un enregistrement TXT SPF sur le domaine : la RFC 7208 §3.2 en exige exactement un, et en avoir deux provoque aussi une permerror, indépendamment du nombre de requêtes.
Un modificateur redirect peut remplacer un enregistrement entier par la politique d'un autre domaine, mais la RFC 7208 §6.1 précise qu'il ne doit apparaître que lorsqu'aucun autre mécanisme n'est présent dans cet enregistrement : mélanger redirect avec vos propres mécanismes include:/all donne une évaluation imprévisible.
Ce qui se passe si vous ignorez le problème
Une permerror n'est pas neutre : la plupart des destinataires appliquent leur politique locale par-dessus. Et comme l'alignement DMARC dépend de la réussite du SPF, un enregistrement SPF défaillant casse souvent aussi l'alignement DMARC, même lorsque DKIM est valide. Cette combinaison est une cause fréquente et discrète d'e-mails arrivant en spam ; si vous diagnostiquez plus largement votre délivrabilité, consultez pourquoi vos e-mails arrivent en spam pour une vue d'ensemble qui va au-delà du seul SPF.
Récapitulatif : ce qui compte dans la limite SPF
| Mécanisme/modificateur | Compte dans la limite de 10 requêtes ? |
|---|---|
include |
Oui |
a |
Oui |
mx |
Oui (10 premiers enregistrements MX utilisés au maximum) |
ptr |
Oui (obsolète, à éviter) |
exists |
Oui |
redirect |
Oui |
ip4 / ip6 |
Non |
all |
Non |
Une fois votre enregistrement corrigé, gardez-le à l'œil : la dérive SPF revient chaque fois qu'une équipe ajoute un nouvel outil d'envoi sans vérifier le budget existant. Si vous gérez le DNS auprès de plusieurs registrars et fournisseurs, nos outils de gestion DNS vous offrent un point unique pour consulter et modifier chaque enregistrement avant qu'il ne casse discrètement la distribution de vos e-mails.
Questions fréquentes
#Qu'est-ce qui compte exactement comme une requête DNS SPF ?
Chaque mécanisme include, a, mx, ptr, exists et redirect compte pour une requête, et les includes imbriqués à l'intérieur comptent aussi dans le même total. ip4, ip6 et all ne nécessitent pas de requête DNS : ils sont donc gratuits.
#Dépasser la limite de requêtes SPF bloque-t-il tous mes e-mails ?
Cela provoque une permerror, que la plupart des systèmes de messagerie destinataires traitent comme une vérification SPF échouée ou inexploitable plutôt que comme un résultat neutre. Les messages sont alors souvent rejetés ou envoyés en spam, et l'alignement DMARC sur SPF peut aussi être cassé.
#Puis-je simplement avoir deux enregistrements SPF pour y ajouter plus d'expéditeurs ?
Non : la RFC 7208 exige exactement un enregistrement TXT SPF par domaine, et en avoir plusieurs produit aussi une permerror, indépendamment du problème de nombre de requêtes.
#À quelle fréquence faut-il mettre à jour les plages IP aplaties ?
Cela dépend du fournisseur : certains modifient rarement leurs plages d'envoi tandis que d'autres les changent régulièrement. Les enregistrements aplatis doivent donc être revérifiés périodiquement par rapport aux plages actuellement publiées par le fournisseur, afin de ne pas perdre d'expéditeurs légitimes.
Essayez avec un outil gratuit
Cet article vous a-t-il été utile ?
