La plupart des organisations découvrent les limites des enregistrements SPF uniquement après une rupture d’authentification. À ce moment-là, les emails légitimes rebondissent déjà, atterrissent dans les spams ou échouent silencieusement sans erreurs visibles. La limite de 10 recherches DNS n’est pas une recommandation c’est une frontière technique stricte qui met fin à l’évaluation SPF et renvoie une erreur permanente, causant généralement un échec d’alignement DMARC même lorsque d’autres authentifications réussissent.

Soixante-trois pour cent des organisations utilisant trois plateformes email tierces ou plus dépassent la limite de recherche SPF dans les 18 mois suivant le déploiement initial, selon les données récentes de référence en matière d’authentification email. L’échec est structurel : chaque expéditeur autorisé ajouté au SPF via des mécanismes include: augmente le nombre de requêtes DNS, et la plupart des organisations atteignent la limite bien avant de réaliser qu’elles comptent mal les requêtes.

Cet article explique comment fonctionnent les limites de recherche SPF, ce qui se casse lorsque vous les dépassez, comment identifier l’échec avant qu’il n’impacte la délivrance, et comment restructurer le SPF pour rester dans les limites techniques tout en maintenant la couverture des fournisseurs.

I. Qu’est-ce que la limite de recherche SPF ?

Le SPF (Sender Policy Framework) valide que le serveur de messagerie émetteur est autorisé à envoyer des emails au nom d’un domaine. Le serveur récepteur effectue des recherches DNS pour résoudre l’enregistrement SPF et évaluer la chaîne d’autorisation. La RFC 7208 fixe une limite stricte de 10 recherches DNS par évaluation SPF pour prévenir les abus, les récursions infinies et les attaques par amplification DNS.

Lorsqu’une évaluation SPF dépasse 10 recherches DNS, le serveur récepteur arrête le traitement et renvoie permerror. Il s’agit d’un échec permanent, pas d’une condition temporaire. Le résultat est traité comme un échec SPF dans la plupart des implémentations, ce qui signifie :

• L’alignement DMARC échoue même si DKIM réussit, car le SPF n’a ni réussi ni été aligné.
• Les signaux de réputation se dégradent car les fournisseurs de messagerie voient une incohérence d’authentification.
• La délivrance devient imprévisible car certains serveurs récepteurs filtrent silencieusement, d’autres rejettent, et beaucoup ne révèlent pas l’échec dans les messages de rebond.

La limite est fixe. Elle ne s’ajuste pas à la taille du domaine, au volume d’emails ou à la complexité métier. Ajouter un expéditeur autorisé de plus lorsque vous êtes déjà à 10 recherches casse l’intégralité de l’enregistrement SPF.

II. Comment les recherches DNS sont comptées

Le comptage des recherches SPF est souvent mal compris car tous les mécanismes d’un enregistrement SPF ne déclenchent pas une recherche DNS. Les mécanismes suivants comptent dans la limite de 10 recherches :

• include: – Chaque mécanisme include: déclenche au moins une recherche, et si l’enregistrement inclus contient des mécanismes supplémentaires include:, a, mx ou ptr, ceux-ci comptent récursivement.
• a – Interroge l’enregistrement A du domaine.
• mx – Interroge l’enregistrement MX du domaine, et chaque cible MX nécessite une recherche d’enregistrement A supplémentaire.
• ptr – Interroge l’enregistrement PTR (déprécié et ne devrait pas être utilisé).
• redirect= – Déclenche une recherche, plus toutes les recherches dans l’enregistrement redirigé.
• exists: – Interroge l’enregistrement A du domaine spécifié.

Les mécanismes suivants ne comptent pas :

• ip4: – Adresse IP statique, aucune requête DNS nécessaire.
• ip6: – Adresse IPv6 statique, aucune requête DNS nécessaire.
• all – Mécanisme qui définit l’action par défaut, aucune requête DNS.

Exemple : Explosion cachée de recherches

Un enregistrement SPF apparemment simple peut rapidement dépasser la limite :

v=spf1 include:_spf.google.com include:sendgrid.net include:spf.protection.outlook.com include:mail.zendesk.com include:_spf.salesforce.com ~all

Nombre de recherches apparent : 5
Nombre de recherches réel : 12+

Voici pourquoi :

• include:_spf.google.com → 3 recherches (Google utilise des includes imbriqués)
• include:sendgrid.net → 2 recherches
• include:spf.protection.outlook.com → 2 recherches
• include:mail.zendesk.com → 2 recherches
• include:_spf.salesforce.com → 3 recherches

Total : 12 recherches. Cet enregistrement renverra permerror et échouera l’authentification SPF.

Les organisations supposent souvent que cinq instructions include: équivalent à cinq recherches. Ce n’est pas le cas. Chaque domaine inclus peut s’étendre en plusieurs recherches imbriquées, et celles-ci comptent dans le total.

III. Que se passe-t-il quand vous dépassez la limite

1. SPF renvoie permerror

Lorsque le serveur récepteur atteint la limite de 10 recherches, l’évaluation SPF s’arrête et renvoie permerror. Ceci est enregistré dans l’en-tête Authentication-Results comme :

spf=permerror (too many DNS lookups)

L’email ne bénéficie pas de l’authentification SPF. Si DKIM n’est pas présent ou ne s’aligne pas, DMARC échoue.

2. L’alignement DMARC échoue

DMARC nécessite que SPF ou DKIM réussisse et s’aligne avec le domaine From:. Si SPF renvoie permerror, il ne peut pas s’aligner. Si DKIM est manquant, non signé ou mal aligné, DMARC échoue entièrement.

À p=quarantine ou p=reject, cela signifie que l’email est filtré ou bloqué. À p=none, l’échec est invisible mais toujours enregistré dans les rapports agrégés, dégradant la réputation au fil du temps.

3. Filtrage silencieux

Tous les fournisseurs de messagerie ne rejettent pas les emails avec SPF permerror. Certains dégradent silencieusement la délivrance :

• L’email atterrit dans les spams au lieu de la boîte de réception.
• L’email est retardé ou ralenti.
• L’email est livré mais marqué comme potentiellement suspect dans le client de messagerie du destinataire.

Parce que l’échec est silencieux, les organisations ne réalisent souvent pas que SPF est cassé jusqu’à ce que les taux de plainte augmentent, que l’engagement chute ou qu’une campagne majeure échoue.

4. Impact spécifique aux fournisseurs

L’impact varie selon les fournisseurs :

• Gmail : Traite permerror comme un signal d’échec mais peut quand même livrer si DKIM réussit et que la réputation du domaine est forte. Cependant, le placement en boîte de réception se dégrade au fil du temps.
• Microsoft 365 : Traite permerror comme un échec SPF. Si DKIM ne s’aligne pas, l’email est filtré ou rejeté selon la politique et la réputation.
• Yahoo, AOL : Application stricte. permerror aboutit souvent à un rejet ou un filtrage spam.
• Listes de diffusion, redirecteurs : SPF se casse lors de la redirection car l’expéditeur d’enveloppe ne s’aligne pas. Si l’enregistrement SPF original est déjà en permerror, l’email redirigé n’a aucune couverture d’authentification.

5. Les rapports DMARC montrent l’échec

Si votre politique DMARC est définie sur p=none avec les rapports agrégés activés, vous verrez permerror dans le champ de résultat spf des rapports agrégés DMARC. Le rapport montre :

<auth_results>
  <spf>
    <domain>example.com</domain>
    <result>permerror</result>
  </spf>
</auth_results>

L’échec est enregistré, mais si vous n’examinez pas activement les rapports DMARC, vous ne le verrez pas. C’est pourquoi de nombreuses organisations dépassent la limite SPF sans s’en rendre compte jusqu’à ce que des problèmes de délivrance apparaissent.

IV. Comment identifier le nombre de recherches SPF avant qu’il ne casse

Comptage manuel des recherches SPF

Vous pouvez compter manuellement les recherches SPF en développant récursivement chaque mécanisme include: et en comptabilisant tous les mécanismes include:, a, mx, redirect= et exists: rencontrés.

Processus étape par étape :

1. Interrogez votre enregistrement SPF :

   dig TXT example.com

2. Pour chaque mécanisme include:, interrogez le domaine inclus :

   dig TXT _spf.google.com
   dig TXT sendgrid.net

3. Comptez tous les mécanismes qui déclenchent des recherches DNS dans l’enregistrement principal et tous les enregistrements imbriqués.

Ce processus est chronophage et sujet aux erreurs, surtout lorsque les fournisseurs modifient leurs enregistrements SPF sans préavis.

Validation automatisée des recherches SPF

Utilisez un vérificateur d’enregistrement SPF qui compte automatiquement les recherches DNS et identifie quels mécanismes contribuent au total. Des outils tels que :

• Skysnag Domain Checker – Scanne votre domaine, compte les recherches SPF et signale les enregistrements qui dépassent ou approchent la limite de 10 recherches.
• dig + récursion manuelle (technique mais exhaustive).
• Validateurs SPF tiers (précision variable ; certains ne comptent pas correctement les recherches imbriquées).

Skysnag Domain Checker affiche :

• Le nombre actuel de recherches
• Quels mécanismes include: se développent en plusieurs recherches
• Si l’enregistrement est déjà en permerror
• Recommandations pour l’aplatissement ou la restructuration

V. Comment corriger les problèmes de limite de recherche SPF

1. Remplacer include: par ip4: ou ip6: lorsque c’est possible

Si un expéditeur tiers fournit une plage IP statique, remplacez le mécanisme include: par des adresses IP explicites :

Avant :

v=spf1 include:mail.vendor.com ~all

Après :

v=spf1 ip4:203.0.113.0/24 ip4:198.51.100.5 ~all

Cela élimine les recherches DNS pour cet expéditeur. Cependant, cette approche ne fonctionne que si le fournisseur utilise des IP statiques et ne fait pas tourner l’infrastructure fréquemment. De nombreuses plateformes SaaS font tourner les IP, rendant les listes statiques impraticables.

2. Aplatir l’enregistrement SPF

L’aplatissement SPF résout tous les mécanismes include: en leurs adresses IP finales et les consolide en un seul enregistrement. Cela réduit les recherches DNS mais crée un risque opérationnel :

• Les changements d’IP des fournisseurs cassent l’authentification. Si un fournisseur ajoute ou fait tourner des adresses IP, votre enregistrement SPF aplati devient obsolète, et les emails légitimes échouent l’authentification.
• Mises à jour manuelles requises. Vous devez surveiller les enregistrements SPF des fournisseurs et mettre à jour votre enregistrement aplati chaque fois que des changements se produisent.
• Aucune notification quand les fournisseurs changent. La plupart des fournisseurs n’annoncent pas les changements d’enregistrements SPF, donc vous ne découvrez l’échec que lorsque les emails commencent à rebondir.

L’aplatissement fonctionne comme une solution à court terme mais nécessite une maintenance et une surveillance continues.

3. Utiliser des sous-domaines pour segmenter les expéditeurs

Déplacez des flux d’emails spécifiques vers des sous-domaines dédiés et créez des enregistrements SPF séparés pour chacun :

Exemple :

• example.com → Authentifié pour les emails professionnels principaux (Microsoft 365)
• marketing.example.com → Authentifié pour les plateformes marketing (SendGrid, Mailchimp)
• support.example.com → Authentifié pour les outils de support (Zendesk, Intercom)

Chaque sous-domaine a son propre enregistrement SPF, et chaque enregistrement reste sous la limite de 10 recherches. Cette approche fonctionne bien pour les organisations avec une segmentation claire des expéditeurs, mais elle nécessite :

• Le support de la plateforme email pour l’envoi depuis un sous-domaine (toutes les plateformes ne le supportent pas).
• La configuration DNS pour chaque sous-domaine.
• L’alignement de la politique DMARC entre les sous-domaines (si non configuré, DMARC peut échouer).

4. Supprimer les mécanismes include: inutilisés ou redondants

Beaucoup d’enregistrements SPF incluent des expéditeurs qui ne sont plus utilisés :

• Anciennes plateformes marketing
• Outils de support désactivés
• Déclarations include: en double (par exemple, deux entrées pour le même fournisseur)
• Fournisseurs qui ont été testés mais jamais déployés

Auditez votre enregistrement SPF et supprimez tous les mécanismes include: qui ne correspondent pas à des expéditeurs actifs. Utilisez Skysnag Protect pour identifier quels expéditeurs envoient activement des emails et quelles entrées include: sont inutilisées.

5. Consolider les fournisseurs lorsque c’est possible

Si vous utilisez plusieurs plateformes marketing, outils de support ou fournisseurs d’emails transactionnels, consolidez-les en moins de fournisseurs. Cela réduit le nombre de mécanismes include: et simplifie la gestion SPF.

Par exemple :

• Utilisez une seule plateforme d’emails transactionnels au lieu de trois.
• Consolidez les emails marketing via un seul ESP.
• Routez les emails de support via un seul système de tickets.

Il s’agit d’une décision métier, pas seulement d’une correction technique, mais c’est la façon la plus durable de réduire la complexité SPF.

VI. Limite de recherche SPF et application DMARC

Lorsque SPF dépasse la limite de recherche et renvoie permerror, l’évaluation DMARC dépend du fait que DKIM réussisse et s’aligne.

Scénario 1 : SPF permerror + DKIM réussit + DKIM s’aligne

DMARC réussit car DKIM fournit l’authentification et l’alignement requis. L’échec SPF ne bloque pas la délivrance, mais il affaiblit la posture globale d’authentification.

Scénario 2 : SPF permerror + DKIM échoue ou manquant

DMARC échoue. Si votre politique est définie sur p=quarantine ou p=reject, l’email est filtré ou refusé lors de la livraison SMTP lorsque le serveur récepteur honore la politique. Si votre politique est p=none, l’échec est enregistré mais ne déclenche pas l’application.

Scénario 3 : SPF permerror + DKIM réussit mais mal aligné

DMARC échoue. DKIM doit s’aligner avec le domaine From: (alignement strict ou relâché). Si DKIM réussit mais ne s’aligne pas, et que SPF est en permerror, DMARC n’a aucun chemin d’authentification valide.

Le mode d’échec le plus courant est le Scénario 2 SPF casse, DKIM n’est pas configuré pour l’expéditeur tiers, et DMARC échoue complètement.

VII. Comment surveiller le nombre de recherches SPF au fil du temps

Les enregistrements SPF changent lorsque vous ajoutez ou supprimez des expéditeurs autorisés. Surveiller le nombre de recherches prévient les échecs d’authentification avant qu’ils n’impactent la délivrance.

Utiliser Skysnag Protect pour la surveillance continue du SPF

Skysnag Protect surveille en continu votre enregistrement SPF et suit le nombre de recherches DNS. Lorsqu’un fournisseur met à jour son enregistrement SPF et que votre nombre total de recherches augmente, Skysnag vous alerte avant que la limite de 10 recherches ne soit dépassée.

Comment ça fonctionne :

1. Skysnag scanne votre enregistrement SPF quotidiennement.
2. Suit le nombre de recherches pour tous les mécanismes include:.
3. Vous alerte lorsque le nombre de recherches approche ou dépasse la limite.
4. Fournit des recommandations pour l’aplatissement, la segmentation par sous-domaine ou la consolidation IP.

Cela prévient le mode d’échec silencieux où SPF casse et vous ne le découvrez que lorsque la délivrabilité se dégrade.

Commencez à surveiller votre enregistrement SPF avec Skysnag Protect.

VIII. Alternatives au SPF : MTA-STS et authentification DKIM uniquement

Certaines organisations éliminent complètement SPF et s’appuient sur DKIM pour l’authentification. Cela évite la limite de recherche mais supprime le rôle de SPF dans la prévention de l’usurpation au niveau de l’enveloppe.

Authentification DKIM uniquement

DKIM authentifie le corps du message et les en-têtes à l’aide d’une signature cryptographique. Il ne valide pas l’expéditeur d’enveloppe (l’adresse utilisée pendant SMTP), donc il ne prévient pas certains types d’usurpation. Cependant, DKIM n’a pas de limite de recherche, ne casse pas lors de la redirection, et fournit des garanties cryptographiques plus fortes que SPF.

Si vous déployez une authentification DKIM uniquement :

• Assurez-vous que DKIM est configuré pour tous les expéditeurs autorisés.
• Utilisez DMARC avec aspf=r (alignement relâché) pour permettre la flexibilité des sous-domaines.
• Surveillez les rapports agrégés DMARC pour vérifier la couverture DKIM.

MTA-STS pour la sécurité du transport

MTA-STS (Mail Transfer Agent Strict Transport Security) impose une livraison chiffrée mais ne remplace pas SPF ou DKIM. Il garantit que l’email est livré via TLS, empêchant les attaques de type homme du milieu, mais il n’authentifie pas l’expéditeur.

MTA-STS fonctionne aux côtés de DMARC, pas comme un substitut.

IX. Erreurs courantes concernant la limite de recherche SPF

1. Supposer que les enregistrements SPF des fournisseurs ne changent jamais

Les fournisseurs mettent à jour leurs enregistrements SPF pour ajouter de l’infrastructure, faire tourner les IP ou changer d’hébergeur. Si vous aplatissez votre enregistrement SPF et ne surveillez pas les changements des fournisseurs, l’authentification casse silencieusement.

2. Compter les déclarations include: au lieu des recherches DNS

Un enregistrement SPF avec 5 mécanismes include: peut déclencher 12+ recherches DNS car chaque enregistrement inclus peut contenir des mécanismes supplémentaires include:, a ou mx imbriqués.

Comptez toujours le total des recherches DNS récursives, pas seulement les mécanismes de premier niveau.

3. Utiliser les mécanismes ptr

Le mécanisme ptr est déprécié et inefficace. Il déclenche des recherches DNS inverses et augmente le nombre de requêtes. N’utilisez pas ptr dans les enregistrements SPF modernes.

4. Ne pas tester les changements SPF avant publication

Publier un changement SPF sans test peut casser l’authentification pour tous les emails. Utilisez un domaine ou sous-domaine de test pour valider l’enregistrement avant de l’appliquer en production.

5. Ignorer les rapports agrégés DMARC

Les rapports DMARC montrent les échecs SPF permerror, mais de nombreuses organisations ne consultent pas régulièrement les rapports. Configurez une surveillance via Skysnag pour faire remonter les problèmes SPF avant qu’ils n’impactent la délivrance.

X. Points clés à retenir

Les limites de recherche SPF ne sont pas flexibles. La frontière de 10 recherches DNS est une contrainte technique fixe, et la dépasser renvoie permerror, ce qui casse l’authentification SPF et cause souvent un échec DMARC.

Les organisations utilisant plusieurs plateformes email tierces dépassent couramment la limite sans s’en rendre compte car les recherches DNS sont comptées récursivement, et les enregistrements SPF des fournisseurs changent sans préavis.

L’échec est souvent silencieux. L’email peut encore être livré, mais il atterrit dans les spams, est ralenti ou dégrade la réputation au fil du temps. Les rapports agrégés DMARC montrent le résultat permerror, mais si les rapports ne sont pas activement surveillés, l’échec passe inaperçu jusqu’à ce que des problèmes de délivrabilité apparaissent.

Pour rester dans la limite de recherche SPF :

• Remplacez les mécanismes include: par ip4: ou ip6: lorsque les fournisseurs utilisent des IP statiques.
• Segmentez les flux d’emails entre sous-domaines pour répartir le nombre de recherches.
• Supprimez les entrées include: inutilisées ou héritées.
• Consolidez les fournisseurs pour réduire la complexité SPF.
• Surveillez les enregistrements SPF en continu pour détecter les changements de fournisseurs.

Utilisez Skysnag Protect pour surveiller le nombre de recherches DNS, identifier quels expéditeurs contribuent à l’inflation des recherches, et recevoir des alertes avant que SPF ne casse. Skysnag offre une visibilité sur la structure SPF, suit les changements d’enregistrements des fournisseurs, et vous aide à restructurer les enregistrements avant que l’authentification n’échoue.