SPF en pratique : comment dépasser la limite des 10 recherches

À retenir

Le problème : SPF impose une limite stricte de 10 recherches DNS. Si vous la dépassez, même des emails légitimes échouent à l’authentification.

Pourquoi : Chaque service d’email (Google, Microsoft, Salesforce, etc.) ajoute des recherches. Les entreprises modernes atteignent rapidement la limite.

Solutions inefficaces :

• Flattening (listes d’IP en dur) – casse dès qu’un fournisseur change d’adresse IP
• Plusieurs enregistrements SPF – viole les standards
• Ignorer le problème – provoque des échecs de délivrabilité

La vraie solution : Dynamic SPF surveille automatiquement les changements d’IP des fournisseurs et vous permet de rester sous la barre des 10 recherches sans intervention manuelle.

En bref : Les contournements classiques du SPF ne suffisent pas ; Dynamic SPF règle définitivement le problème de limite de recherche.

Le SPF paraît simple… jusqu’à ce que les choses se compliquent. Le protocole limite les évaluations DNS à 10 recherches par vérification. Si vous atteignez ce plafond (souvent à cause des chaînes d’include: imbriquées de plusieurs plateformes SaaS), les destinataires arrêtent l’évaluation et renvoient un échec SPF permanent. Cela entraîne des échecs intermittents, casse l’alignement DMARC, et dégrade la délivrabilité.

Testez vos DNS dès maintenant grâce au SPF checker gratuit de Red Sift.SPF checker gratuit de Red Sift.

Les infrastructures modernes évoluent par couches successives : automation marketing, notifications produit, support, facturation, relais régionaux… À chaque fois, cela ajoute des includes SPF. Après quelques acquisitions, vous avez dépassé la limite sans vous en rendre compte. Résultat : des messages qui échouent "parfois" sans raison claire – un cauchemar à diagnostiquer.

Chaque mécanisme dans votre enregistrement SPF ne consomme pas forcément une recherche, ce qui explique pourquoi la limite prend souvent les utilisateurs au dépourvu. Voici ce qui compte :

• Pris en compte dans les 10 : include, a, mx, ptr, exists, et le modificateur redirect
• Non comptabilisé : ip4, ip6, et all, car ces éléments sont lus directement sans requête DNS

Surveillez particulièrement mx et ptr. Chacun peut coûter plus d’une recherche, car le récepteur résout tous les enregistrements retournés, pas seulement le premier. Remplacer une chaîne d’include lourde par des plages ip4 publiées permet de regagner rapidement de la marge, mais cela casse dès qu’un fournisseur change ses IPs. Dynamic SPF efface ce compromis.

1. Réduire la profondeur. Remplacez les includes imbriqués (fournisseur de fournisseur) par des blocs d’adresses ou sous-includes dédiés, si vos prestataires le permettent.
2. Privilégier DKIM pour l’alignement. L’alignement DKIM satisfait DMARC même si le SPF échoue à cause d’un transfert.
3. Regrouper les expéditeurs. Supprimez les services inactifs ; regroupez les systèmes peu utilisés derrière un seul relais.
4. Échelonner les changements de politique. Publiez DMARC en p=none, corrigez l’alignement, surveillez, puis resserrez à quarantine ou reject.

En bonus : Dépassez la limite des 10 recherches grâce à Red Sift OnDMARC. Dynamic SPF apporte une solution durable en consolidant les enregistrements et en supprimant le besoin de macros.

À noter : Tous les expéditeurs n’ont pas besoin d’un include SPF. Vérifiez que le return-path est bien dans votre domaine racine avant d’ajouter ce mécanisme, car le SPF s’applique sur le return-path. Si l’expéditeur utilise un sous-domaine ou un autre domaine, ajouter le mécanisme sur votre domaine racine est inutile.

• Les rapports DMARC révèlent quelles IPs/services échouent, pour nettoyer sans risque.
• Faites des tests en direct avant et après toute modification DNS, afin d’éviter de mauvaises surprises lors de la propagation.

Red Sift OnDMARC intègre la technologie Dynamic SPF qui élimine la limite de 10 recherches DNS, tout en préservant la délivrabilité et la sécurité des emails.[1]

Au lieu d’utiliser les enregistrements SPF usuels qui pointent vers des domaines tiers (et consomment autant de recherches), Dynamic SPF maintient un enregistrement unique, aplati, mis à jour en temps réel par Red Sift. La plateforme surveille en continu tous vos services email autorisés pour les changements d’IP, et met à jour instantanément le SPF si un fournisseur modifie son infrastructure.

1. Surveillance automatisée : Red Sift suit en temps réel les IPs de tous vos services d’envoi (Google Workspace, Microsoft 365, Salesforce, HubSpot, etc.).
2. Aplatissement intelligent : la plateforme convertit les includes SPF en IPs, réduisant drastiquement le nombre de recherches tout en assurant une couverture complète.
3. Mises à jour proactives : si un fournisseur change ses IPs d’envoi, Red Sift le détecte immédiatement et actualise votre SPF automatiquement, souvent en quelques minutes.
4. Zéro intervention manuelle : contrairement à l’aplatissement SPF classique, qui requiert surveillance et mises à jour constantes, Dynamic SPF gère tout automatiquement.

Les organisations peuvent ajouter autant de services email que nécessaire sans craindre la barrière des 10 recherches. Dynamic SPF actualise un enregistrement SPF unique, optimisé, sous le seuil réglementaire, et garantit le passage des emails légitimes. Plus besoin de choisir entre vos services ou de prendre le risque de casser le SPF en développant votre business.

Cette automatisation décharge les équipes IT et sécurité, qui n’ont plus à surveiller manuellement les changements d’IP fournisseurs ou à maintenir une configuration SPF complexe.

• Utilisez Red Sift Investigate pour valider rapidement SPF/DMARC sur plusieurs domaines.
• Passez à OnDMARC pour automatiser la découverte des expéditeurs et garder des enregistrements SPF efficaces au fur et à mesure que vos équipes ajoutent des outils. Résultat : alignement stable, moins de faux positifs, délivrabilité sécurisée.