Faire un lookup SPF record et comprendre ce qu’il renvoie

Un lookup SPF, c’est une simple requête TXT

Il n'existe pas de type d'enregistrement DNS dédié au SPF. Le type RR 99, créé pour ça, a été abandonné par la RFC 7208 (avril 2014, qui remplace la RFC 4408) : un enregistrement SPF se publie dans un TXT, à la racine du domaine qui apparaît dans l'enveloppe SMTP. Interroger un SPF revient donc à demander tous les TXT du domaine, puis à garder la chaîne qui commence par v=spf1.

En pratique, une seule ligne suffit et vous n'avez besoin d'aucun outil web. Sur un domaine qui envoie via Google Workspace, la réponse ressemble à v=spf1 include:_spf.google.com ~all. Si rien ne sort, le domaine n'a pas de SPF publié, ce qui donne le résultat none et non un échec.

Trois pièges reviennent tout le temps. Deux chaînes v=spf1 sur le même nom produisent un permerror immédiat, la RFC est explicite là-dessus, et ça arrive dès qu'un prestataire ajoute sa propre ligne au lieu de compléter l'existante. Un TXT est par ailleurs découpé en morceaux de 255 caractères maximum, concaténés à la lecture : un enregistrement long qui affiche des guillemets au milieu n'est pas cassé pour autant. Enfin, un sous-domaine n'hérite de rien : si vos factures partent de mail.exemple.fr, le SPF de exemple.fr ne le couvre pas.

• dig +short TXT exemple.fr : la requête de base, à filtrer avec | grep spf1 si le domaine a beaucoup de TXT
• dig +short TXT _spf.google.com : pour dérouler à la main une chaîne d'include
• nslookup -type=TXT exemple.fr : l'équivalent Windows sans outil supplémentaire
• dig +short TXT exemple.fr @8.8.8.8 : pour contourner un cache local qui vous sert encore l'ancienne valeur

Décoder la ligne que le lookup a renvoyée

Une politique SPF se lit de gauche à droite. Le premier mécanisme qui correspond à l'IP du serveur émetteur décide du résultat, les suivants ne sont jamais évalués. D'où l'importance de la fin de ligne : le all attrape tout ce qui n'a pas encore été reconnu.

Le qualificateur placé devant un mécanisme change le verdict sans changer le test. Quatre valeurs existent : + (pass, implicite si rien n'est écrit), - (fail), ~ (softfail) et ? (neutral). Un -all demande au receveur de rejeter, un ~all lui demande d'accepter en marquant. Beaucoup de domaines restent en ~all des années par prudence, ce qui affaiblit la politique sans que personne ne le remarque.

Le mécanisme ptr mérite une mention à part : la RFC 7208 déconseille formellement son usage, il est lent et peu fiable. Si vous le trouvez dans un SPF existant, c'est de la dette.

Terme	Ce qu'il teste	Coûte une requête DNS
ip4:203.0.113.0/24	L'IP source est dans ce bloc IPv4	Non
ip6:2001:db8::/32	L'IP source est dans ce bloc IPv6	Non
a / a:exemple.fr	L'IP source est un enregistrement A ou AAAA du nom	Oui
mx	L'IP source est un des serveurs MX du domaine	Oui
include:tiers.net	On évalue le SPF du domaine tiers et on garde son pass	Oui
exists:%{i}._spf.exemple.fr	Un nom construit par macro résout en A	Oui
ptr	Le reverse DNS de l'IP pointe vers le domaine (déconseillé)	Oui
redirect=exemple.fr	On remplace toute la politique par celle d'un autre domaine	Oui
all	Correspond systématiquement, à placer en dernier	Non

L’autre lookup : le plafond de dix requêtes DNS

C'est la source d'ambiguïté du terme. Quand un administrateur parle de « lookups SPF », il parle souvent du budget de la RFC 7208 : l'évaluation d'une politique ne doit pas déclencher plus de dix requêtes DNS, imbrications comprises. Dépassement égale permerror, sans avertissement, sans que le SPF change d'une ligne.

Le calcul se fait sur les termes du tableau précédent qui coûtent une requête. Prenez v=spf1 mx a include:_spf.google.com include:sendgrid.net include:servers.mcsv.net ~all : mx compte 1, a compte 1, l'include Google en consomme 4 à lui seul (le _spf.google.com plus les trois _netblocks qu'il contient), et les deux autres include comptent au minimum 1 chacun. Vous êtes déjà à 8 sans avoir regardé ce que ces deux derniers imbriquent. Il reste deux requêtes de marge. Ces chaînes de sous-include bougent chez les prestataires, alors déroulez-les avec dig plutôt que de recopier un chiffre trouvé ailleurs.

Une seconde limite passe inaperçue : les void lookups, ces requêtes qui reviennent vides ou en NXDOMAIN, sont plafonnées à deux. Un include qui pointe vers un domaine de prestataire résilié consomme donc un void, deux services morts suffisent à faire tomber la politique. Le mécanisme mx a en plus sa propre limite de dix enregistrements d'adresses résolus. Le modificateur exp, lui, n'entre pas dans le compte des dix, sa requête ayant lieu après l'évaluation.

Le cas de panne typique : un prestataire ajoute son include « pour cinq minutes », le total passe à 11. Gmail et Outlook renvoient permerror, l'alignement SPF de DMARC ne se fait plus, et si DKIM n'était pas signé correctement un domaine en p=reject voit ses envois refusés. Rien n'a changé côté serveur d'envoi. Le SPF a juste débordé.

La parade habituelle consiste à aplatir la politique, c'est-à-dire remplacer les include par les blocs ip4 et ip6 correspondants. Ça marche, et ça crée une dette : le jour où le prestataire change de plage d'IP, plus rien ne se met à jour tout seul. Préférez d'abord supprimer les include des services que vous n'utilisez plus.

Les sept résultats possibles et où les lire

La RFC 7208 définit exactement sept résultats. Un lookup manuel vous donne le contenu de l'enregistrement, pas le verdict : celui-ci dépend de l'IP émettrice et se lit dans les en-têtes du message reçu.

Récupérez un message de test dans votre boîte, affichez la source, cherchez Authentication-Results. Chez Gmail vous verrez une ligne du type : spf=pass (google.com: domain of retour@exemple.fr designates 203.0.113.41 as permitted sender) smtp.mailfrom=retour@exemple.fr. Le champ smtp.mailfrom vous dit sur quel domaine le test a réellement porté, et c'est cette information qui vaut tous les vérificateurs en ligne.

Résultat	Cause	Réaction courante du receveur
pass	L'IP est autorisée par la politique	Accepté, alignement DMARC possible
fail	Un mécanisme en -all ou -mécanisme correspond	Rejet ou spam selon la politique DMARC
softfail	Un ~all correspond	Accepté mais noté, souvent en spam
neutral	Un ?all ou ?mécanisme correspond	Traité comme none
none	Aucun TXT v=spf1 publié sur le domaine	Aucun signal, DMARC ne peut pas s'appuyer sur SPF
temperror	Panne DNS passagère pendant l'évaluation	Temporisation (4xx), l'émetteur réessaiera
permerror	Syntaxe invalide, deux records, ou plus de 10 lookups	Traité au mieux comme none, souvent plus sévèrement

Ce qu’un lookup SPF ne vous dit pas

SPF valide le domaine de l'enveloppe SMTP (le MAIL FROM, celui du Return-Path), pas l'adresse que votre destinataire voit dans son client de messagerie. Un spammeur peut parfaitement obtenir un pass SPF sur son propre domaine tout en affichant From: service@votre-banque.fr. C'est la confusion la plus coûteuse autour de SPF, et c'est exactement le trou que DMARC (RFC 7489) vient boucher en exigeant que les deux domaines soient alignés.

Deuxième limite : le transfert. Quand un destinataire fait suivre automatiquement son courrier, le message repart depuis le serveur du transitaire, qui n'est pas dans votre SPF. Résultat, un fail sur un message parfaitement légitime, sauf si le transitaire réécrit l'enveloppe via SRS. C'est pour ça qu'une politique d'authentification ne peut pas reposer sur SPF seul : DKIM, lui, survit au transfert tant que le corps du message n'est pas modifié.

Un lookup SPF ne dit rien non plus de votre réputation d'expéditeur ni de la délivrabilité. Il vérifie une déclaration d'autorisation, rien d'autre. Un domaine avec un SPF impeccable en -all peut finir en spam pour de tout autres raisons.

• SPF authentifie le MAIL FROM, DKIM signe le message, DMARC vérifie que l'un des deux s'aligne avec le From: visible
• Un pass SPF sans alignement DMARC ne protège pas votre marque contre l'usurpation
• Republier un SPF ne prend effet qu'après expiration du TTL du TXT, comptez le TTL réel du domaine avant de conclure à un échec

Testez vos connaissances

Questions fréquentes

Comment voir l’enregistrement SPF d’un domaine ?

dig +short TXT exemple.fr, puis repérez la ligne commençant par v=spf1. Sous Windows sans dig : nslookup -type=TXT exemple.fr. Aucune réponse contenant v=spf1 signifie que le domaine n'a pas de SPF, ce qui donne le résultat none et non un échec d'authentification.

Pourquoi mon SPF renvoie permerror alors qu’il a l’air correct ?

Dans la majorité des cas, la politique dépasse les dix requêtes DNS autorisées par la RFC 7208 en comptant les include imbriqués. Les autres causes fréquentes sont deux enregistrements v=spf1 publiés sur le même nom, plus de deux requêtes revenant vides, ou une faute de syntaxe comme un all placé avant d'autres mécanismes.

Combien d’enregistrements SPF un domaine peut-il avoir ?

Un seul. Si vous devez autoriser plusieurs prestataires, tout doit tenir dans la même chaîne v=spf1, en ajoutant des include ou des ip4. Deux lignes séparées font échouer l'évaluation pour tout le monde.

Faut-il finir par -all ou par ~all ?

-all demande le rejet des sources non listées, ~all demande de les accepter en les marquant. Passez en -all une fois que vos rapports DMARC confirment que toutes vos sources légitimes obtiennent un pass. Basculer trop tôt fait disparaître des messages réels, notamment ceux envoyés par des outils métier oubliés.

Un SPF valide empêche-t-il l’usurpation de mon domaine ?

Non, pas à lui seul. SPF ne contrôle que le domaine de l'enveloppe SMTP, invisible pour le destinataire. Sans DMARC en quarantine ou reject, un expéditeur peut afficher votre domaine dans le champ From tout en passant SPF sur le sien.

Faut-il publier un SPF sur un domaine qui n’envoie aucun e-mail ?

Oui, v=spf1 -all sur un domaine parking ou de redirection déclare qu'aucune IP n'est autorisée. Pensez à couvrir aussi les sous-domaines, un SPF ne descend pas dans la hiérarchie automatiquement.

À lire aussi

commande dig · chiffrement email · client email