Limite des recherches SPF : diagnostic et corrections

La limite des recherches SPF peut sembler être un détail DNS jusqu'à ce que l'authentification échoue. Vous ajoutez un expéditeur, un CRM ou un outil d'assistance, puis la politique dépasse une limite du protocole. Le message peut être filtré ou rejeté selon les règles du destinataire; le dépassement ne détermine pas seul son traitement.

Pour comprendre la place de SPF dans votre configuration, commencez par la messagerie professionnelle. SPF n'est pas une simple formalité de marque. C'est un signal d'authentification que les destinataires peuvent utiliser pour évaluer les messages.

Ce guide explique ce que SPF limite, quels termes comptent, pourquoi l'aplatissement impose un entretien supplémentaire et quelles alternatives envisager pour une configuration durable.

Qu'est-ce que la limite des recherches SPF ?

La limite des recherches SPF porte sur les termes nécessitant des recherches DNS pendant l'évaluation, pas simplement sur tous les paquets DNS envoyés. Selon RFC 7208, elle est fixée à 10; son dépassement produit permerror plutôt qu'une validation.

En bref, SPF dispose d'un budget. Si l'évaluation parcourt plus de 10 termes nécessitant des recherches DNS, le destinataire doit l'arrêter et retourner une erreur permanente. Ce n'est pas une particularité de Gmail, mais une règle SPF.

RFC 7208 précise les termes concernés : include, a, mx, ptr, exists et redirect. Les termes ip4, ip6 et all ne consomment pas ce budget lors de l'évaluation.

Cette distinction compte : la longueur du texte ne représente pas son coût d'évaluation. Un enregistrement court peut échouer, un plus long peut être évalué correctement. Il faut examiner les termes réellement parcourus et leurs dépendances.

Quels éléments comptent dans cette limite ?

La limite des recherches SPF compte les mécanismes et modificateurs concernés qui utilisent DNS, pas les mots du TXT. Les termes correspondants des includes imbriqués comptent aussi. Votre panneau DNS peut donc masquer une partie du coût réel.

Ces termes consomment du budget lorsqu'ils sont évalués :

1. include : évalue la politique d'un autre domaine et correspond si elle retourne pass.
2. a : recherche les adresses du nom indiqué et les compare à l'IP connectée.
3. mx : obtient les serveurs MX puis leurs adresses, avec des limites supplémentaires propres.
4. ptr : effectue des vérifications inverses et directes; son usage est déconseillé.
5. exists : recherche les enregistrements A du nom indiqué et correspond si au moins un est retourné.
6. redirect : délègue à une autre politique SPF si aucun mécanisme précédent ne correspond.

Ces termes ne consomment pas ce budget de recherches pendant l'évaluation SPF :

• ip4
• ip6
• all

Le piège est le calcul récursif. Si vous incluez Microsoft et que sa politique en inclut une autre, les termes concernés évalués dans cette dernière comptent aussi. Votre configuration dépend de la structure SPF des prestataires.

Vous pensez avoir ajouté 6 expéditeurs. Après parcours des dépendances, le destinataire peut évaluer 11 ou 12 termes soumis à la limite. Vous dépassez alors le budget SPF tout en pensant être resté sous 10.

Pourquoi le problème apparaît avec l'ajout d'outils

La limite des recherches SPF devient souvent un problème quand l'entreprise ajoute des services. Marketing, assistance, recrutement, CRM et envoi transactionnel peuvent demander un include dans la politique du même domaine, même si leurs expéditeurs d'enveloppe n'ont pas besoin de partager ce domaine.

Au début, l'enregistrement peut être simple. Les exemples suivants sont illustratifs; vérifiez les valeurs actuelles des prestataires avant publication :

v=spf1 include:_spf.google.com ~all

Puis les services s'accumulent :

v=spf1 include:_spf.google.com include:servers.mcsv.net include:mail.zendesk.com include:spf.hubspot.com include:amazonses.com ~all

Vous ne maintenez plus seulement une liste locale, mais une chaîne de dépendances que les prestataires peuvent modifier.

Le problème peut alors sembler aléatoire en production. Votre DNS n'a pas changé ce matin, mais un prestataire a pu ajouter des dépendances. Un parcours auparavant valide peut maintenant retourner permerror. Mesurez après les changements et contrôlez périodiquement.

Si le problème de livraison dépasse SPF, consultez le guide TrekMail pourquoi les emails arrivent dans le spam. Authentification, réputation et contenu sont des signaux distincts qui peuvent intervenir ensemble.

Que se passe-t-il en cas de dépassement ?

Lorsque la limite des recherches SPF est dépassée, l'évaluation retourne permerror. Tous les destinataires ne traitent pas le message de la même façon, mais cette évaluation ne fournit plus une validation SPF.

Il n'existe pas de validation partielle parce que le budget a été presque respecté. Toutefois, SPF ne détermine pas à lui seul DMARC ou le traitement final.

Les recommandations Google relient la livraison à une authentification et un alignement corrects, avec des exigences selon la catégorie d'expéditeur. Si vous envoyez à Gmail en volume, examinez SPF, DKIM et la portée actuelle des consignes pour les expéditeurs.

Deux limites connexes méritent aussi votre attention :

1. Recherches sans données utiles. RFC 7208 recommande de limiter à deux les recherches retournant un nom inexistant ou une absence de données. Une faute dans un include ou un domaine abandonné mérite examen, mais l'effet dépend de la réponse DNS et de l'évaluation.
2. Taille des réponses DNS. Une réponse importante peut être tronquée et nécessiter un autre transport. Si ce recours échoue, des erreurs temporaires ou délais d'attente peuvent apparaître; la taille seule n'impose pas l'échec.

Pourquoi l'aplatissement SPF n'est pas toujours le bon choix

La limite des recherches SPF incite à remplacer les includes par des IP : c'est l'aplatissement, ou flattening. Il réduit les termes nécessitant DNS, mais transfère l'entretien des autorisations à la personne qui publie le TXT.

Exemple d'aplatissement manuel :

v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -all

Ces termes ne consomment pas le budget indiqué. Mais les prestataires SaaS peuvent changer de plages IP et d'infrastructure. Un TXT obsolète risque d'exclure des expéditeurs légitimes ou de continuer à autoriser des adresses qui ne leur appartiennent plus. Les plages de l'exemple sont illustratives.

Une pratique précédente consistait à accumuler les prestataires dans le SPF racine, puis à l'aplatir quand il devenait trop complexe.

Une alternative sépare les fonctions d'envoi par sous-domaines, maintient des politiques ciblées et configure DKIM aligné. Elle peut faciliter l'entretien et l'attribution des problèmes si les services utilisent réellement ces sous-domaines dans leurs identités SMTP.

Avec TrekMail, comparez les conditions actuelles de l'hébergement multidomaine et de la tarification sans frais par boîte ou domaine, sans supposer que tous les anciens prestataires facturent pareil. Les fonctions peuvent inclure domaines personnalisés, boîtes IMAP, catch-all, migration, transfert et SMTP externe ou géré selon l'offre. La source décrit votre propre SMTP sur Free et SMTP géré sur les offres payantes; confirmez disponibilité et limites actuelles. Consultez les enregistrements DNS requis et le SMTP personnalisé (BYO).

Une approche durable : segmenter les expéditeurs

La segmentation est une option à long terme pour la limite des recherches SPF. Séparez correspondance, marketing, assistance et transactions si les services permettent de configurer leurs domaines d'expéditeur d'enveloppe. Chaque politique peut avoir ses propres dépendances; ce n'est pas une isolation absolue de réputation.

Ce modèle peut servir de référence :

1. Domaine racine pour la correspondance personnelle. Exemple : alice@company.com.
2. Sous-domaine marketing. Exemple : newsletter.company.com.
3. Sous-domaine d'assistance. Exemple : support.company.com.
4. Sous-domaine transactionnel. Exemple : updates.company.com.

Enregistrements illustratifs, à adapter au domaine réellement utilisé dans l'enveloppe :

company.com TXT "v=spf1 include:_spf.google.com ~all"
newsletter.company.com TXT "v=spf1 include:servers.mcsv.net ~all"
support.company.com TXT "v=spf1 include:mail.zendesk.com ~all"
updates.company.com TXT "v=spf1 include:sendgrid.net ~all"

Si les identités utilisent des politiques indépendantes, chaque évaluation dispose d'un budget de 10 termes. Publier des TXT ailleurs ou changer seulement le From visible ne répartit pas le coût de la politique originale. Vérifiez aussi DMARC : l'alignement relâché admet le même domaine organisationnel; le mode strict exige une correspondance exacte. Une signature DKIM valide et alignée peut également fournir la validation.

La séparation peut aussi faciliter le suivi de réputation par flux. Cependant, les destinataires peuvent relier sous-domaines, domaine organisationnel et IP partagées. Elle ne protège pas automatiquement la correspondance racine des mauvaises pratiques marketing.

Pour démarrer, consultez ajouter un domaine et vérifiez le DNS avec des tests réels. Pour quitter d'anciens prestataires, la migration IMAP peut aider à copier les données des boîtes selon les fonctions disponibles. DNS, expéditeurs des applications et authentification demandent un travail distinct.

Comment vérifier le coût d'évaluation SPF

Mesurez la limite des recherches SPF plutôt que de deviner. Récupérez le TXT et suivez chaque include et ses dépendances, en tenant compte du parcours d'évaluation pour les IP et identités réelles.

Commencez avec dig :

dig txt example.com +short

dig txt _spf.google.com +short

dig txt spf.protection.outlook.com +short

Comptez ensuite les termes concernés réellement évalués, y compris les termes imbriqués. Ces commandes affichent des enregistrements, mais ne remplacent pas une évaluation SPF complète.

Procédure pratique :

1. Récupérer le TXT SPF du domaine utilisé dans l'expéditeur d'enveloppe.
2. Recenser include, a, mx, exists et redirect; vérifier aussi tout mécanisme inverse hérité.
3. Parcourir les politiques imbriquées en respectant leur sémantique et l'ordre d'évaluation.
4. Retirer les services qui n'envoient plus après vérification de l'inventaire.
5. Évaluer les sous-domaines et tester les identités avant d'envisager l'aplatissement.

Vérifiez aussi les SPF dupliqués. Il faut publier une seule politique SPF par nom en intégrant les autorisations, pas des SPF distincts pour chaque service. Pour réorganiser une configuration complexe, consultez créer un email avec un domaine, l'hébergement multidomaine et imapsync.

Le rôle de TrekMail dans une configuration maintenable

TrekMail ne supprime pas la limite des recherches SPF : c'est une contrainte du protocole. Son modèle peut faciliter une architecture moins dispersée, mais le coût et la simplicité dépendent des besoins et du plan.

Cela peut intéresser deux groupes.

Les petites équipes peuvent garder une politique simple pour la correspondance racine et choisir SMTP externe ou géré selon les besoins. Les agences et prestataires de services gérés peuvent séparer les clients et comparer les fonctions d'ajout de domaines avec les tarifs sans frais par utilisateur. Vérifiez les ressources actuelles et documentez les identités de chaque expéditeur.

Approche précédente et approche actuelle :

Précédente : réunir correspondance, alias, applications et marketing chez un prestataire avec une politique SPF pour éviter d'éventuels frais supplémentaires.

Actuelle : envisager une plateforme multidomaine à tarif fixe, centraliser les boîtes IMAP, séparer les identités par sous-domaines et maintenir des politiques face aux changements des prestataires.

Selon la source, Starter commence à $3.50 par mois. Free coûte $0 avec 10 domaines, 5GB de stockage mutualisé et votre propre SMTP. Les offres payantes ajoutent SMTP géré, limites supérieures et automatisation selon le plan. Prix, noms des offres et ressources peuvent changer; consultez les tarifs TrekMail.

Conclusion : intégrer la limite SPF à la conception

La limite des recherches SPF est une contrainte du protocole à prévoir dans l'architecture. Si vous ajoutez des outils, gardez une marge et examinez les dépendances, sans supposer que toute croissance conduira nécessairement à l'échec.

N'attendez pas permerror pour revoir une politique surchargée. Recensez les expéditeurs, retirez les autorisations obsolètes vérifiées et envisagez des sous-domaines. Testez SPF et l'alignement DMARC après les changements, avec une procédure de retour arrière pour le trafic légitime.

Pour gérer cette architecture sur peu ou beaucoup de domaines, comparez les fonctions actuelles de TrekMail : domaines personnalisés, boîtes IMAP, stockage mutualisé, migration de boîtes et choix SMTP avec des conditions sans frais par utilisateur. Consultez l'offre gratuite sur trekmail.net ou comparez les plans sur trekmail.net/pricing. Aucune plateforme ne garantit à elle seule un DNS correct ni le placement en boîte de réception.