Résoudre la limite des 10 recherches SPF : Guide technique pour MSP

Résumé exécutif L’enregistrement SPF de chaque domaine est plafonné à 10 recherches DNS — une contrainte fixée en 2006 qui n’est plus adaptée à l’environnement SaaS moderne. Pour les MSP qui gèrent des dizaines de domaines clients, chacun utilisant différents outils d’email, marketing, facturation et support, dépasser cette limite devient quasiment inévitable. Lorsque cela se produit, les emails légitimes échouent silencieusement à l’authentification, l’alignement DMARC est rompu et les tickets d’assistance s’accumulent. Ce guide explique le fonctionnement de la limite, comment auditer les domaines clients à grande échelle, pourquoi les solutions traditionnelles comme le flattening et la délégation de sous-domaines sont insuffisantes, et comment le Dynamic SPF élimine entièrement la contrainte — transformant la gestion SPF d’une urgence réactive à un service automatisé et évolutif.

Points clés à retenir

• Chaque mécanisme SPF include, a, mx, redirect, exists et ptr compte pour le plafond de 10 recherches — et les inclusions imbriquées dans les enregistrements tiers consomment des recherches cachées qui passent facilement inaperçues lors d’un contrôle manuel.
• Un client de taille intermédiaire utilisant sept outils SaaS ou plus est souvent déjà à la limite ou proche du seuil, ce qui fait qu'ajouter un nouveau service peut provoquer un PermError et casser la délivrabilité sans avertissement préalable.
• Google et Microsoft appliquent désormais explicitement la conformité SPF pour les expéditeurs à gros volumes, faisant de la limite une exigence de délivrabilité, non plus une simple recommandation de bonnes pratiques.
• Le flattening SPF devient un point faible en maintenance, car les fournisseurs cloud renouvellent fréquemment les adresses IP d’envoi — rendant les enregistrements aplatis rapidement obsolètes dans un portefeuille.
• Le Dynamic SPF regroupe tous les expéditeurs autorisés dans une inclusion unique et auto-actualisée qui reste sous le seuil, quel que soit le nombre de services utilisés par le client.
• Les MSP doivent auditer chaque domaine client lors de l’onboarding, signaler toute configuration à 8 recherches et plus comme à risque, et traiter la résolution SPF comme une étape clé pour passer du DMARC en surveillance à une application totale.

Un client ajoute HubSpot à son stack marketing. Une semaine plus tard, les factures de son CFO tombent en spam. Un ticket d’assistance apparaît, et la cause racine est oubliée des checklists d’onboarding : l’enregistrement SPF du client vient de dépasser sa dixième recherche DNS, déclenchant un échec d’authentification irréversible que même une analyse poussée ne pourra résoudre. Pour des MSP gérant de multiples domaines clients, tous avec leur panaché de services email, CRM et support, ce scénario devient de plus en plus courant. 

Des plateformes comme Red Sift OnDMARC règlent ce problème via le Dynamic SPF, supprimant entièrement la contrainte de la limite. Mais comprendre pourquoi la limite existe, comment elle cède et ce que les solutions traditionnelles font de travers, est un savoir clé pour tout MSP bâtissant une expertise DMARC.

Ce guide explique la limite des 10 recherches SPF de façon pratique, présente les contournements classiques et leurs limites, et expose les approches automatisées permettant aux MSP de gérer l’authentification email à grande échelle, sans buter contre ce plafond.

• Que signifie réellement la limite des 10 recherches SPF ?
• Pourquoi les MSP atteignent-ils la limite plus souvent que les autres ?
• Comment auditer l’enregistrement SPF d’un client
• Contournements classiques et leurs échecs
• Dynamic SPF : la solution automatisée
• Construire un workflow de gestion SPF pour votre MSP
• FAQ

SPF (Sender Policy Framework) permet aux propriétaires de domaines de déclarer quels serveurs de messagerie sont autorisés à envoyer des emails en leur nom. Les serveurs destinataires consultent le record SPF du domaine émetteur et vérifient si l’adresse IP d’origine est permise. Le protocole fonctionne, mais impose une contrainte stricte définie par la RFC 7208 : une évaluation SPF ne doit jamais exiger plus de 10 mécanismes ou modificateurs générant des recherches DNS supplémentaires [1].

Cette limite existe pour protéger l’infrastructure DNS. Sans elle, un enregistrement SPF mal conçu (voire malveillant) pourrait déclencher une chaîne infinie de requêtes DNS, consommant les ressources de réception et créant un risque de déni de service. Ce plafonnement permet de garder l’évaluation prévisible et bornée.

Nuance importante : la limite compte le nombre de mécanismes qui nécessitent une recherche, et non le nombre total de requêtes DNS générées [2]. Un mécanisme mx compte pour une recherche, même si cela entraîne plusieurs requêtes supplémentaires pour résoudre les adresses des serveurs de messagerie. Cette distinction est essentielle à l’optimisation des enregistrements : remplacer un mécanisme mx par des entrées ip4 économise une recherche, quel que soit le nombre d’entrées MX du domaine.

Si un serveur destinataire dépasse le seuil de 10 recherches lors de l’évaluation, il retourne un PermError, soit un échec SPF permanent. La conséquence dépend de la politique du destinataire : certains rejettent le message, d’autres l’envoient en spam, ou le considèrent comme non authentifié. DMARC est alors rompu si SPF était l’unique mécanisme valide, ce qui peut entraîner un passage en quarantaine ou rejet par les politiques DMARC en aval.

La limite a été définie en 2006 et codifiée dans la RFC 7208 en 2014, à une époque où les organisations utilisaient un ou deux services d’envoi d’email. Aujourd’hui, le paysage SaaS est tout autre. Un client de taille moyenne doit souvent inclure dans son SPF :

• Plateforme email (Google Workspace ou Microsoft 365)
• Marketing automation (HubSpot, Marketo ou Mailchimp)
• CRM (Salesforce)
• Support desk (Zendesk ou Freshdesk)
• Facturation (QuickBooks, Xero)
• Ressources humaines (Greenhouse, BambooHR)
• Email transactionnel (SendGrid ou Amazon SES)

Chacun de ces services exige généralement sa propre inclusion dans l’enregistrement SPF du domaine. Sept services = sept recherches, sans même compter les mécanismes a ou mx du domaine. Ajoutez un outil de plus, et c’est le seuil dépassé.

Pour les MSP, le problème se multiplie car chaque domaine client possède sa propre version de cette difficulté. Un portefeuille de 30 clients, c’est 30 combinaisons SaaS, 30 SPF à surveiller et autant de points de rupture potentiels. Dès qu’une équipe IT ou marketing d’un client ajoute un nouveau service sans avertir le MSP, le SPF peut dépasser la limite sans bruit. Les mails échouent alors de manière intermittente (car PermError ne se déclenche que si l’évaluation arrive jusqu’à la 11e recherche, et tous les serveurs ne vont pas au bout de tous les mécanismes à chaque message) : le problème est donc dur à détecter et à reproduire.

Google exige maintenant la conformité SPF pour les organisations qui envoient plus de 5 000 emails par jour [3], et Microsoft a introduit des exigences similaires : il faut maintenir le SPF dans la limite des 10 recherches [4]. Pour les MSP, la conformité expéditeur massif n’est plus facultative pour tout client pratiquant l’emailing à grande échelle.

Avant de corriger le problème, il faut l’évaluer. Un audit systématique permet de mesurer le nombre de recherches générées par l’enregistrement SPF d’un client et d’identifier leur source.

Méthodologie d’audit, étape par étape :

1. Interroger l’enregistrement SPF à l’aide d’un outil comme Red Sift's SPF Checker ou via DNS en ligne de commande (dig TXT example.com) pour récupérer l’enregistrement brut
2. Cartographier la chaîne des include en dépliant chaque mécanisme include de manière récursive. Chaque include équivaut à une recherche, et le record inclus peut comporter d’autres inclusions imbriquées
3. Compter tous les mécanismes générant une recherche : include, a, mx, redirect, exists et ptr
4. Identifier les services inactifs en comparant les include SPF avec l’infrastructure d’envoi réelle du client. Certains services à l’arrêt consomment quand même des recherches
5. Consigner le nombre obtenu et signaler toute configuration à 8 recherches ou plus comme à risque (deux nouveaux services pourraient suffire à casser la configuration)
6. Surveiller la profondeur des inclusions car certains SPF tiers contiennent eux-mêmes plusieurs inclusions imbriquées. Un simple include:tiers.com peut ainsi, une fois déroulé, compter pour trois ou quatre recherches

Auditer un portefeuille clients dévoile l’ampleur du problème. La plupart des MSP constatent qu’une proportion notable de domaines client dépasse déjà la limite ou est à un service d’y arriver.

Face à la limite des 10 recherches, les MSP essaient généralement plusieurs solutions de contournement. Chacune a des limites majeures la rendant inadaptée à l’échelle en production.

Le flattening remplace les include par leurs adresses IP (ip4/ip6), réduisant le décompte de recherches à zéro pour chaque service. Cela fonctionne en théorie, mais échoue en pratique : les fournisseurs cloud changent souvent leurs plages d’IP, ce qui rend l’enregistrement aplati vite obsolète ; les emails légitimes finissent alors rejetés.

Le flattening manuel impose au MSP une veille continue sur tous les fournisseurs pour renouveler les DNS au moindre changement d’IP. Sur 30 domaines de clients, tous différents, cette maintenance est intenable. Un oubli et la délivrabilité est en panne sur tout ou partie du portefeuille.

Publier plusieurs enregistrements SPF (TXT) sur un même domaine enfreint la spécification [1]. Tout serveur rencontré doit retourner PermError — cette approche aggrave donc le problème au lieu de le résoudre.

Déplacer chaque service sur un sous-domaine (marketing.example.com, support.example.com) répartit les recherches SPF. Cela diminue la charge par sous-domaine, mais complexifie l’alignement DMARC, exige une configuration Return-Path rigoureuse, et crée une complexité qui ne passe pas à l’échelle pour un portefeuille clients.

Certains MSP constatent qu’une part des serveurs n’impose pas strictement la limite. Ils en déduisent que « ça marche », même au-delà du seuil. Mais le comportement varie selon les serveurs et peut changer sans préavis. Google et Microsoft rappellent explicitement la conformité SPF dans leurs critères expéditeurs en masse, cette stratégie expose donc à un risque croissant.

Le Dynamic SPF change complètement d’approche : au lieu de gérer péniblement la contrainte des 10 recherches, Dynamic SPF regroupe toutes les sources autorisées dans une inclusion unique, maintenue automatiquement et toujours conforme.

Comment ça fonctionne :

1. Veille continue : la plateforme surveille en temps réel toutes les plages IP des services autorisés (Google Workspace, Microsoft 365, Salesforce, HubSpot...)
2. Consolidation intelligente : les include par domaine sont résolus en IP et regroupés dans un seul enregistrement optimisé
3. Mises à jour automatiques : quand un fournisseur change d’infrastructure, le SPF dynamique s’auto-actualise en quelques minutes, sans intervention DNS manuelle
4. Inclusion unique : l’enregistrement SPF client ne référence qu’un Dynamic SPF, une seule recherche quel que soit le nombre de services configurés

Résultat : les MSP ajoutent de nouveaux services email à volonté pour un client sans se soucier du plafond. Quinze services = une seule recherche, comme si le domaine n'en avait que trois. La barrière technique qui freinait l’application DMARC disparaît.

Pour les MSP qui évaluent des plateformes DMARC, la gestion Dynamic SPF est désormais un critère essentiel. Les différences techniques SPF, DKIM et DMARC restent importantes mais l'enjeu pratique est de choisir une plateforme capable d’éliminer ce plafond, à grande échelle, sur des portefeuilles clients hétérogènes.

Corriger la limite SPF pour un domaine isolé est simple. À l’échelle d’un portefeuille, il faut une méthode reproductible.

Workflow MSP recommandé :

1. Audit du portefeuille : effectuer des contrôles SPF sur tous les clients à l’onboarding. Signaler toute configuration à 8 recherches ou plus comme à risque
2. Prioriser suivant l’impact : traiter d’abord les domaines déjà non conformes, puis ceux à risque. Les clients avec DMARC à p=quarantine ou p=reject sont prioritaires car l’échec SPF met directement en danger la délivrabilité
3. Déployer Dynamic SPF : migrer les clients vers une plateforme qui gère le Dynamic SPF. Le programme partenaires MSP Red Sift fournit une infrastructure multi-locataire conçue pour les MSP gérant beaucoup de domaines simultanément
4. Mettre en place un contrôle des changements : imposer que toute modification ou ajout de source email doive passer par le MSP. Cela empêche l’ajout sauvage de services SaaS qui auparavant aurait pu faire casser le SPF.
5. Surveiller en continu : utiliser des alertes automatiques pour détecter tout nouveau service, tout écart de configuration ou tout échec SPF sur le parc
6. Reporter aux clients : inclure des métriques de santé SPF dans les rapports réguliers : taux de succès d’authentification, évolution des expéditeurs et indicateurs d’utilisation des recherches montrent la valeur et la sécurité du service

Normaliser ce workflow MSP diminue radicalement le coût SPF par domaine. L’audit et la migration initiaux demandent un effort, mais la maintenance devient ensuite automatisée plutôt que réactive.

La gestion SPF s’intègre naturellement dans les packages DMARC à plusieurs niveaux. La limite 10 recherches est souvent le verrou technique qui bloque les clients en mode surveillance (p=none) plutôt qu’en application (p=reject). Résoudre la casse SPF sur l’ensemble du portefeuille débloque la voie à l’application totale, palier à plus forte valeur pour un service d’authentification email managé.

[1] Kitterman, S. « Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1. » IETF RFC 7208, 2014. https://datatracker.ietf.org/doc/html/rfc7208#section-4.6.4

[2] Mailhardener. « The SPF lookup limit explained. » Mailhardener Blog, 2024. https://www.mailhardener.com/blog/spf-lookup-limit-explained

[3] Google. « Email sender guidelines. » Google Workspace Admin Help, 2024. https://support.google.com/a/answer/81126

[4] Microsoft Defender for Office 365 Team. « Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders. » Microsoft Tech Community, 2025. https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730

Le serveur de messagerie du destinataire retourne PermError, un échec SPF permanent. Selon la politique de réception et la configuration DMARC du domaine, le message peut être rejeté, placé en spam ou considéré comme non authentifié. L’échec est intermittent car il ne survient que lorsque l’évaluation arrive jusqu’à la 11e recherche, ce qui dépend du message et du serveur.

Le flattening transforme les include en IP statiques, ce qui réduit le nombre de recherches mais crée un casse-tête de maintenance. Les fournisseurs cloud renouvellent souvent les IP d’envoi : l’enregistrement aplati devient obsolète et provoque des échecs d’authentification. Pour un domaine, cela reste gérable ; au niveau d’un portefeuille avec plusieurs fournisseurs, la gestion manuelle ne passe pas à l’échelle.

Le Dynamic SPF automatise la consolidation et la maintenance : la plateforme surveille continuellement les plages IP et met à jour automatiquement le SPF à chaque changement. Le flattening classique est un instantané qui nécessite des mises à jour manuelles, tandis que le Dynamic SPF garantit une exactitude continue en temps réel, sans intervention humaine.

Google exige la conformité SPF pour tout expéditeur dépassant 5 000 emails/jour [3]. Microsoft précise explicitement de respecter la limite 10 recherches dans leurs préconisations aux expéditeurs à gros volumes [4]. Les deux plateformes renforcent progressivement le filtrage pour les messages non conformes.

Commencez par les domaines déjà non conformes (PermError), puis ceux à 8-9 recherches (un nouvel ajout et tout casse). Dans chaque groupe, donnez priorité à ceux enforceant DMARC (p=quarantine ou p=reject) car l’échec SPF a un effet immédiat sur la délivrabilité.