Defaults.Exposed › Rapports

Pourquoi mon SPF échoue-t-il ? Le problème des 10 lookups pour les expéditeurs UK et UE avec des outils SaaS (2026)

Publié 2026-07-09

Chiffres au 2026-06-29 · méthodologie v7. Données agrégées sur 261 millions de domaines évalués. Voir comment nous évaluons.

Quand SPF échoue pour une entreprise utilisant des outils SaaS au Royaume-Uni ou en Europe, la cause la plus probable est une règle RFC unique à laquelle vous n’avez jamais eu à réfléchir : au-delà de 10 requêtes DNS, SPF ne renvoie pas « fail » — il renvoie PermError, ce qui signifie que l’enregistrement est traité comme s’il n’existait pas. Au moins 797 263 domaines ont déjà franchi cette limite. 2 119 539 autres se trouvent exactement à 9–10 lookups — un nouvel outil suffit pour tomber du même précipice.

Pourquoi SPF se casse-t-il quand on ajoute un outil SaaS ?

SPF fonctionne en listant les serveurs de messagerie autorisés à envoyer au nom de votre domaine. Les entreprises modernes n’exploitent plus leurs propres serveurs mail — elles utilisent Google Workspace pour la messagerie interne, Mailchimp pour les campagnes, HubSpot pour les séquences commerciales, Pipedrive pour les actions CRM. Chaque plateforme vous remet une ligne include: à coller dans votre DNS.

Le problème : chaque include: est lui-même une requête DNS. Et chaque enregistrement à l’intérieur de cet include peut déclencher d’autres lookups de manière récursive. RFC 7208 §4.6.4 fixe un plafond strict à dix. Au-delà de dix, le serveur de messagerie destinataire arrête l’évaluation et renvoie PermError — et un PermError n’est pas un échec doux qui atterrit dans les spams. Cela signifie que votre enregistrement SPF est considéré comme absent. L’authentification de l’e-mail échoue au niveau SPF.

Vous ne verrez rien dans votre panneau DNS. Le compteur ne s’active que lors d’une évaluation en direct. Vous pouvez avoir trois lignes include: dans votre enregistrement visible et être tout de même à douze lookups de profondeur, parce que l’enregistrement SPF de chaque fournisseur contient ses propres sous-includes.

Combien de domaines ont déjà dépassé la limite ?

Au moins 797 263. C’est le décompte après avoir résolu chaque cible SPF include: référencée 100 fois ou plus — 10 842 cibles distinctes couvrant 95,2% de toutes les références include — et évalué la chaîne complète de chaque domaine. Le décompte de surface (en ne comptant que les lignes visibles dans un enregistrement) donne environ 7 958. Le chiffre évalué par chaîne est 100 fois plus élevé, parce que presque tout le problème est invisible à l’intérieur des cibles include.

La situation qui touche le plus les entreprises européennes :

Hébergeurs européens et défauts SPF insuffisants

Le prestataire d’hébergement de départ a son importance — certains définissent des paramètres SPF par défaut qui consomment déjà plusieurs des dix lookups avant même de connecter un seul outil SaaS.

Parmi les principaux hébergeurs utilisés par les domaines européens dans notre recensement :

IONOS se distingue négativement : seulement 1,0% des domaines hébergés chez IONOS ont un DMARC actif, ce qui signifie que l’immense majorité ne dispose d’aucune authentification d’expéditeur réelle. Les domaines OVH s’en sortent mieux sur le paramètre SPF strict (43,7%) mais tombent à 2,2% pour l’application DMARC — SPF seul, sans DMARC pour le relier à l’en-tête From:, ne protège que l’enveloppe, pas ce que le destinataire voit.

Microsoft 365 fait figure d’exception positive : 85,0% des domaines hébergés par Microsoft utilisent SPF strict, en grande partie parce que l’assistant de flux mail de Microsoft définit -all par défaut. Google Workspace définit ~all (softfail) par défaut, laissant 92% de ses domaines sans protection stricte.

Diagnostiquer votre échec SPF en moins de 60 secondes

La vérification la plus rapide est un outil gratuit qui évalue la chaîne complète de lookups — pas seulement l’enregistrement visible. Exécutez nslookup -type=TXT votredomaine.com en ligne de commande et comptez chaque include: visible. Consultez ensuite chacun de ces enregistrements et comptez les leurs. Si vous manquez de doigts avant de manquer d’includes, vous êtes dans la zone dangereuse.

Une approche plus fiable : vérifiez votre domaine ici — le scanner évalue la chaîne résolue complète, signale les PermError et vous montre quels mécanismes consomment votre budget de lookups.

Trois résultats de diagnostic possibles :

• PermError — vous dépassez déjà dix. Chaque e-mail envoyé échoue au contrôle SPF chez le destinataire.
• À 9–10 lookups — vous êtes au bord du précipice. La prochaine intégration SaaS vous fait basculer.
• Softfail (~all) au lieu de hardfail (-all) — vous êtes sous la limite, mais l’enregistrement est configuré trop permissivement pour offrir une vraie protection. Voir le rapport sur les mauvaises configurations SPF pour le panorama complet sur -all vs ~all.

Comment corriger SPF quand on utilise plusieurs outils SaaS

Trois approches, par ordre de pérennité :

1. Auditer et élaguer. Commencez par lister tous les include: de votre enregistrement actuel. Supprimez toute plateforme que vous n’utilisez plus — anciens ESP, outils CRM de contrats précédents, plateformes testées puis abandonnées. C’est gratuit et récupère souvent plusieurs lookups. Chaque include: supprimé peut éliminer 1 à 3 sous-lookups.

2. Aplatir votre enregistrement SPF. L’aplatissement SPF résout toutes les cibles include: en leurs plages IP sous-jacentes et les inscrit directement dans votre enregistrement sous forme de mécanismes ip4: et ip6:. Les mécanismes IP ne déclenchent pas de lookups, de sorte qu’un enregistrement aplati peut lister des dizaines de sources d’envoi tout en restant à zéro lookup. L’inconvénient : il faut ré-aplatir chaque fois qu’un fournisseur met à jour ses IP d’envoi, ce qui arrive sans préavis. La plupart des organisations font appel à un service d’aplatissement géré (PowerDMARC, EasyDMARC, Dmarcian, entre autres) ou mettent en place un workflow de surveillance.

3. Utiliser les macros SPF. Les macros RFC 7208 permettent de construire des enregistrements qui effectuent un seul lookup DNS par vérification et répondent dynamiquement, au lieu d’enchaîner les includes. Les macros nécessitent une compatibilité de l’hébergeur DNS et un certain effort d’implémentation, mais représentent la solution architecturalement propre pour les organisations ayant de nombreux expéditeurs SaaS.

Après avoir corrigé SPF, associez-le à l’application DMARC — SPF sans DMARC n’authentifie que l’expéditeur de l’enveloppe, pas l’adresse From: de l’en-tête que les destinataires voient.

Questions fréquemment posées

Pourquoi mon enregistrement SPF passe-t-il le test de mon outil DNS mais échoue-t-il dans les en-têtes d’e-mail ? La plupart des outils de lookup DNS ne comptent que les mécanismes visibles dans votre propre enregistrement, pas les sous-lookups que ces mécanismes déclenchent. Vous pouvez avoir deux lignes include: et être quand même au-dessus de la limite si l’enregistrement de chaque fournisseur en contient plusieurs autres. Seul un outil d’évaluation par chaîne (ou un serveur mail destinataire) compte la profondeur totale. Vérifiez votre domaine pour voir le décompte de chaîne réel.

Un échec SPF signifie-t-il que mes e-mails vont dans les spams ? Un PermError (trop de lookups) signifie que le volet SPF de l’authentification ne renvoie aucun résultat — effectivement absent. DMARC évalue à la fois SPF et DKIM ; si DKIM passe, DMARC peut tout de même réussir malgré le PermError SPF. Si aucun des deux ne passe, DMARC échoue, et le résultat dépend de votre politique DMARC. Avec p=none, l’e-mail est quand même distribué mais l’échec est consigné. Avec p=quarantine ou p=reject, l’e-mail est filtré ou rejeté. Corrigez SPF pour ne pas dépendre uniquement de DKIM.

Combien de lookups une pile SaaS typique consomme-t-elle ? L’enregistrement SPF au p99 de notre recensement se situe déjà à 9 lookups — juste à la limite — avant d’ajouter quoi que ce soit. Un enregistrement Google Workspace ajoute 3 à 4 lookups ; Mailchimp en ajoute 1 à 2 ; HubSpot en ajoute 1 à 3 selon sa configuration actuelle. Trois outils courants plus la configuration par défaut de votre hébergeur suffisent souvent à dépasser dix.

L’aplatissement SPF est-il sûr ? Oui, à condition de le maintenir à jour. L’aplatissement convertit les chaînes include: en plages IP statiques — si un fournisseur fait tourner ses IP d’envoi et que vous ne ré-aplatissez pas, vous commencerez à rejeter ses e-mails. La plupart des organisations utilisent un service d’aplatissement géré qui surveille les changements d’IP plutôt que de le faire manuellement.

Mon SPF est ainsi depuis des années — pourquoi échoue-t-il soudainement ? Parce que vos fournisseurs ont mis à jour leurs enregistrements SPF, pas le vôtre. Chaque fois qu’une plateforme SaaS ajoute une nouvelle plage d’IP d’envoi ou imbrique un autre include, le coût de votre chaîne augmente sans aucun changement de votre côté. La limite des 10 lookups est évaluée en direct à la réception des messages, de sorte qu’une modification d’un fournisseur un mardi matin peut briser votre SPF dès le mardi après-midi.

Corriger SPF améliore-t-il la délivrabilité des e-mails ? Cela supprime une source d’échec d’authentification, ce qui est un prérequis pour une distribution cohérente — d’autant plus que Google et Yahoo imposent désormais l’alignement DMARC pour les expéditeurs en masse. SPF seul ne suffit pas : associez-le à DKIM et à DMARC pour une authentification e-mail complète.

Vérifiez votre SPF gratuitement

Si vous n’êtes pas sûr que votre enregistrement SPF dépasse la limite de lookups — ou qu’il est configuré trop faiblement pour protéger votre domaine — lancez une vérification gratuite. Elle évalue la chaîne résolue complète et vous montre exactement où le budget est dépensé.

Vérifier votre domaine → · Corriger SPF → · Le rapport SPF PermError → · Rapport sur les mauvaises configurations SPF → · Le modèle de maturité d’adoption SPF → · Corriger DMARC → · Données agrégées uniquement. Données stockées et traitées en UE.