La limite des recherches SPF est simple : si l’évaluation de votre politique SPF nécessite plus de 10 termes déclenchant des requêtes DNS, les destinataires peuvent arrêter le traitement et renvoyer une erreur permanente. Un message dont la configuration semble correcte dans votre panneau DNS peut donc échouer à l’authentification en conditions réelles. Si vous faites déjà le ménage dans la messagerie de votre domaine, commencez par la messagerie professionnelle pour petites entreprises, puis revenez corriger ce qui pose souvent problème plus tard.
Ce piège concerne de nombreuses équipes. Elles ajoutent Google Workspace, puis Microsoft 365, Mailchimp, un CRM et un outil de support. Chaque prestataire dit : « Ajoutez simplement notre include. » Quelques mois plus tard, le registre SPF reste valide sur le plan syntaxique, mais ne fonctionne plus en pratique. Les messages arrivent dans les indésirables. Certains sont rejetés. Personne ne comprend pourquoi, car le registre paraît normal au premier coup d’œil.
Bonne nouvelle : la correction est généralement simple. Supprimez les entrées obsolètes. N’utilisez plus `mx`, sauf si vous en avez réellement besoin. Placez les envois marketing sur un sous-domaine. Gardez votre domaine principal propre.
Qu’est-ce que la limite des recherches SPF ?
La limite des recherches SPF est le plafond défini par le RFC pour les termes SPF déclenchant des requêtes DNS pendant l’évaluation. Les destinataires ne doivent pas traiter plus de 10 de ces termes sur le chemin évalué de l’arbre SPF, y compris les chaînes de `include` imbriqués. Au-delà, SPF peut renvoyer `permerror`, et votre message perd un signal d’authentification important.
Le RFC 7208 définit cette règle. Le plafond évite que SPF ne provoque des problèmes d’amplification DNS. Ce n’est ni une option ni une simple bonne pratique : c’est une limite du protocole.
Le point souvent oublié est que la limite des recherches SPF est cumulative. Vous n’avez pas droit à 10 recherches dans le registre racine, puis à 10 autres dans chaque include. Le budget est unique pour tout le chemin d’évaluation.
| Mécanisme SPF | Coût en recherches | Conseil pratique |
|---|---|---|
include: | 1 | Courant, mais les includes imbriqués s’accumulent vite |
a | 1 | Acceptable dans une petite configuration, souvent inutile |
mx | 1+ | Généralement peu adapté à l’autorisation des envois |
ptr | 1+ | À éviter ; le RFC 7208 en déconseille fortement l’usage |
exists | 1 | Rare et facile à mal employer |
redirect= | 1 | Utile dans certains schémas, mais compte aussi |
ip4 / ip6 | 0 | Aucune requête DNS pendant l’évaluation SPF |
all | 0 | Définit seulement la politique, sans coût de recherche |
Pourquoi la limite des recherches SPF fait échouer des registres « fonctionnels »
La limite des recherches SPF fait échouer des registres apparemment corrects parce que SPF ne juge pas la lisibilité du TXT racine. Il compte les termes déclenchant du DNS que le destinataire doit évaluer en suivant include, redirect, `a` et `mx` sur le chemin complet.
Exemple :
Vous publiez `v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:servers.mcsv.net -all` et pensez avoir consommé trois recherches. Ce n’est pas le cas. Les registres de Google et Microsoft se développent chacun en recherches supplémentaires. Le registre visible est court ; celui qui est évalué ne l’est pas.
C’est pourquoi la limite des recherches SPF pose souvent problème plus tard, pas dès le premier jour. Quand les prestataires modifient leurs arbres SPF, votre compteur peut augmenter sans aucune modification de votre DNS.
Un autre piège concerne les recherches vides. Le RFC 7208 recommande aux implémentations de les limiter à deux. Une recherche vide est une requête DNS sans réponse ou renvoyant `NXDOMAIN`. Une faute de frappe dans un include peut ne pas suffire à tout bloquer. Deux références incorrectes peuvent provoquer un échec. Votre problème de limite des recherches SPF devient alors un problème de `permerror`, même en restant sous 10.
Les consignes de Google pour les expéditeurs illustrent aussi l’enjeu : une authentification absente ou défectueuse peut entraîner le classement en spam ou le rejet des messages d’expéditeurs en nombre. Google indique que ces expéditeurs doivent configurer SPF, DKIM et DMARC, et que les messages ne respectant pas les exigences peuvent être rejetés ou envoyés dans les indésirables. Consultez la FAQ des exigences Google pour les expéditeurs.
Comment calculer l’utilisation des recherches SPF
Pour calculer l’utilisation de la limite des recherches SPF, partez du registre SPF racine et comptez les mécanismes déclenchant du DNS sur chaque chemin d’évaluation de l’arbre récursif. Cela comprend vos termes et ceux auxquels vos prestataires font référence. Si un chemin dépasse 10, la politique peut échouer en pratique.
Commencez par le registre racine :
dig +short txt example.comExemple de résultat :
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"Examinez ensuite chaque domaine référencé :
dig +short txt _spf.google.com
dig +short txt spf.protection.outlook.comPoursuivez jusqu’à ne trouver que `ip4`, `ip6` ou des termes terminaux de politique.
Utilisez cette méthode de comptage :
- Comptez chaque
include,a,mx,ptr,existsetredirectrencontré. - Comptez aussi les termes imbriqués dans les registres inclus.
- Ne comptez pas
ip4,ip6niall. - Signalez les cibles d’include qui ne renvoient aucune donnée. Elles peuvent causer des recherches vides.
Pour vérifier rapidement le DNS lors de la configuration d’un domaine dans TrekMail, commencez par la documentation sur la vérification de l’état DNS et les enregistrements DNS requis.
Erreurs fréquentes liées à la limite des recherches SPF
La plupart des dépassements de la limite des recherches SPF viennent d’erreurs récurrentes : empiler les prestataires sur le domaine racine, conserver d’anciens fournisseurs, utiliser `mx` comme raccourci et aplatir manuellement sans processus de maintenance. Rien d’exceptionnel : une gestion approximative du DNS devient plus problématique à mesure que l’activité grandit.
Les principaux cas :
| Erreur | Conséquence | Meilleure approche |
|---|---|---|
| Conserver d’anciens prestataires | Consomme le budget de recherches et augmente le risque | Supprimez les services qui ne servent plus à envoyer |
Utiliser mx pour autoriser les envois | Les hôtes MX de réception ne sont souvent pas vos expéditeurs | Autorisez explicitement le véritable expéditeur |
Utiliser ptr | Lent, déconseillé et fragile | Supprimez-le |
| Tout envoyer depuis un domaine | Le marketing et le transactionnel partagent le même budget SPF | Répartissez les flux entre des sous-domaines |
| Aplatir manuellement | Peut échouer quand les prestataires changent leurs IP | Automatisez les mises à jour ou évitez l’aplatissement |
Les équipes confondent également complexité visible et complexité réelle. Un seul include de prestataire peut consommer plusieurs recherches après expansion. C’est pourquoi la limite des recherches SPF finit par sanctionner le réflexe « ajoutons juste un expéditeur ».
Si vous hésitez encore entre transfert, alias et véritable boîte aux lettres pour un usage donné, ces choix influencent davantage la configuration des expéditeurs qu’on ne le pense. À lire aussi : alias de domaine ou boîte aux lettres et transfert avec un alias e-mail.
Comment corriger la limite des recherches SPF sans perturber le courrier
L’approche la plus prudente pour résoudre la limite des recherches SPF consiste à simplifier SPF plutôt qu’à accumuler les contournements. Supprimez d’abord les expéditeurs obsolètes. Déplacez ensuite les systèmes à fort volume vers des sous-domaines. N’aplatissez que si vous pouvez automatiser la maintenance.
1. Supprimez le superflu.
Retirez les prestataires inutilisés. Supprimez `ptr`. Remplacez `mx` par l’autorisation de l’expéditeur réellement nécessaire. Une simple opération de nettoyage suffit souvent à repasser sous la limite des recherches SPF.
2. Séparez le trafic par sous-domaine.
C’est souvent une bonne solution pour les équipes en croissance.
; Primary company mail
example.com. TXT "v=spf1 include:spf.trekmail.net -all"
; Marketing mail
marketing.example.com. TXT "v=spf1 include:servers.mcsv.net include:hubspotemail.net -all"
; Transactional app mail
notify.example.com. TXT "v=spf1 include:amazonses.com -all"Chaque sous-domaine dispose de son propre budget SPF. Cela aide à stabiliser le domaine racine et rend la limite des recherches SPF bien plus facile à gérer.
3. N’aplatissez qu’en dernier recours.
L’aplatissement remplace les includes par des plages IP explicites :
; Before
v=spf1 include:vendor-a.example include:vendor-b.example -all
; After
v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 ip4:198.51.100.0/24 -allIl réduit presque à zéro le nombre de recherches, mais crée une dette de maintenance. Les prestataires changent leurs IP, votre registre devient obsolète et des messages peuvent échouer. Si vous aplatissez, automatisez les mises à jour.
Ancienne et nouvelle approche : gérer la limite des recherches SPF avec TrekMail
L’ancienne approche de la limite des recherches SPF consiste à empiler fournisseurs de boîtes, plateformes marketing et relais sur un domaine racine, jusqu’à devoir faire de l’archéologie dans le DNS. La nouvelle réduit les dépendances et sépare les rôles des expéditeurs dès le départ.
Ancienne approche : un SPF racine surchargé, des anciens prestataires toujours présents, le marketing mélangé au courrier des boîtes et aucune responsabilité claire sur les autorisations d’envoi.
Nouvelle approche : simplifier l’hébergement des boîtes, isoler les expéditeurs à fort volume sur des sous-domaines et conserver une politique SPF courte avec de la marge sur le domaine principal.
TrekMail peut faciliter cette organisation. Avec l’envoi géré de TrekMail sur un forfait payant, la configuration décrite consiste à ajouter `include:spf.trekmail.net` au SPF. Ce terme consomme une recherche directe ; les éventuelles dépendances imbriquées restent à vérifier. L’offre décrite commence à $3.50/mois et comprend domaines personnalisés, boîtes IMAP, catch-all, transfert de boîte, outil de migration intégré et accès API. Les forfaits payants prévoient un essai gratuit de 14 jours avec carte bancaire. Nano est présenté comme gratuit, sans essai, avec BYO SMTP ; vérifiez les conditions en vigueur.
Avec Nano, TrekMail peut servir de couche de boîtes aux lettres pendant que vous envoyez via SES, Mailgun ou un autre relais. Organisez les sous-domaines avec rigueur pour éviter que la politique racine atteigne la limite des recherches SPF. La documentation TrekMail sur le SMTP personnalisé (BYO), le SMTP géré par TrekMail et le lancement d’une migration depuis le tableau de bord détaille le fonctionnement.
Si vous regroupez vos domaines, consultez aussi l’hébergement de messagerie multidomaine et la configuration d’une messagerie sur votre domaine.
Conclusion : rester sous la limite des recherches SPF
Pour rester sous la limite des recherches SPF, gardez une configuration simple. Limitez le nombre d’expéditeurs sur le domaine racine. Déplacez les envois en nombre et ceux des applications vers des sous-domaines. Revérifiez les includes à chaque nouvel outil. Si votre politique approche de 10, considérez cela comme un avertissement.
Voilà l’essentiel. La limite des recherches SPF n’est pas un cas théorique marginal du RFC, mais une contrainte opérationnelle stricte qui complique l’accumulation de services. Gardez le registre court et les responsabilités DNS claires. Ne faites pas partager un chemin d’authentification à budget limité à cinq prestataires, sauf si vous aimez examiner les en-têtes à 2 heures du matin.
Pour une configuration plus simple, TrekMail propose un hébergement de messagerie multidomaine à tarif forfaitaire, sans frais par utilisateur, avec stockage mutualisé, migration IMAP intégrée et choix entre BYO SMTP et SMTP géré par TrekMail, selon l’offre et le forfait en vigueur. Consultez les tarifs TrekMail ou rendez-vous sur TrekMail.
