Vérifier un enregistrement SPF : comment le lire, et le plafond qui le casse

Vérifier un enregistrement SPF : ce que le résultat vous dit vraiment

Vérifier un enregistrement SPF, c'est lire l'enregistrement TXT publié sur votre domaine pour savoir quels serveurs vous avez autorisés à envoyer des emails en votre nom. Cela répond à une question, et une seule : cet expéditeur figure-t-il sur la liste. Cela ne dit pas si votre email atteint une boîte de réception, et c'est dans cet écart que la plupart des configurations de prospection échouent en silence.

La majorité des vérificateurs vous rendent une coche verte et s'arrêtent là. Les trois choses qui cassent réellement un domaine d'envoi viennent après : le plafond de dix requêtes DNS, une politique qui autorise tout le monde, et un enregistrement qui était correct jusqu'au jour où vous avez ajouté un troisième outil d'envoi. Cette page traite la vérification, puis ces trois points, du point de vue de quelqu'un qui fait de la prospection à froid et non d'un administrateur de messagerie d'entreprise. Elle s'inscrit dans notre cluster cold email.

Lire un enregistrement SPF, mécanisme par mécanisme

Un enregistrement tient sur une ligne. Chaque élément est un mécanisme, et ceux qui obligent le serveur destinataire à faire une requête DNS supplémentaire sont ceux qui coûtent cher.

Si vous partez de zéro plutôt que de réparer, les contrôles à faire une fois par domaine donnent l'ordre dans lequel s'y prendre. Lu de gauche à droite, l'enregistrement est une liste de qui a le droit d'écrire, terminée par un verdict sur tous ceux qui n'y figurent pas. Ce verdict compte moins qu'on ne le croit, et les requêtes comptent bien davantage.

Vérifier votre enregistrement SPF et compter les requêtes

Les outils qui font ce travail s'appellent un vérificateur SPF, un SPF checker ou un SPF lookup, et ils lisent tous le même enregistrement TXT. La plupart interrogent le DNS à partir d'un nom de domaine ; celui-ci prend l'enregistrement lui-même, il fonctionne donc aussi sur un brouillon que vous n'avez pas encore publié. Collez l'enregistrement que vous publiez aujourd'hui. L'analyseur tourne dans votre navigateur, compte les mécanismes qui coûtent une requête, et signale les défauts de structure qui font ignorer l'enregistrement.

S'il a signalé un problème, les deux sections qui suivent expliquent ce qui casse et comment le réparer, dans l'ordre le moins coûteux. Une limite honnête d'abord, et c'est la plus importante : l'outil compte les mécanismes écrits dans votre enregistrement. Un include: renvoie vers un autre enregistrement qui porte les siens, donc huit mécanismes écrits peuvent en valoir quinze à l'exécution. Lisez ce chiffre comme un plancher.

Écrire un enregistrement SPF de zéro

Un premier enregistrement tient en trois parties sur une ligne : la balise de version, un mécanisme par expéditeur que vous utilisez, et une politique pour tous les autres. Pour un domaine qui passe par un seul fournisseur, cela donne v=spf1 include:le-fournisseur ~all, et rien de plus n'est nécessaire le premier jour.

Deux contraintes gouvernent la suite. L'enregistrement doit tenir dans une seule chaîne DNS TXT de 255 caractères ; au-delà, il faut le découper en plusieurs chaînes entre guillemets que les résolveurs recollent, ce qui est une source fréquente d'enregistrements cassés en silence. Et chaque expéditeur ajouté ensuite consomme une part de votre budget de requêtes : ajoutez-les un par un et revérifiez entre chaque. Des générateurs existent, mais un enregistrement assez court pour être correct est aussi assez court pour être écrit à la main.

La limite des dix requêtes DNS, la panne que personne ne voit venir

La norme qui définit SPF, la RFC 7208, plafonne le serveur destinataire à dix requêtes DNS par évaluation. Au-delà, il renvoie permerror : il arrête d'évaluer et traite votre SPF comme s'il n'existait pas. Rien ne rebondit. Rien ne vous prévient. Votre authentification cesse simplement de compter, et si vous publiez DMARC par-dessus, l'alignement dont il dépend disparaît sans bruit.

C'est un problème de comptage, pas de syntaxe, et c'est pourquoi un enregistrement peut passer un validateur basique tout en étant mort. C'est aussi cumulatif et invisible : les outils auxquels vous déléguez modifient leurs propres enregistrements sans vous prévenir, donc un enregistrement qui comptait neuf le trimestre dernier peut en compter onze aujourd'hui sans que personne y ait touché.

Pourquoi une configuration de prospection casse plus vite qu'une configuration d'entreprise

Une messagerie d'entreprise se résume en général à un ou deux include, et n'en bouge plus pendant des années. Une configuration de prospection, elle, accumule. L'outil de séquence, puis un deuxième pour un autre segment, puis le CRM qui envoie ses notifications, puis l'outil de prise de rendez-vous, puis le gestionnaire de formulaires. Chacun arrive avec son include: et son guide d'installation rassurant, et aucun ne mentionne les quatre autres.

Trois conséquences à anticiper.

• Le plafond arrive sans événement. Aucun outil ne vous dit que son ajout vous a fait passer de neuf à onze. Le premier symptôme est une baisse lente du placement, qui ressemble exactement à un problème de copy.
• Un domaine d'envoi séparé est la réponse structurelle. Faire tourner la prospection sur son propre domaine garde l'enregistrement principal court et donne à chaque domaine son budget de requêtes. Cela isole aussi la réputation, ce qui est de toute façon la raison pour laquelle la plupart des équipes le font.
• Les sous-domaines n'héritent pas. Un enregistrement posé sur la racine ne couvre pas mail.exemple.com. Chaque sous-domaine expéditeur publie le sien, et l'oublier est la première cause d'échec d'authentification d'un nouveau domaine de prospection.

Ce que vérifier un enregistrement SPF ne vous dit pas

Une vérification SPF qui passe prouve une seule chose : ce serveur figurait sur la liste. Elle ne prédit rien de la boîte de réception, ne dit rien des adresses auxquelles vous écrivez, et ne couvre que l'expéditeur d'enveloppe. C'est la partie que les outils laissent de côté, et c'est elle qui décide si l'exercice a servi à quelque chose.

Elle ne prédit pas la boîte de réception. SPF est une liste d'autorisations, pas un score de réputation. Un message parfaitement authentifié, parti d'un domaine froid vers une liste sans engagement, atterrit quand même en spam. L'authentification vous achète le droit d'être jugé sur le fond, rien de plus.

Elle ne dit rien des adresses auxquelles vous écrivez. Les rebonds se décident sur la qualité de la liste, pas sur votre DNS. Un enregistrement peut être irréprochable pendant qu'un dixième de votre liste est injoignable, et ce taux de rebond abîme la réputation d'expéditeur que l'enregistrement était censé protéger.

Elle ne couvre que l'expéditeur d'enveloppe. SPF valide le domaine de return-path, que votre outil d'envoi contrôle souvent. C'est pour cela que SPF seul ne suffit pas, et que DKIM et DMARC existent.

Dit simplement : l'authentification est une porte qu'on passe une fois. Ce que vous envoyez ensuite décide du résultat, et c'est le sujet de nos guides sur les objets de mail et sur le moment d'envoi.

Réparer un enregistrement qui dépasse la limite

Repasser sous dix est presque toujours possible sans rien aplatir. Quatre gestes, du moins cher au plus engageant : faites-les dans l'ordre et arrêtez-vous dès que vous êtes sous le plafond.

1. Retirez ce qui n'envoie plus. La plupart des enregistrements hors limite portent l'include d'un outil que l'équipe a cessé d'utiliser il y a deux ans. C'est gratuit et c'est en général suffisant.
2. Remplacez un include par ses plages d'adresses. Si le fournisseur publie une plage stable, des entrées ip4: coûtent zéro requête. Le compromis est réel : le jour où le fournisseur change ses plages, votre enregistrement est faux et rien ne vous le signale.
3. Découpez par sous-domaine. Le marketing sur un sous-domaine, la prospection sur un autre, le transactionnel sur un troisième. Chacun a son enregistrement et ses dix requêtes. C'est l'option qui continue de fonctionner quand vous ajoutez des outils.
4. Aplatissez, en connaissance de cause. L'aplatissement automatique résout tout en adresses IP et les tient à jour. Il règle le comptage et crée une dépendance : à traiter en dernier recours, pas en réglage par défaut.

Relancez la vérification après chaque geste plutôt qu'à la fin, pour savoir lequel vous a rendu de la marge. Et si vous venez de basculer la prospection sur son propre domaine, la partie copy repart elle aussi de zéro : nos six formats de modèle supposent un domaine qui authentifie déjà.

SPF, DKIM et DMARC : ce que votre vérification doit couvrir

SPF tout seul est la configuration à moitié faite la plus répandue en prospection. Les trois enregistrements font des métiers différents et ne fonctionnent qu'ensemble.

Démarrez DMARC en politique de surveillance, pour que les rapports arrivent avant que vous n'imposiez quoi que ce soit. Ces rapports sont aussi l'endroit où un permerror remonte tout seul, sans que personne pense à aller le chercher.

Vérifier un enregistrement SPF en prospection : les erreurs à éviter

• Publier deux enregistrements SPF. Deux TXT commençant par v=spf1 s'invalident mutuellement. Fusionnez-les en un seul, toujours.
• Laisser +all après une séance de débogage. Cela autorise internet entier à écrire en votre nom, ce qui est pire que de ne rien publier.
• Passer directement à -all. Le hardfail avant que votre liste d'expéditeurs soit complète bloque votre propre courrier légitime. Restez sur ~all tant que les rapports ne sont pas propres.
• Vérifier la racine et supposer le sous-domaine. Ce sont deux enregistrements distincts. Vérifiez le domaine exact de votre return-path.
• Prendre une coche verte pour un verdict de délivrabilité. C'est un contrôle d'autorisation. La liste à laquelle vous écrivez décide du reste.

À retenir

• Une vérification SPF dit qui a le droit d'écrire en votre nom, pas si vous atteignez la boîte de réception.
• Le plafond de dix requêtes DNS est la panne qui arrive en silence, et les include s'imbriquent : comptez large.
• Les configurations de prospection atteignent ce plafond plus vite, parce que les outils s'ajoutent un include à la fois.
• Un domaine d'envoi séparé, avec son enregistrement par sous-domaine, est la réparation qui tient dans le temps.
• ~all tant que vous ajoutez des expéditeurs, -all une fois la liste stable, jamais +all.
• SPF, DKIM et DMARC forment un ensemble. DMARC en surveillance est ce qui rend un permerror visible.

Une fois l'authentification en ordre, la variable qui décide encore de votre taux de rebond est la liste elle-même, et celle-là n'est pas un problème de DNS. Derrick trouve et vérifie les adresses depuis la feuille Google Sheets, l'assistant IA ou l'API où votre liste se trouve déjà, avec Email Verification à 1 crédit par email, facturé uniquement quand un résultat revient. La vérification est sur les plans payants ; le plan gratuit et ses 100 crédits par mois servent à essayer d'abord la recherche et l'enrichissement sur un vrai lot. Commencez avec le plan gratuit, ou parcourez le reste du cluster cold email.

Nous publions aussi un email tous les 15 jours avec ce que nous mesurons sur la prospection à froid et la qualité de la donnée. Inscrivez-vous depuis la page d'accueil.