Test SPF : vérifier un enregistrement et lire le résultat

Ce que le test SPF vérifie, et ce qu’il ignore

SPF (Sender Policy Framework, normalisé par la RFC 7208 en avril 2014, qui remplace la RFC 4408) répond à une seule question : l'adresse IP qui présente ce message a-t-elle le droit d'envoyer au nom de ce domaine ? Le domaine testé est celui de l'enveloppe SMTP, c'est-à-dire la valeur de la commande MAIL FROM, plus rarement celle du HELO/EHLO. Pas le champ From: que votre destinataire voit dans son client mail.

La distinction n'est pas théorique. Un expéditeur malveillant peut publier un SPF impeccable sur son propre domaine d'enveloppe, obtenir un spf=pass en bonne et due forme, et afficher malgré tout votre marque dans le From:. C'est exactement ce que DMARC vient corriger en exigeant un alignement entre le domaine de l'enveloppe et celui du From: affiché. Un SPF qui passe ne signifie donc jamais « ce message est authentique », seulement « cette IP était autorisée pour ce domaine d'enveloppe ».

Trois limites à garder en tête avant de lancer le moindre test :

• SPF ne contrôle ni le contenu du message, ni le champ From: visible.
• SPF ne survit pas aux redirections automatiques : le serveur qui relaie devient l'IP émettrice et échoue au test, sauf si l'opérateur applique SRS ou ARC.
• SPF ne signe rien. Contrairement à DKIM, il n'y a aucune empreinte cryptographique attachée au message, seulement une liste d'IP consultée à la volée.
• Le mécanisme ptr existe encore mais la RFC 7208 §5.5 le déconseille explicitement : coûteux en DNS et peu fiable.

Lire l’enregistrement avec dig avant tout outil en ligne

Un SPF est un simple enregistrement TXT publié à l'apex du domaine. Le type DNS dédié SPF (type 99) a été abandonné par la RFC 7208 §3.1 : si un outil vous conseille encore de le publier, il est périmé.

La commande de base : dig TXT example.com +short Filtrez si le domaine porte beaucoup de TXT (vérification Google, DKIM, DMARC) : dig +short TXT example.com | grep spf1 Vous devez obtenir exactement une ligne commençant par v=spf1. Deux enregistrements v=spf1 sur le même nom produisent un permerror et cassent l'authentification entière, y compris pour les IP correctement listées. C'est la panne classique après l'ajout d'un nouvel outil d'emailing : chaque prestataire fait publier « son » SPF au lieu de fusionner les include dans l'existant.

Chaque chaîne de caractères d'un TXT est plafonnée à 255 octets. Un SPF plus long doit être découpé en plusieurs chaînes concaténées entre guillemets dans la zone, ce que la plupart des interfaces DNS gèrent seules mais que certaines cassent silencieusement.

Le dernier terme du record décide du sort des sources non listées.

Qualificateur	Résultat renvoyé	Écriture et usage
+	pass	implicite quand aucun qualificateur n'est écrit : ip4:203.0.113.10 vaut +ip4:203.0.113.10
-	fail	-all, position stricte : le destinataire est invité à rejeter
~	softfail	~all, accepté mais marqué. Le bon réglage pendant la phase d'observation
?	neutral	?all, aucune position prise. Équivaut en pratique à ne rien publier

La limite de 10 requêtes DNS, première cause de permerror

La RFC 7208 §4.6.4 impose un plafond de 10 requêtes DNS par évaluation SPF. Au-delà, le résultat est permerror, et un permerror se comporte pour le destinataire comme une absence d'autorisation. Le compteur est global : il inclut les include imbriqués des prestataires que vous ajoutez.

Un exemple parlant. include:_spf.google.com compte pour 1 lookup, mais ce record contient lui-même trois include (_netblocks, _netblocks2, _netblocks3). Vérifiez-le : dig +short TXT _spf.google.com Le coût réel est donc de 4 requêtes sur les 10 disponibles, pour un seul prestataire. Ajoutez un routeur transactionnel, un CRM et un outil de facturation, et vous dépassez sans avoir écrit une seule ligne de trop.

La même section recommande aussi de limiter à deux les « void lookups », ces requêtes qui ne renvoient rien (NXDOMAIN ou réponse vide). Un include pointant vers un service que vous n'utilisez plus en génère un à chaque message.

Le remède pratique : remplacer les include devenus inutiles, préférer des blocs ip4:/ip6: explicites pour vos propres serveurs (coût zéro), et vérifier le compteur après chaque modification plutôt qu'une fois par an.

Terme SPF	Requêtes DNS consommées
ip4: / ip6:	0
all	0
a / mx / exists	1 chacun
include:	1, plus le coût complet du record inclus
redirect=	1
ptr	1, mécanisme déconseillé par la RFC
exp=	0, évalué après coup et hors compteur

Tester sur un message réel, pas seulement sur la syntaxe

Un validateur en ligne vous dit si le record est bien formé. Il ne vous dit pas si le serveur qui envoie vraiment vos factures figure dedans. Pour ça, envoyez un message et lisez les en-têtes chez le destinataire.

Dans Gmail, ouvrez le message puis « Afficher l'original ». Vous cherchez une ligne de ce genre : Authentication-Results: mx.google.com; spf=pass (google.com: domain of contact@example.com designates 203.0.113.10 as permitted sender) smtp.mailfrom=contact@example.com Deux informations comptent ici : le verdict (spf=pass) et surtout le smtp.mailfrom, qui vous confirme quel domaine a réellement été testé. Si smtp.mailfrom affiche un domaine technique de votre routeur alors que le From: montre le vôtre, SPF passe mais l'alignement DMARC échouera.

En ligne de commande, swaks permet de forcer un envoi depuis un serveur précis : swaks --to vous@gmail.com --from contact@example.com --server mail.example.com Pour simuler une évaluation sans rien envoyer, spfquery (paquet libmail-spf-perl sur Debian et Ubuntu) prend l'IP et l'identité à tester : spfquery --scope mfrom --id contact@example.com --ip 203.0.113.10

Testez depuis chaque source d'envoi, pas seulement depuis votre webmail principal : serveur applicatif, imprimante réseau, formulaire de contact, plateforme de newsletter. Ce sont presque toujours les envois automatiques oubliés qui finissent en spam.

Les sept résultats possibles et ce qu’ils déclenchent

La RFC 7208 §2.6 définit sept verdicts. Les connaître évite de courir après un faux problème : un temperror n'appelle pas la même réaction qu'un fail.

Depuis février 2024, Gmail et Yahoo demandent aux expéditeurs dépassant 5 000 messages par jour vers leurs domaines de publier à la fois SPF, DKIM et DMARC, et exigent au minimum SPF ou DKIM des autres expéditeurs. Un permerror silencieux qui traînait depuis des mois devient à ce moment-là un problème de délivrabilité visible.

Résultat	Cause	Réaction habituelle du destinataire
pass	l'IP correspond à un mécanisme autorisé	message accepté, alignement DMARC possible
fail	l'IP est refusée par -all ou un mécanisme en -	rejet ou classement en spam
softfail	l'IP tombe sur ~all	accepté, souvent avec un malus de réputation
neutral	?all ou mécanisme en ?	traité comme none
none	aucun enregistrement SPF publié	aucune vérification, DMARC ne peut pas s'appuyer sur SPF
temperror	panne DNS temporaire pendant l'évaluation	différé, à retester plus tard
permerror	syntaxe invalide, deux records, plus de 10 lookups	traité comme une absence d'autorisation

Testez vos connaissances

Questions fréquentes

Comment tester un SPF sans envoyer de mail ?

dig TXT votredomaine.fr +short affiche l'enregistrement publié. Vérifiez trois points : une seule ligne commence par v=spf1, le total des requêtes DNS déclenchées reste sous 10, et le record se termine par ~all ou -all. Pour aller plus loin sans envoi réel, spfquery --scope mfrom --id contact@votredomaine.fr --ip 203.0.113.10 simule l'évaluation telle que la ferait un serveur destinataire.

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

~all pendant la mise en place, le temps de repérer les envois oubliés dans les rapports DMARC. -all une fois que vous êtes certain d'avoir listé toutes vos sources. Passer directement en -all sur un parc mal inventorié fait rejeter les alertes de vos serveurs, les factures de votre outil comptable ou les mails du formulaire de contact, souvent sans que personne s'en aperçoive avant plusieurs semaines.

Puis-je publier deux enregistrements SPF sur le même domaine ?

Non. La RFC 7208 impose un seul record v=spf1 par nom : deux enregistrements donnent un permerror, y compris pour les IP correctement listées dans l'un des deux. Quand un nouveau prestataire vous demande d'ajouter « son » SPF, il faut fusionner son include dans la ligne existante, pas créer un second TXT.

Mon SPF passe mais DMARC échoue, où est le problème ?

L'alignement. SPF teste le domaine de l'enveloppe (smtp.mailfrom dans les en-têtes), DMARC exige en plus que ce domaine corresponde à celui du From: affiché. Beaucoup de routeurs utilisent par défaut leur propre domaine de rebond, ce qui donne un spf=pass parfaitement valide mais non aligné. La correction passe par la configuration d'un domaine de rebond personnalisé chez le prestataire.

Pourquoi mes messages transférés échouent-ils au test SPF ?

Parce que le serveur qui transfère devient l'IP émettrice tout en conservant l'enveloppe d'origine. Cette IP ne figure évidemment pas dans votre SPF, le test renvoie fail. Le problème est structurel, pas dans votre configuration. Les opérateurs le contournent avec SRS (réécriture de l'enveloppe) ou ARC (conservation du verdict d'origine). C'est aussi la raison pour laquelle DKIM reste indispensable en complément.

À lire aussi

commande dig · chiffrement email · client email · cloudflare dns 1 1 1 1