Vérificateur d’enregistrement SPF

Vérifiez l’enregistrement SPF d’un domaine : sa syntaxe, chaque include tel que le suit un serveur destinataire, les requêtes DNS qu’il coûte sur la limite de 10, et ce que deviennent les e-mails des serveurs qu’il ne cite pas.

Les requêtes DNS partent directement de votre navigateur vers des résolveurs publics (Cloudflare, Google) : nous ne voyons rien.

Ce que vérifie le vérificateur SPF

Un seul enregistrement SPF: Un domaine doit publier exactement un enregistrement TXT qui commence par v=spf1. Avec deux, chaque destinataire renvoie une erreur permanente (permerror), même si chacun est correct.
La syntaxe de chaque terme: Chaque mécanisme (ip4, ip6, a, mx, include, exists, ptr, all) et modificateur (redirect, exp) est lu comme le lit un destinataire. Un seul terme mal écrit, comme include; ou un nom d’hôte après ip4:, casse tout l’enregistrement.
Les requêtes DNS, include par include: include, a, mx, ptr, exists et redirect obligent chacun le destinataire à interroger le DNS, et les includes contenus dans un include comptent aussi. La RFC 7208 s’arrête à 10 : le vérificateur montre ce que coûte chaque terme et le total.
Includes morts et requêtes vides: Un include vers un domaine sans enregistrement SPF fait échouer tout l’enregistrement d’un coup, avec un permerror, dès le premier (RFC 7208, section 5.2). Les requêtes vides (void lookups) sont autre chose : des requêtes DNS qui ne renvoient aucune réponse ou NXDOMAIN, le plus souvent des mécanismes a, mx ou exists qui pointent vers des noms disparus. Au-delà de deux, SPF échoue avec un permerror (section 4.6.4).
Le mécanisme all: La fin de l’enregistrement décide du sort de tous les autres serveurs : -all refuse, ~all signale, ?all ne dit rien et +all laisse n’importe qui envoyer.
Doublons et termes obsolètes: Le même include écrit deux fois coûte deux fois ses requêtes. ptr est déconseillé par la RFC 7208, lent, et ignoré par certains destinataires.

Comment lire le résultat

Vert : correct: Un seul enregistrement valide, 10 requêtes au plus, terminé par ~all ou -all. Les e-mails des serveurs qu’il cite passent SPF.
Orange : fonctionne, mais fragile: Huit à dix requêtes, un ptr, un doublon ou ?all. SPF répond encore, mais le prochain service ajouté, ou un fournisseur qui modifie son propre enregistrement, peut faire dépasser la limite.
Rouge : SPF échoue: Deux enregistrements, une erreur de syntaxe, plus de 10 requêtes ou un include mort : les destinataires obtiennent un permerror, et DMARC le compte comme un échec pour chaque message qui s’appuie sur SPF.
Le tableau des requêtes: Chaque terme de l’enregistrement avec les requêtes qu’il coûte, includes imbriqués compris. La ligne la plus lourde est en général celle à remplacer par des plages ip4 ou à déplacer sur un sous-domaine.

Erreurs SPF fréquentes et leur correction

Les messages ci-dessous apparaissent dans les retours d’erreur, dans l’en-tête Authentication-Results d’un e-mail reçu, ou dans d’autres outils. Voici ce que chacun veut dire et ce qu’il faut changer.

`SPF permerror: too many DNS lookups`

Pourquoi. Une fois chaque include suivi, l’enregistrement demande plus de 10 requêtes DNS. Le destinataire s’arrête et renvoie une erreur permanente, que DMARC traite comme un échec SPF.

Correction. Retirez les services que vous n’utilisez plus. Remplacez les includes qui ne couvrent que quelques adresses fixes par ip4: ou ip6:, qui ne coûtent rien. Envoyez les e-mails en nombre depuis un sous-domaine (news.exemple.fr) qui a son propre SPF.

`SPF permerror: multiple SPF records found`

Pourquoi. Deux enregistrements TXT commencent par v=spf1, souvent parce qu’un nouveau fournisseur a demandé d’« ajouter un enregistrement SPF » et que l’ancien est resté.

Correction. Fusionnez-les : un seul v=spf1, tous les includes et adresses des deux, un seul all à la fin. Supprimez ensuite l’autre enregistrement.

`spf=softfail (domain of … does not designate 192.0.2.1 as permitted sender)`

Pourquoi. Le serveur qui a envoyé le message n’est pas dans l’enregistrement, qui se termine par ~all. Le plus souvent, un service qui envoie en votre nom (CRM, facturation, formulaire du site) n’a jamais été ajouté.

Correction. Retrouvez le service expéditeur dans les en-têtes Received et ajoutez l’include qu’il documente. Si le message n’était pas de vous, l’enregistrement a fait son travail.

`550 5.7.23 The message was rejected because of Sender Policy Framework violation`

Pourquoi. Microsoft, comme d’autres destinataires, a refusé le message parce que SPF a échoué sur un enregistrement en -all, ou parce que DMARC a appliqué l’échec.

Correction. Ajoutez l’expéditeur manquant, comme pour un softfail. Un e-mail transféré ne peut pas passer SPF : signez vos e-mails avec DKIM pour que DMARC passe par DKIM.

`SPF void lookup limit exceeded`

Pourquoi. Plus de deux requêtes DNS faites pour évaluer l’enregistrement n’ont renvoyé aucune réponse ou NXDOMAIN, le plus souvent des mécanismes a, mx ou exists qui pointent vers des noms supprimés ou mal écrits. Le destinataire s’arrête sur un permerror (RFC 7208, section 4.6.4).

Correction. Retirez ou corrigez les mécanismes qui pointent vers des noms qui n’existent plus. Un include vers un domaine sans SPF est une erreur distincte, plus stricte : il fait échouer l’enregistrement dès le premier, donc retirez-le ou remplacez-le par l’include que le fournisseur documente aujourd’hui.

`No SPF record found`

Pourquoi. Aucun enregistrement TXT commençant par v=spf1 sur le domaine lui-même : il a été publié sur www, dans une autre zone, ou jamais.

Correction. Publiez un seul enregistrement TXT sur le domaine (nommé @ dans la plupart des interfaces DNS). Un domaine qui n’envoie jamais d’e-mails publie v=spf1 -all.

Questions

Combien de requêtes DNS SPF autorise-t-il ?

10, comptées sur tout l’enregistrement avec chaque include imbriqué (RFC 7208, section 4.6.4). ip4, ip6 et all ne coûtent rien. Au-delà de 10, le résultat est une erreur permanente, et plus de deux requêtes qui ne renvoient rien font aussi échouer SPF.

Mon SPF doit-il finir par ~all ou -all ?

Avec DMARC en quarantine ou reject, ~all suffit et ménage les e-mails transférés : DMARC tranche. Sans DMARC, -all est la seule fin qui fait refuser les e-mails falsifiés. Jamais +all, et ?all revient à ne pas avoir de SPF.

Puis-je « aplatir » mon SPF pour passer sous 10 requêtes ?

Remplacer les includes par les adresses qu’ils contiennent aujourd’hui fait baisser le compte, mais les fournisseurs changent leurs adresses sans prévenir et un enregistrement aplati se périme sans bruit. N’aplatissez que ce qu’un fournisseur documente comme fixe.

SPF protège-t-il l’adresse From que l’on voit ?

Non. SPF vérifie l’expéditeur de l’enveloppe (le Return-Path), pas la ligne From. Seul DMARC relie SPF ou DKIM au From visible : c’est pourquoi SPF seul n’empêche pas l’usurpation.

Les requêtes passent-elles par vos serveurs ?

Non. Le vérificateur fonctionne dans votre navigateur et interroge des résolveurs DNS-over-HTTPS publics (Cloudflare, puis Google). Rien ne nous est envoyé ni conservé.