Publier un enregistrement SPF ne protège rien si ce même enregistrement dépasse un seuil que presque personne ne vérifie. La cause la plus fréquente d’échec SPF tient rarement à son absence pure et simple. Elle vient d’un enregistrement mal construit, qui franchit la limite de 10 requêtes DNS fixée par la RFC 7208 sans que rien ne prévienne l’expéditeur avant l’incident. Un enregistrement SPF valide contient la liste des serveurs autorisés à envoyer des emails pour un domaine ; au-delà de 10 requêtes DNS nécessaires pour l’évaluer, le serveur receveur renvoie une erreur PermError qui invalide l’authentification pour l’ensemble des messages du domaine, pas seulement pour l’expéditeur en trop.
Ce qu’un enregistrement SPF autorise réellement
Un enregistrement SPF (Sender Policy Framework) est un enregistrement DNS de type TXT publié sur un domaine, listant les adresses IP autorisées à envoyer des emails en son nom. Un serveur receveur, Gmail ou Outlook par exemple, interroge ce DNS et compare l’IP de connexion à cette liste. Le SPF vérifie précisément le MAIL FROM, aussi appelé Return-Path, l’adresse technique des rebonds et des NDR et non l’adresse affichée dans le champ « De : » du client mail. Cette distinction laisse une brèche ouverte au spoofing visuel.
Les mécanismes qui composent l’enregistrement SPF
La syntaxe SPF repose sur une série de mécanismes qui, mis bout à bout, définissent qui a le droit d’envoyer. ip4: et ip6: déclarent directement une plage d’adresses, sans interroger le DNS une seconde fois. a et mx vérifient que l’IP émettrice correspond à l’enregistrement A ou aux serveurs MX du domaine cité. include: délègue la vérification à l’enregistrement SPF d’un autre domaine, typiquement celui d’un prestataire d’envoi (ESP, CRM, outil de facturation). ptr effectue une résolution inverse, aujourd’hui déconseillée par la RFC 7208 elle-même pour sa lenteur. exists teste l’existence d’un enregistrement A construit dynamiquement. Le modificateur redirect, lui, ne s’ajoute pas à la liste : il remplace entièrement l’évaluation par celle d’un autre enregistrement, un peu comme une redirection HTTP appliquée au DNS. Chacun de ces mécanismes, à l’exception de ip4 et ip6, consomme une requête DNS distincte au moment de l’évaluation. Un include: peut lui-même contenir d’autres include: imbriqués, sans que la ligne visible ne le laisse deviner. L’ordre d’écriture compte aussi : le serveur receveur évalue les mécanismes de gauche à droite et s’arrête au premier qui correspond à l’IP émettrice. Placer les serveurs internes les plus utilisés en tête de l’enregistrement ne change rien au résultat final. Cela accélère seulement l’évaluation sur les domaines à fort volume d’envoi.
Les qualifieurs -all, ~all, ?all : ce qui arrive à un email non conforme
Un enregistrement SPF se termine toujours par un qualifieur qui fixe le sort d’un email envoyé depuis une IP absente de la liste. -all (fail strict) demande au serveur receveur de rejeter le message. ~all (softfail) demande de l’accepter mais de le marquer comme suspect, souvent en le routant vers les spams. ?all (neutral) ne donne aucune consigne claire, ce qui revient à laisser chaque fournisseur de messagerie décider seul. Un dernier qualifieur, +all, autorise explicitement n’importe quelle IP à envoyer au nom du domaine ; il n’a d’usage que pour désactiver volontairement le SPF en phase de test, jamais en production. Gmail et Microsoft 365 traitent le softfail avec une tolérance qui diminue chaque année. Un domaine encore configuré en ~all par prudence finit souvent par migrer vers -all une fois DKIM et DMARC en place ; sans ce passage, le SPF ne fait que suggérer une méfiance au lieu de la trancher.
Un enregistrement SPF commenté ligne par ligne
Prenons un exemple représentatif d’un domaine qui envoie à la fois depuis ses propres serveurs et via un ESP tiers :
v=spf1 ip4:203.0.113.10 include:_spf.google.com include:sendgrid.net mx -all
v=spf1 déclare la version du protocole, toujours identique. ip4:203.0.113.10 autorise directement le serveur mail interne de l’entreprise, sans coût de lookup. include:_spf.google.com délègue l’autorisation aux serveurs de Google Workspace, utilisés ici pour les emails des collaborateurs. include:sendgrid.net fait la même chose pour les campagnes envoyées via SendGrid. mx ajoute automatiquement les serveurs MX du domaine à la liste des expéditeurs valides. -all ferme l’enregistrement en fail strict : toute IP absente de cette liste voit son message rejeté. Cet enregistrement consomme déjà 3 lookups sur les 10 autorisés (les deux include: et le mx), sans compter que chaque include: peut lui-même déclencher plusieurs sous-requêtes une fois résolu.
La limite de 10 lookups DNS et l’erreur PermError
La RFC 7208, section 4.6.4, fixe deux plafonds distincts sur l’évaluation d’un enregistrement SPF. Le premier, le plus connu, limite à 10 le nombre de requêtes DNS déclenchées par les mécanismes include, a, mx, ptr, exists et le modificateur redirect ; ip4 et ip6 n’en coûtent aucune, puisque l’adresse est déjà écrite dans l’enregistrement. Le second plafond, moins documenté, limite à 2 le nombre de « void lookups » tolérés : une requête DNS qui revient sans réponse (NXDOMAIN), généralement causée par un include: pointant vers un domaine mal orthographié ou un prestataire résilié dont l’enregistrement a été supprimé (AutoSPF, mars 2026). Franchir l’une ou l’autre limite produit le même verdict : PermError. Le serveur receveur arrête alors l’évaluation et traite l’authentification comme un échec, pour la totalité des messages du domaine, y compris ceux envoyés depuis une IP parfaitement légitime et documentée trois lignes plus haut dans l’enregistrement.
L’aplatissement SPF, connu aussi sous le nom de SPF flattening, résout ce dépassement en remplaçant chaque include: par la liste brute des adresses IP qu’il désigne. L’évaluation ne coûte alors plus qu’un seul lookup, quel que soit le nombre de prestataires d’envoi cités au départ. Des fournisseurs spécialisés en délivrabilité comme dmarcian ou PowerDMARC documentent cette technique et proposent des services qui recalculent l’enregistrement à chaque changement d’IP côté prestataire. Le procédé a son propre plafond : une chaîne TXT DNS est limitée à 255 caractères par segment. Un enregistrement aplati qui liste des dizaines d’adresses IP directement finit parfois par s’en approcher dangereusement, ce qui oblige à le découper en plusieurs chaînes concaténées.
C’est ce qui explique un scénario classique en équipe growth : les campagnes finissent en spam, sans qu’aucune explication ne remonte du côté du SaaS d’emailing utilisé, qui affiche pourtant « SPF configuré ». Le dashboard vérifie l’existence et la syntaxe de l’enregistrement. Il ne recalcule jamais le nombre de lookups une fois tous les include: résolus en cascade. Un domaine qui a accumulé Google Workspace, un ESP transactionnel, un outil de marketing automation et un CRM peut dépasser la limite sans qu’aucune de ces intégrations, prise isolément, ne semble en cause.
Vérifier son enregistrement SPF avant qu’il ne casse
Vérifier son enregistrement SPF ne demande pas d’outil payant. La méthode la plus directe se déroule en trois étapes :
- Interroger le DNS en ligne de commande avec
dig txt votredomaine.com(ounslookup -type=txt votredomaine.comsous Windows) pour lire l’enregistrement tel qu’il est réellement publié, pas tel qu’il a été saisi dans l’interface du registrar. - Passer cet enregistrement dans un vérificateur SPF en ligne qui résout chaque
include:imbriqué et affiche le décompte total de lookups, plutôt que de compter les mécanismes à la main. - Refaire ce contrôle à chaque ajout d’un nouveau service d’envoi (ESP, outil de facturation, plateforme de recrutement qui envoie des emails candidats) et pas seulement au moment de la configuration initiale.
Google Postmaster Tools sert d’outil postmaster côté Gmail. Le SNDS joue le même rôle chez Microsoft pour le suivi de réputation IP. Les deux affichent un historique d’authentification. Aucun des deux ne signale un dépassement de lookups avant qu’il ne produise un PermError effectif sur un envoi réel.
Le double enregistrement et les erreurs qui reviennent le plus souvent
Un domaine ne doit publier qu’un seul enregistrement SPF. En avoir deux, souvent parce qu’une agence a ajouté le sien sans supprimer celui déjà en place, produit un nouveau PermError : la RFC 7208 n’a pas prévu de fusion automatique entre deux enregistrements TXT de type SPF. L’autre erreur récurrente consiste à oublier un prestataire d’envoi tiers dans la liste, un outil de sondage ou une plateforme de recrutement qui envoie des emails transactionnels au nom du domaine sans jamais avoir été ajouté à l’enregistrement. Ces messages échouent silencieusement jusqu’à ce qu’un client signale ne rien avoir reçu.
Le transfert d’email fait échouer le SPF : ce que fait (et ne fait pas) SRS
Un email transféré casse presque toujours le SPF, par construction du protocole. Le serveur qui relaie le message n’apparaît jamais dans l’enregistrement SPF du domaine d’origine, l’authentification échoue donc côté destinataire final. Le Sender Rewriting Scheme (SRS) corrige ce cas précis en réécrivant l’adresse MAIL FROM du message avec le domaine du serveur relais, qui lui est bien autorisé dans son propre SPF (documentation Microsoft Learn, septembre 2025). Ce mécanisme a un angle mort documenté par Microsoft lui-même : le SPF valide alors le domaine du relais, pendant que le champ « From » visible par le destinataire continue d’afficher le domaine d’origine.
La documentation Microsoft le précise noir sur blanc : SRS ne résout pas le cas des messages transférés qui échouent au DMARC, ce protocole exigeant un alignement entre le domaine validé par SPF (ou DKIM) et le domaine affiché dans le champ From.
Un message peut donc passer le SPF grâce à SRS et échouer quand même en DMARC reject, faute d’alignement entre les deux domaines vérifiés.
SPF, DKIM et l’alignement DMARC : le mécanisme qui protège vraiment la réputation
SPF et DKIM ne parlent pas de la même chose au serveur receveur. SPF valide le MAIL FROM, DKIM signe cryptographiquement l’ensemble du message. DMARC ajoute une couche que les deux protocoles ignorent seuls : l’alignement, c’est-à-dire la vérification que le domaine authentifié par SPF ou DKIM correspond effectivement au domaine affiché dans le champ « From » lu par l’utilisateur. Sans cet alignement, un message peut valider le SPF via un ESP tiers tout en affichant un domaine d’expéditeur totalement différent, ce qui est exactement le schéma d’une attaque de phishing par usurpation. Ce triple contrôle conditionne le taux de complaint rate et la lutte contre le spam et le phishing côté Gmail comme Outlook.
Un enregistrement SPF propre ne compense pas une liste pleine d’adresses mortes : une campagne envoyée à des adresses inexistantes fait grimper le taux de hard bounce, ce qui dégrade la sender reputation que le SPF et le DKIM sont censés protéger, quel que soit le soin apporté à la configuration DNS. Vérifier la liste avant l’envoi, une pratique de list hygiene basique, coûte moins cher en réputation que de filtrer après coup les Enhanced Status Codes 5.1.1 remontés par les serveurs de destination une fois la campagne partie. La DMARC ferme la boucle : sans elle, SPF et DKIM restent deux vérifications isolées, sans lien garanti avec l’adresse que le destinataire regarde vraiment.
Un domaine correctement authentifié ne se remarque jamais : il n’apparaît dans aucun rapport d’incident, précisément parce que personne n’a besoin d’en parler.
