Aplatissement SPF : corriger la limite de 10 requêtes

La limite de 10 requêtes expliquée

SPF (Sender Policy Framework) échoue avec un permerror lorsqu’un serveur de messagerie destinataire doit effectuer plus de 10 requêtes DNS pour résoudre votre enregistrement SPF. Cela vient des instructions include imbriquées : si votre enregistrement inclut un fournisseur, et que ce fournisseur inclut un autre service, chaque étape compte dans la limite. Pour y remédier, vous devez recourir à l’aplatissement SPF (SPF flattening), qui remplace ces requêtes récursives par une liste statique d’adresses IP.

En tant qu’ingénieur chargé de la délivrabilité, j’ai surtout vu ce problème apparaître avec la « prolifération des fournisseurs ». Une entreprise démarre avec un fournisseur transactionnel, ajoute un outil marketing, puis un CRM, et son enregistrement SPF devient soudain un château de cartes. Lorsque la 11e requête est déclenchée, le serveur de réception arrête sa recherche et renvoie une erreur permanente. Votre e-mail n’est alors pas seulement classé en spam : il peut être rejeté purement et simplement, parce que le contrôle d’authentification a échoué sur le fond.

Comment fonctionne la limite de requêtes

Selon la RFC 7208, cette limite existe pour empêcher les attaques par déni de service (DoS) contre l’infrastructure DNS. Sans limite, un acteur malveillant pourrait créer une référence circulaire ou une énorme chaîne d’include obligeant le serveur de réception à effectuer des centaines de requêtes pour un seul e-mail.

Qu’est-ce qui compte comme une requête ?

Tous les mécanismes de votre enregistrement SPF ne sont pas gratuits. Les suivants déclenchent une requête DNS :

• include : le coupable le plus fréquent. Il demande au serveur d’aller consulter l’enregistrement SPF d’un autre domaine.
• a : interroge l’enregistrement A du domaine.
• mx : interroge les enregistrements MX du domaine.
• ptr : interroge le DNS inverse (ce mécanisme est toutefois déprécié et à éviter).
• exists : interroge un domaine précis pour vérifier s’il existe.

Les mécanismes comme ip4 et ip6 sont gratuits, car l’adresse IP figure explicitement dans l’enregistrement.

Anatomie d’une chaîne de requêtes

Prenons cet enregistrement SPF hypothétique :

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendhq.cc ~all

En apparence, cela fait 3 requêtes. Mais si _spf.google.com contient trois autres instructions include et spf.protection.outlook.com en contient quatre, vous êtes déjà à 10 requêtes. Si l’enregistrement de SendHQ comportait lui aussi un include, vous atteindriez la limite. C’est ce qu’on appelle une « chaîne d’include ».

Identifier le permerror

Si vous ne savez pas si vous avez atteint la limite, vous pouvez utiliser le vérificateur DNS e-mail de SendHQ pour valider vos enregistrements. Dans un log brut ou un outil d’analyse d’en-têtes, vous verrez un résultat de ce type :

spf=permerror (too many DNS lookups)

C’est différent d’un softfail (~all) ou d’un fail (-all). Un permerror signifie que le contrôle SPF n’a pas pu aboutir. Dans ce cas, le destinataire ne peut pas vérifier si l’expéditeur est autorisé, ce qui conduit souvent à l’abandon de l’e-mail ou à son signalement par les filtres agressifs.

Qu’est-ce que l’aplatissement SPF ?

L’aplatissement SPF consiste à résoudre tous les mécanismes include, a et mx en une liste à plat d’adresses ip4 et ip6.

Exemple : avant et après

Avant (récursif) :

v=spf1 include:_spf.example.com include:_spf.vendor.com ~all

(Supposons que _spf.example.com se résout en 1.2.3.4 et _spf.vendor.com en 5.6.7.8)

Après (aplati) :

v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ~all

En convertissant l’enregistrement en liste d’IP, le nombre de requêtes passe de 2 (ou plus) à 0. Le serveur de réception voit immédiatement les IP et valide l’expéditeur sans autre requête DNS.

Les inconvénients de l’aplatissement

L’aplatissement est une solution efficace, mais il impose une charge de maintenance importante.

1. Le problème des IP obsolètes

Lorsque vous utilisez une instruction include, vous déléguez la gestion des adresses IP au fournisseur. Si Amazon SES ou SendGrid ajoute une nouvelle plage d’IP à son infrastructure, il met à jour son propre enregistrement SPF, et vos e-mails continuent de passer.

Si vous aplatissez ces enregistrements dans votre propre DNS, ces IP deviennent votre responsabilité. Si le fournisseur change une IP et que vous ne mettez pas à jour votre liste aplatie, vos e-mails échoueront à l’authentification SPF. C’est la principale raison pour laquelle l’aplatissement manuel est dangereux pour l’e-mail transactionnel à fort volume.

2. Limites de longueur des enregistrements

Les enregistrements DNS ont une longueur maximale. Une chaîne unique dans un enregistrement TXT est limitée à 255 caractères. Vous pouvez concaténer plusieurs chaînes, mais certains parseurs DNS anciens gèrent mal les enregistrements très longs. Si vous aplatissez trop de fournisseurs, votre enregistrement SPF risque de devenir trop volumineux pour être traité correctement.

Comment corriger les chaînes d’include

Si vous atteignez la limite de 10 requêtes, suivez cette hiérarchie de solutions, de la plus sûre à la plus radicale.

Étape 1 : auditer et élaguer

Recherchez dans votre enregistrement les fournisseurs obsolètes. Beaucoup d’équipes conservent des instructions include pour des services qu’elles n’utilisent plus depuis trois ans. Retirez tout fournisseur qui n’envoie plus d’e-mails en votre nom.

Étape 2 : utiliser des sous-domaines selon le type de trafic

C’est la correction architecturale la plus professionnelle. Au lieu de placer chaque service sur votre domaine racine, séparez-les par fonction :

• Domaine racine (example.com) : e-mail d’entreprise (Google Workspace/Outlook).
• Sous-domaine transactionnel (mail.example.com) : SendHQ ou Amazon SES.
• Sous-domaine marketing (news.example.com) : Mailchimp ou Klaviyo.

Chaque sous-domaine a son propre enregistrement SPF et sa propre limite de 10 requêtes. Le risque est ainsi isolé, et la chaîne SPF complexe d’un outil marketing ne peut pas casser vos e-mails transactionnels critiques.

Étape 3 : aplatissement SPF dynamique

L’aplatissement dynamique est un service qui surveille en temps réel les chaînes include de vos fournisseurs et met automatiquement à jour votre enregistrement DNS avec les adresses IP actuelles. Il résout le problème des « IP obsolètes » en automatisant la mise à jour via une API.

SPF dans le contexte de la livraison moderne

Il est important de comprendre que SPF n’est qu’une pièce du puzzle de l’authentification. Pour que vos e-mails soient acceptés par le serveur de réception, vous devez coordonner SPF avec DKIM et DMARC. Vous trouverez une analyse détaillée de ces relations dans le guide SendHQ sur DKIM, SPF et DMARC.

Acceptation, livraison et placement

En tant qu’ingénieur, je distingue ces trois étapes :

1. Acceptation : le serveur de réception accepte la connexion et le message. Un permerror SPF peut amener un serveur à rejeter le message au niveau SMTP, auquel cas il n’est jamais accepté.
2. Livraison : le message est accepté et déposé dans la boîte aux lettres de l’utilisateur (ou dans un dossier).
3. Placement en boîte de réception : le message arrive dans la boîte de réception principale plutôt que dans le dossier spam.

L’aplatissement SPF corrige un problème d’acceptation. Il ne garantit pas le placement en boîte de réception, qui dépend de la réputation d’expéditeur, du contenu et des indicateurs d’engagement.

Points d’attention pour les agents IA

Avec l’essor des agents IA qui envoient des e-mails via des API, le risque de problèmes SPF augmente, car les agents peuvent déclencher de gros volumes d’e-mails sur plusieurs domaines. Lorsque vous construisez des workflows agentiques, traitez l’envoi d’e-mails comme un effet de bord externe.

Idempotence et validation

Les agents ne doivent jamais envoyer d’e-mails en boucle sans mécanisme de sécurité. Utilisez une clé d’idempotence pour que la logique de nouvelles tentatives de votre agent n’envoie pas dix fois le même e-mail transactionnel à un client. De plus, pour les e-mails à fort enjeu, ajoutez une étape de validation humaine avant l’appel API.

Analyse des coûts des fournisseurs d’envoi

Lorsque vous choisissez un fournisseur à inclure dans votre enregistrement SPF, tenez compte du coût du volume que vous envoyez. D’après les tarifs de septembre 2026 :

• Amazon SES : 0.10 USD pour 1 000 e-mails à la carte (tarifs Amazon SES). Pour 50 000 e-mails, cela représente environ 5 USD. Les nouvelles formules par paliers introduites le 21 juillet 2026 comprennent Essentials (0.16 USD pour 1 000), Pro (0.22 USD pour 1 000 plus 105 USD/mois/région) et Enterprise (0.23 USD pour 1 000 plus 500 USD/mois).
• Postmark : 15 USD par mois pour 10 000 e-mails, avec des dépassements entre 1.80 et 1.20 USD pour 1 000 (tarifs Postmark). 50 000 e-mails avec les paliers de Postmark coûtent environ 66 USD.
• Resend : l’offre gratuite comprend 3 000 e-mails par mois (plafonnés à 100/jour). Pro coûte 20 USD par mois pour 50 000 e-mails, avec des dépassements à 0.90 USD pour 1 000 (tarifs Resend).
• Mailgun : 15 USD par mois pour 10 000 e-mails, avec des dépassements de 1.80 à 1.10 USD pour 1 000 (tarifs Mailgun).
• SendGrid : l’offre gratuite est désormais un essai de 60 jours, et Essentials démarre à 19.95 USD par mois (tarifs SendGrid).

Checklist de dépannage SPF

Si vous soupçonnez un problème de limite de requêtes, suivez cette checklist :

• Exécutez une vérification DNS sur le domaine racine et tous les sous-domaines d’envoi.
• Comptez le nombre total de mécanismes include, a, mx et exists.
• Suivez les chaînes d’include de chaque fournisseur pour voir si elles contiennent des requêtes imbriquées.
• Identifiez et supprimez les fournisseurs inutilisés.
• Évaluez si le trafic peut être déplacé vers un sous-domaine dédié (par exemple, notifications.example.com).
• Si la limite est toujours dépassée, implémentez un aplatissement SPF dynamique.
• Vérifiez que l’enregistrement final ne dépasse pas la limite de 255 caractères par chaîne.

Tableau récapitulatif : mécanismes SPF

Mécanisme | Requête DNS ? | Risque | Recommandation

ip4 / ip6 | Non | Faible | À utiliser pour les IP statiques

include | Oui | Élevé | Avec parcimonie, surveiller les chaînes

a | Oui | Moyen | À éviter si possible, utiliser ip4

mx | Oui | Moyen | À éviter si possible

ptr | Oui | Élevé | Ne pas utiliser (déprécié)

En gérant vos enregistrements SPF de manière proactive, vous évitez le permerror qui ruine la délivrabilité avant même que votre e-mail n’atteigne le filtre anti-spam. Que vous utilisiez une simple API ou un système agentique complexe, garder un DNS épuré est le meilleur moyen de faire accepter vos e-mails transactionnels.

Pour un ensemble complet d’outils de gestion de l’authentification de votre domaine, rendez-vous sur https://sendhq.cc.