Comment vérifier le SPF d’un domaine et lire le résultat

Un check SPF consiste à lire l'enregistrement TXT commençant par v=spf1 publié sur le domaine expéditeur, puis à vérifier que l'IP du serveur d'envoi y est bien autorisée. La commande dig +short TXT votredomaine.fr affiche cet enregistrement en une seconde ; tout le travail restant consiste à compter les requêtes DNS qu'il déclenche et à choisir entre ~all et -all.

Ce qu’un check SPF regarde vraiment

SPF ne lit pas l'adresse que votre destinataire voit à l'écran. Il compare l'IP du serveur qui présente le message à la liste publiée par le domaine de l'enveloppe SMTP, celui du MAIL FROM, aussi appelé Return-Path. Un message peut donc afficher facturation@banque.fr dans le champ From et obtenir un pass SPF parfaitement valide, parce que l'enveloppe portait un tout autre domaine, contrôlé par l'expéditeur. C'est la première source de malentendu quand un client vous dit que son SPF est bon mais qu'il reçoit quand même des usurpations.

La vérification se fait côté réception, pendant la session SMTP sur le port 25. Le serveur destinataire récupère l'enregistrement TXT du domaine d'enveloppe, le lit de gauche à droite, s'arrête au premier mécanisme qui correspond à l'IP source et applique le qualificateur de ce mécanisme. Le verdict est ensuite inscrit dans les en-têtes du message, ce qui rend le contrôle rejouable des jours plus tard sur un mail archivé.

Dans un message reçu, ouvrez la source complète et cherchez ces deux lignes. Le champ smtp.mailfrom indique le domaine réellement testé, à comparer avec le From affiché.

Authentication-Results: mx.exemple.fr; spf=pass smtp.mailfrom=newsletter.boutique.fr Received-SPF: pass (exemple.fr: domain of newsletter.boutique.fr designates 198.51.100.24 as permitted sender)

Faire le check soi-même en ligne de commande

Un enregistrement SPF est un simple TXT publié au sommet du domaine. Aucun outil spécifique à installer, dig suffit. La spécification en vigueur est le RFC 7208, publié en avril 2014, qui a au passage abandonné l'ancien type d'enregistrement DNS SPF (type 99) : ne publiez plus qu'un TXT.

Attention à la longueur. Chaque chaîne de caractères d'un TXT est plafonnée à 255 octets ; un enregistrement plus long doit être découpé en plusieurs chaînes entre guillemets à l'intérieur du même TXT, que le vérificateur recolle. Si votre hébergeur DNS refuse silencieusement la fin de la ligne, votre SPF devient invalide sans prévenir.

• dig +short TXT exemple.fr : affiche la chaîne brute, qui doit commencer par v=spf1
• dig +noall +answer TXT exemple.fr : montre en plus le TTL, utile pour savoir dans combien de temps une correction sera visible partout
• dig +short TXT _spf.google.com : déplie un include pour voir les plages réellement autorisées derrière
• dig +short TXT exemple.fr @1.1.1.1 : interroge un résolveur public quand votre résolveur local garde une vieille valeur en cache
• nslookup -type=TXT exemple.fr : l'équivalent sous Windows, sans rien installer
• python3 -c "import spf; print(spf.check2(i='198.51.100.24', s='contact@exemple.fr', h='mail.exemple.fr'))" : rejoue une évaluation complète avec la bibliothèque pyspf et renvoie le verdict et son explication

Les sept verdicts et ce qu’ils déclenchent

Chaque mécanisme porte un qualificateur : + pour autoriser (valeur par défaut, rarement écrite), - pour rejeter, ~ pour signaler sans rejeter, ? pour rester neutre. Le mécanisme all placé en fin de ligne décide du sort de toutes les IP qui n'ont correspondu à rien avant lui. Un v=spf1 include:spf.protection.outlook.com -all dit donc : Microsoft 365 et personne d'autre.

Le RFC 7208 définit sept résultats possibles. Savoir les distinguer évite de chercher une panne de configuration là où il n'y a qu'une coupure DNS passagère.

Résultat	Signification	Traitement courant côté réception
pass	L'IP émettrice est autorisée par le domaine	Accepté, et exploitable pour l'alignement DMARC
fail	Le mécanisme -all a été atteint	Rejet ou quarantaine selon la politique du destinataire
softfail	Le mécanisme ~all a été atteint	Accepté mais pénalisé dans le score antispam
neutral	?all, ou aucune décision ferme possible	Traité comme une absence de SPF
none	Aucun enregistrement v=spf1 publié	Aucun crédit d'authentification
temperror	Erreur DNS temporaire pendant l'évaluation	Réponse SMTP 4xx, le message est réessayé plus tard
permerror	Syntaxe invalide, deux enregistrements SPF, ou plus de 10 requêtes DNS	Souvent traité comme none, et l'alignement DMARC tombe

Les deux pannes qui reviennent tout le temps

La première est la limite de 10 requêtes DNS. Les mécanismes include, a, mx, ptr, exists et le modificateur redirect comptent chacun pour une requête, et ce compteur se propage à l'intérieur des include imbriqués. Les mécanismes ip4, ip6 et all ne coûtent rien. Un include vers un gros fournisseur en consomme souvent trois ou quatre à lui seul : dépliez le vôtre avec dig plutôt que de vous fier à un chiffre trouvé ailleurs, ces enregistrements changent sans préavis.

Le scénario type : une PME ajoute son CRM, sa plateforme de newsletters, un outil de facturation et un service de signature électronique au fil des mois. Au onzième lookup, l'évaluation renvoie permerror et tout le domaine perd son authentification, y compris les mails qui partaient très bien la veille. Personne n'a rien cassé, on a juste ajouté un include de trop. La correction passe par la suppression des prestataires qui n'envoient plus rien, le remplacement de certains include par des blocs ip4 fixes, et le déport des envois marketing sur un sous-domaine dédié qui a son propre budget de 10 requêtes.

Deux limites secondaires font aussi tomber le même verdict : au-delà de deux requêtes revenant vides (void lookups), et au-delà de 10 adresses résolues par un seul mécanisme mx, l'évaluation s'arrête en permerror. Le mécanisme ptr, lui, est explicitement déconseillé par le RFC 7208 : retirez-le si vous en trouvez un.

La seconde panne n'est pas une erreur de configuration. Le transfert automatique casse SPF par construction : quand une adresse d'association renvoie le courrier vers une boîte Gmail personnelle, c'est le serveur de l'association qui présente le message, avec une IP absente du SPF du domaine d'origine. Le résultat est fail, alors que le message est authentique. Le contournement côté serveur de transfert s'appelle SRS, qui réécrit l'enveloppe. Avant d'accuser un expéditeur, regardez donc la chaîne des en-têtes Received.

SPF, DKIM et DMARC : ne pas confondre les trois

SPF valide un chemin : telle IP a-t-elle le droit d'émettre pour ce domaine d'enveloppe. DKIM (RFC 6376) valide un contenu, par une signature cryptographique dont la clé publique est publiée dans le DNS. DMARC (RFC 7489) s'appuie sur les deux et ajoute la pièce manquante : l'alignement. Il exige que le domaine validé par SPF ou par DKIM corresponde au domaine du champ From, celui que votre lecteur voit.

La conséquence est directe. Un spam qui obtient spf=pass sur son propre domaine jetable, tout en affichant votre nom dans le From, échoue à DMARC malgré son pass SPF. Inversement, un -all bien serré ne protège pas votre marque contre l'usurpation du champ From tant que vous n'avez pas publié une politique DMARC en p=quarantine ou p=reject. Le check SPF est donc une brique, pas le verdict final.

Vérifiez les trois d'un coup : dig +short TXT exemple.fr pour SPF, dig +short TXT _dmarc.exemple.fr pour DMARC, et dig +short TXT selecteur._domainkey.exemple.fr pour la clé DKIM, en remplaçant selecteur par celui que votre prestataire vous a communiqué.

Questions fréquentes

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

-all demande le rejet des IP non listées, ~all demande seulement de les marquer. Commencez en ~all le temps de vérifier dans les rapports DMARC que plus aucun envoi légitime n'est oublié, puis passez en -all. Rester indéfiniment en ~all fonctionne, mais laisse aux filtres la liberté d'accepter des messages usurpés.

Peut-on publier deux enregistrements SPF sur le même domaine ?

Non. Deux TXT commençant par v=spf1 sur le même nom produisent un permerror, et le domaine perd son authentification. C'est fréquent après une migration : l'ancien enregistrement reste en place à côté du nouveau. Fusionnez les mécanismes des deux lignes en une seule.

Mon message passe le SPF mais atterrit en spam, pourquoi ?

Un pass SPF prouve seulement que le serveur avait le droit d'émettre. La réputation de l'IP et du domaine, le contenu, l'historique des plaintes et la présence de DKIM et DMARC pèsent souvent plus lourd. Regardez d'abord si le domaine du From est bien aligné avec celui de l'enveloppe.

Combien de temps avant qu’une correction SPF soit prise en compte ?

Le délai correspond au TTL de l'ancien enregistrement, encore en cache chez les résolveurs des destinataires. Lisez-le avec dig +noall +answer TXT votredomaine.fr : une valeur de 3600 signifie jusqu'à une heure d'attente. Baisser le TTL avant une migration, puis le remonter, évite les surprises.

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

Oui, et c'est le cas le plus simple à traiter : v=spf1 -all déclare qu'aucune machine n'est autorisée à émettre pour ce nom. Publiez-le sur vos domaines parqués et vos redirections, ce sont les cibles les plus faciles pour une usurpation.

À lire aussi

commande dig · chiffrement email · client email

Testez vos connaissances