Votre enregistrement SPF a l'air correct, chaque expéditeur que vous utilisez y figure, et pourtant un beau jour un rapport DMARC ou un rebond signale permerror. La cause habituelle est la limite de 10 lookups DNS : SPF n'a le droit de déclencher qu'un nombre fixe de requêtes DNS pendant son évaluation, et chaque outil que vous ajoutez avec un include: en dépense une part. Ce guide montre comment compter vos lookups, quels termes en coûtent un et lesquels sont gratuits, et dans quel ordre corriger un enregistrement qui dépasse la limite sans casser le courrier d'un expéditeur oublié.
La réponse en bref#
SPF est défini dans la RFC 7208, qui dit qu'une implémentation doit limiter à 10 les termes qui provoquent des requêtes DNS pendant l'évaluation. Les termes qui comptent sont include, a, mx, ptr, exists et le modificateur redirect. Les termes qui n'ont besoin d'aucun lookup, ip4, ip6 et all, sont gratuits. Le décompte est récursif : un include: en coûte un, plus tout ce que contient l'enregistrement vers lequel il pointe. Au-delà de 10, le contrôle renvoie permerror, ce qui signifie que SPF ne passe pour aucun e-mail du domaine. Pour corriger, supprimez les includes des outils que vous n'utilisez plus, remplacez ce que vous pouvez par ip4/ip6 pour les serveurs stables, puis déplacez les expéditeurs en masse vers un sous-domaine. N'aplatissez qu'en dernier recours. Le vérificateur SPF, DKIM et DMARC gratuit et le contrôle de santé du domaine montrent l'enregistrement que vous avez publié, mais ils ne suivent pas les includes et ne comptent pas les lookups : comptez donc à la main comme décrit ci-dessous, ou utilisez un outil qui suit la récursion.
Ce qui compte dans la limite#
| Terme | Coûte un lookup ? | Remarques |
|---|---|---|
include:domain | Oui, 1 plus son contenu | L'enregistrement inclus est évalué aussi, donc ses propres includes comptent |
a ou a:domain | Oui, 1 | Un seul terme, quel que soit le nombre d'adresses renvoyées |
mx ou mx:domain | Oui, 1 | Facile à oublier ; vous n'en avez peut-être pas besoin |
ptr | Oui, 1 | Déconseillé par la RFC ; supprimez-le |
exists:domain | Oui, 1 | Rare, souvent utilisé par les configurations à base de macros |
redirect=domain | Oui, 1 plus son contenu | Ignoré si l'enregistrement contient aussi un terme all |
ip4: et ip6: | Non | Gratuits, mais c'est à vous de les tenir à jour |
all | Non | Toujours en dernier ; les termes qui suivent ne sont jamais évalués |
Un exemple concret montre à quelle vitesse cela s'additionne.
example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net include:mail.zendesk.com include:servers.mcsv.net mx a ~all"
Cet enregistrement compte six termes coûteux en lookups au niveau supérieur, et chaque include: peut en contenir d'autres. Le décompte visible est 6, le décompte réel est celui que les enregistrements imbriqués ajoutent. C'est pourquoi un enregistrement qui semble court peut dépasser la limite, et pourquoi le nombre change sans que vous touchiez à votre DNS : un fournisseur modifie son propre enregistrement SPF et votre total bouge.
La RFC dit aussi que les implémentations devraient limiter à deux les « void lookups », les requêtes qui ne renvoient rien. C'est une recommandation plutôt qu'une exigence stricte, mais un terme include:, a ou mx qui pointe vers un nom qui n'existe plus est exactement ce type de lookup. C'est une raison de plus de supprimer d'abord les includes morts.
Étape 1 : confirmer qu'il s'agit d'un problème de décompte#
Avant de changer quoi que ce soit, écartez les autres causes d'erreur SPF.
- Plus d'un enregistrement SPF. Deux enregistrements TXT
v=spf1au même nom constituent aussi une erreur permanente, et c'est facile à faire par accident quand la page de configuration d'un outil dit d'ajouter un enregistrement. Lancezdig +short TXT example.comet comptez les lignes qui commencent parv=spf1. Si vous en trouvez deux, fusionnez-les. Quand SPF, DKIM et DMARC cessent de fonctionner traite ce cas et les autres causes habituelles. - Une erreur de syntaxe. Une coquille comme
includesans domaine, une plageip4incorrecte ou une espace manquante casse l'enregistrement. - Un include en boucle. Deux domaines qui s'incluent mutuellement ne finissent jamais d'être évalués.
- Un include qui ne pointe nulle part. Le domaine cible ne publie aucun enregistrement SPF.
Si aucun de ces cas ne s'applique, comptez les lookups. Faites-le une fois à la main pour comprendre l'arborescence : interrogez l'enregistrement de premier niveau, listez chaque terme coûteux, puis interrogez chaque cible include: et redirect= et recommencez. Un outil qui suit les includes fait la récursion à votre place et vaut la peine d'être utilisé, car l'enregistrement imbriqué d'un fournisseur peut compter plusieurs niveaux. Les vérificateurs gratuits de ce site lisent l'enregistrement mais ne comptent pas.
Étape 2 : supprimer ce que vous n'utilisez plus#
C'est la correction la moins chère et elle récupère généralement plusieurs lookups. Passez en revue chaque include: et demandez-vous si quelque chose envoie encore par ce biais.
- Les outils d'essai. Des services testés pendant un mois et jamais retirés.
- Les plateformes abandonnées. L'outil marketing remplacé il y a deux ans, ou l'ancien helpdesk.
- Les fournisseurs que vous ne savez nommer que par leur include. Si vous ne pouvez pas dire ce que c'est, renseignez-vous avant de supprimer. Les rapports agrégés DMARC montrent quelles sources ont réellement envoyé en votre nom : un include qui n'apparaît jamais en un mois de rapports est un bon candidat.
Supprimez-en un à la fois, recomptez, et gardez le texte de l'ancien enregistrement pour pouvoir revenir en arrière. Retirez aussi les termes mx et a isolés, sauf si vous envoyez vraiment depuis ces hôtes, et supprimez ptr complètement.
Étape 3 : remplacer des includes par des plages d'IP, avec prudence#
Pour un expéditeur dont les adresses sont peu nombreuses et stables, comme votre propre serveur de messagerie, vous pouvez remplacer un include: ou un mx par des entrées ip4: et économiser les lookups.
v=spf1 ip4:203.0.113.10 ip4:203.0.113.11 include:_spf.google.com ~all
La contrepartie, c'est la maintenance. Une entrée ip4: est une promesse de remarquer quand les adresses changent. Ne le faites que pour une infrastructure que vous contrôlez. Ne copiez jamais la longue liste d'IP d'un grand ESP dans votre enregistrement : les fournisseurs ajoutent et retirent des adresses sans vous prévenir, et votre copie devient obsolète en silence.
Étape 4 : déplacer les expéditeurs en masse et marketing vers un sous-domaine#
Chaque domaine d'envoi a son propre enregistrement SPF et son propre budget. Si votre plateforme marketing, votre service transactionnel et votre support envoient tous en tant que example.com, ils se partagent un seul budget de 10. Donnez à la newsletter un sous-domaine comme news.example.com, publiez-y un enregistrement SPF court, et configurez la plateforme pour l'utiliser comme chemin de retour et adresse From. Cela isole aussi la réputation, ce que le guide de la stratégie de sous-domaine d'envoi explique en détail.
Gardez DMARC à l'esprit en le faisant. L'alignement compare le domaine From au domaine qui a passé SPF ou DKIM. L'alignement relaxed permet à news.example.com de s'aligner avec example.com, mais l'expéditeur doit tout de même s'authentifier sous l'un de ces domaines. Configurer DMARC traite de l'alignement.
Étape 5 : l'aplatissement, et pourquoi il devient obsolète#
Aplatir consiste à remplacer les termes include: par les adresses IP littérales vers lesquelles ils se résolvent, afin que l'enregistrement n'ait besoin d'aucun lookup. Cela fonctionne, et c'est aussi la correction la plus risquée, car l'include existe précisément pour que le fournisseur puisse changer d'adresses sans que vous modifiiez le DNS. Un enregistrement aplati fige les adresses au moment où vous l'avez construit. Quand le fournisseur ajoute un serveur, les e-mails qui en partent échouent à SPF jusqu'à ce que quelqu'un actualise votre enregistrement.
Deux autres limites s'appliquent. Un enregistrement aplati peut dépasser la taille qu'un seul enregistrement TXT peut raisonnablement contenir, et le DNS limite la taille d'une réponse UDP : les gros enregistrements doivent donc être découpés ou servis avec précaution. Et vous héritez d'une tâche d'actualisation. Si vous aplatissez, faites-le avec un service ou un script qui résout à nouveau à intervalle régulier et vous alerte en cas d'échec, jamais par un copier-coller unique.
Pour la plupart des domaines, l'ordre ci-dessus suffit. Supprimer d'abord, sous-domaine ensuite, ip4 en troisième, aplatir en dernier.
Garder le décompte sous contrôle#
Le nombre de lookups n'est pas fixe. Il bouge quand vous ajoutez un outil et quand un fournisseur modifie son propre enregistrement : un enregistrement qui passait en mars peut donc échouer en septembre sans aucun changement de votre part. Trois habitudes vous gardent en avance.
- Comptez avant d'ajouter. Vérifiez le total avant d'ajouter un include, pour savoir si le nouvel expéditeur tient.
- Recontrôlez à intervalle régulier. Les contrôles de santé du domaine recalculent le décompte récursif à chaque fois.
- Alertez à 9, pas à 11. Quand le décompte dépasse 10, vous êtes déjà en échec.
La surveillance de la santé du domaine s'occupe des deux dernières. Chaque domaine couvert reçoit un contrôle SPF quotidien qui suit les includes et les redirections et compte les lookups comme le décrit la section 4.6.4 de la RFC 7208. Elle lève un avertissement à 9 ou 10 lookups et un problème de gravité « bad » au-delà de 10, et vous envoie un e-mail dans ce cas. Elle signale aussi les autres problèmes SPF de l'étape 1 : enregistrements multiples, erreurs de syntaxe, un include qui ne publie aucun enregistrement, une fin en +all ou ?all et le mécanisme ptr. Une limite à connaître : chaque rapport dispose d'un budget de 40 requêtes DNS par domaine, de sorte que sur un très gros enregistrement certains éléments apparaissent comme non vérifiés et que le décompte est une borne inférieure. Les raisons de contrôler plus que SPF sont exposées dans la surveillance de la santé du domaine e-mail, et les guides SPF par fournisseur montrent ce que chaque expéditeur ajoute à votre décompte.
Foire aux questions
01Qu'est-ce que la limite SPF de 10 lookups DNS ?
La RFC 7208 dit qu'un contrôle SPF doit limiter à 10 les termes qui provoquent des requêtes DNS. Les termes include, a, mx, ptr, exists et redirect comptent, et les includes imbriqués aussi. Au-delà, le résultat est permerror, que les destinataires traitent comme un échec SPF.
02Les mécanismes ip4 et ip6 comptent-ils dans la limite ?
Non. ip4, ip6 et all n'ont besoin d'aucune requête DNS : ils sont gratuits. Le coût est la maintenance : c'est à vous de mettre à jour les adresses chaque fois que l'expéditeur les change.
03Aplatir mon enregistrement SPF est-il une bonne solution ?
Cela fonctionne, mais cela fige les adresses actuelles du fournisseur : les e-mails échouent donc quand il ajoute des serveurs, sauf si l'enregistrement est actualisé. Essayez d'abord de supprimer les includes inutilisés et de déplacer les expéditeurs en masse vers un sous-domaine, et n'aplatissez qu'avec une actualisation automatique.
04Pourquoi mon SPF a-t-il cassé alors que je n'ai rien changé ?
Les includes sont évalués récursivement : quand un fournisseur modifie son propre enregistrement SPF, votre total change. Un enregistrement à 9 ou 10 lookups peut basculer sans aucune modification de votre part, ce qui explique l'intérêt d'alerter avant 10.
SPF dit seulement quels serveurs peuvent envoyer en votre nom : il ne peut pas vous dire si les personnes de votre liste veulent vous lire, ni même si elles existent. Les 100 crédits gratuits de la page des tarifs lancent la vérification complète sur une liste, pour voir combien d'adresses rebondiraient. Un enregistrement qui passe SPF a encore besoin d'une liste saine pour mériter la boîte de réception.
