L’enregistrement SPF que tout le monde peut lire en cinq secondes, c’est celui avec deux includes et un -all. L’enregistrement SPF que personne ne peut lire sans compter sur ses doigts, c’est celui qu’un client a accumulé en quatre ans — include:_spf.google.com, un vieil include:_spf.mailgun.org venu d’une campagne dont personne ne se souvient, deux mécanismes a et mx hérités d’une ère auto-hébergée, et un include joker d’un fournisseur marketing qui en inclut trois autres. SPF Lookup & Parser existe pour le deuxième cas.
Ce que l’outil fait
Il récupère l’enregistrement TXT v=spf1 pour un domaine, le scinde en mécanismes individuels, résout récursivement chaque include et redirect pour que vous voyiez l’ensemble complet des expéditeurs, et compte les requêtes DNS contre la limite stricte de dix de RFC 7208. La politique catch-all (-all, ~all, ?all, +all) est mise en évidence séparément parce que mal lire le catch-all est l’erreur SPF la plus courante.
Le compteur de requêtes compte plus que la lisibilité. Une fois que l’évaluation SPF dépasse dix requêtes DNS, les destinataires doivent retourner permerror, et un SPF en permerror est traité par la plupart des destinataires comme si le domaine n’avait aucun SPF du tout. Un domaine parfaitement conforme lundi peut tomber hors de la limite mardi parce qu’un seul fournisseur SaaS a ajouté un expéditeur dans sa propre chaîne d’includes — et vous l’apprenez par la plainte de livrabilité, pas par le changement.
Comment l’utiliser
Ouvrez portjar.com/tools/spf-lookup et entrez le domaine apex (SPF est publié à l’apex, pas sur les sous-domaines sauf dans des configurations soigneusement conçues). L’analyseur retourne une décomposition qui nomme chaque mécanisme, sa source, et sa contribution au compteur de requêtes. Le catch-all est en bas et c’est le champ qu’on lit en premier.
Quand vous faites un changement pour aplatir ou restructurer l’enregistrement, relancez la recherche tout de suite après publication. L’enregistrement TXT est petit et les TTL sont typiquement courts ; la réponse devrait refléter le changement en quelques minutes.
Quand vous y recourriez
- Une plainte de livrabilité où le courriel est rejeté avec
SPF permerroroutoo many DNS lookups. Le guide de dépannage « SPF PermError » de PortJar décrit le processus compter-et-aplatir, et l’analyseur est l’outil qui compte pour vous. - Un nouvel expéditeur (une plateforme marketing, un bureau de soutien qui envoie depuis le domaine, un service de facturation) est ajouté à SPF et vous devez confirmer que l’include n’a pas poussé l’enregistrement au-delà de la limite.
- Prise en charge d’un domaine dont vous n’avez pas encore les accès registraire — l’analyseur vous dit exactement ce qui est publié sans avoir besoin d’accès.
- Une migration d’un fournisseur de courriel à un autre, où vous devez confirmer que l’ancien include a été retiré et que le nouveau a pris sa place. Oublier de retirer l’ancien include est la cause typique d’un
+alldevenant permissif par accident. - Un audit de domaine pendant une prise en charge, où vous voulez un document unique listant chaque entité autorisée à envoyer au nom du domaine. L’arbre d’includes analysé vous donne cette liste.
Quoi faire de la sortie
Un enregistrement SPF propre sous les dix requêtes, avec -all en catch-all, et une liste d’includes qui correspond à ce que le client croit envoyer, c’est l’objectif. C’est le seul état dans lequel vous devriez laisser un domaine infogéré.
Un ~all (softfail) est acceptable en déploiement progressif — il dit aux destinataires d’accepter-mais-marquer-comme-suspect les sources non autorisées. Traitez ~all comme un état de transition, pas comme une destination. Une fois que vous avez confirmé que chaque expéditeur est dans l’enregistrement et que DMARC est propre depuis une semaine, passez à -all.
Un +all est presque toujours une mauvaise configuration. Il dit aux destinataires que n’importe quelle IP peut envoyer au nom du domaine, ce qui est l’inverse de l’objectif de SPF. La cause la plus courante est une coquille — quelqu’un a collé ?all en voulant -all, ou collé +all en testant et n’a jamais reverti. Corrigez immédiatement.
Un compteur de requêtes au-delà de dix veut dire que l’évaluation SPF retournera permerror et que l’enregistrement est effectivement inexistant pour les destinataires. Le correctif consiste à aplatir — retirer les includes qui n’envoient pas réellement, remplacer les includes coûteux par des plages d’IP explicites, ou utiliser un service SPF hébergé qui aplatit pour vous. L’aplatissement échange la lisibilité humaine contre la survie du budget de requêtes.
Plusieurs enregistrements v=spf1 sur le même domaine, c’est aussi une forme permerror. Un seul enregistrement SPF est permis ; les destinataires rejetteront le lot s’ils en trouvent deux. Ça arrive typiquement quand l’assistant de prise en charge d’un fournisseur publie un second enregistrement à côté du précédent. L’analyseur signale ce cas pour que vous le repériez avant le destinataire.
Stack Harbor gère SPF, DKIM et DMARC sur chaque domaine qu’on opère dans le cadre des environnements infogérés.