Compte chaque requête DNS de l'enregistrement

Outil gratuit

Vérificateur SPF

Vérifiez l'enregistrement SPF de tout domaine et sa marge avant la limite de requêtes

Vérification SPF gratuite pour tout domaine. Nous résolvons l'enregistrement complet depuis votre navigateur, suivons chaque include et chaque redirect comme le ferait un serveur de réception, et affichons le nombre de requêtes DNS sur 10, les requêtes vides, la politique par défaut et chaque plage d'adresses IP que l'enregistrement autorise.

Saisissez un domaine. Aucun compte ni accès à son DNS n'est nécessaire.

La vérification s'exécute dans votre navigateur via DNS-over-HTTPS : l'enregistrement SPF vous parvient sans transiter par nos serveurs. Nous recevons le nom de chaque domaine vérifié, et ce nom déclenche une vérification indépendante depuis nos propres serveurs, dont nous conservons le résultat, y compris l'enregistrement SPF lui-même, afin de maintenir à jour notre index public de domaines.

Comment utiliser ce vérificateur SPF

Trois étapes pour passer d'un nom de domaine à une réponse fiable sur sa configuration SPF.

  1. 1

    Saisissez un domaine

    Tapez n'importe quel domaine dans le formulaire ci-dessus. Vous n'avez besoin ni d'en être titulaire ni d'avoir accès à son DNS.

  2. 2

    Nous résolvons l'enregistrement complet

    Votre navigateur interroge les enregistrements TXT du domaine via DNS-over-HTTPS, puis suit chaque terme include, redirect, a, mx et exists rencontré, exactement comme le ferait un serveur de réception.

  3. 3

    Lisez le compteur et le verdict

    Vous obtenez le total des requêtes DNS sur 10, le total des requêtes vides sur 2, la politique par défaut issue du mécanisme all, chaque erreur de syntaxe et chaque plage d'adresses IP autorisée, groupée par include d'origine.

Ce qu'une vérification SPF vous apprend

Un enregistrement SPF peut être syntaxiquement correct et échouer malgré tout en production. Utilisez cette vérification pour :

  • Confirmer qu'un nouvel expéditeur a bien été ajouté après avoir connecté Google Workspace, Microsoft 365, SendGrid ou Mailchimp.
  • Mesurer la marge restante avant la limite de 10 requêtes, avant d'ajouter un include de plus.
  • Diagnostiquer un permerror qui fait échouer DMARC alors que les emails sont légitimes.
  • Repérer une requête vide laissée par un hôte mis hors service ou un prestataire résilié.
  • Vérifier si l'enregistrement se termine par -all, ~all, ?all, ou par rien du tout.
  • Auditer le SPF d'un fournisseur ou d'un domaine racheté avant de le laisser envoyer en votre nom.

Comprendre le SPF

La limite de 10 requêtes DNS

La section 4.6.4 du RFC 7208 impose aux destinataires d'arrêter après 10 termes provoquant une requête DNS au cours d'une même évaluation SPF. Ces termes sont les mécanismes include, a, mx, ptr et exists, ainsi que le modificateur redirect. Les mécanismes ip4, ip6 et all ne coûtent rien, et le modificateur exp est exempté car sa requête intervient une fois l'évaluation terminée. Franchir la limite donne un permerror, que les destinataires traitent comme un échec SPF pour chaque message envoyé par le domaine. Le comptage est récursif : chaque include ajoute les requêtes de l'enregistrement qu'il désigne, si bien que quatre include peuvent facilement en coûter quinze.

Les requêtes vides, et pourquoi le plafond est à deux

Une requête vide est une requête DNS effectuée pendant l'évaluation SPF qui ne renvoie rien : soit NXDOMAIN, soit NOERROR avec une section de réponse vide. La section 4.6.4 du RFC 7208 indique que les implémentations devraient limiter les requêtes vides à deux et recommande deux par défaut ; au-delà, le résultat est permerror. Les requêtes vides méritent d'être corrigées même quand le total des requêtes reste confortable, car chacune signifie que l'enregistrement désigne encore un hôte ou un include mis hors service.

-all, ~all, ?all et +all

Le mécanisme all se place à la fin d'un enregistrement et correspond à tout expéditeur qu'aucun terme précédent n'a fait correspondre (RFC 7208, section 5.1). Son qualificateur décide du verdict. -all signifie fail : une déclaration explicite que l'expéditeur n'est pas autorisé. ~all signifie softfail : le domaine indique que l'expéditeur n'est probablement pas autorisé sans aller jusqu'à l'affirmer, et demande aux destinataires de ne pas rejeter sur cette seule base. ?all est neutre, ce que la section 8.2 impose de traiter exactement comme l'absence totale d'enregistrement. +all autorise tous les hôtes d'Internet et annule l'intérêt même de publier un SPF. Un enregistrement sans mécanisme all ni redirect se termine lui aussi en neutre. Visez -all dès que vos rapports DMARC montrent que tous vos expéditeurs légitimes sont couverts.

Les macros SPF

Les macros (RFC 7208, section 7) permettent à un enregistrement de construire le nom DNS qu'il interroge à partir du message vérifié, sous la forme d'un signe pourcent et d'une lettre entre accolades. La macro i correspond à l'adresse IP émettrice, s à l'adresse MAIL FROM complète, l à sa partie locale, o et d à des noms de domaine, et h au nom HELO. Les grandes plateformes les associent au mécanisme exists pour qu'un seul enregistrement réponde par client ou par adresse IP, sans publier des milliers d'enregistrements. Les macros sont légitimes et cet outil résout ce qu'il peut, mais une macro signifie que la vraie réponse dépend du message : aucune vérification statique ne peut la prédire entièrement. La macro à éviter est p : elle force une résolution DNS inverse, la raison même pour laquelle la section 5.5 du RFC 7208 déconseille le mécanisme ptr.

Le flattening SPF

Le flattening remplace les termes include, a et mx par les plages ip4 et ip6 vers lesquelles ils se résolvent à l'instant T. Recopié à la main, l'enregistrement obtenu ne coûte aucune requête DNS ; un service géré le publie derrière un unique include hébergé, soit une seule requête. Dans les deux cas, c'est le seul moyen fiable de ramener sous la limite de 10 un enregistrement comptant de nombreux expéditeurs. La contrepartie : il fige un instantané. Quand un fournisseur change les plages derrière son include, un enregistrement aplati à la main continue d'autoriser les anciennes et se met à faire échouer des emails que vous avez réellement envoyés. Le flattening n'est donc sûr que si un mécanisme le résout de nouveau à intervalle régulier. Les enregistrements aplatis sont aussi longs, et un enregistrement TXT de plus de 255 caractères doit être publié en plusieurs chaînes que les destinataires recollent (RFC 7208, section 3.3).

Questions fréquentes

Qu'est-ce qu'un enregistrement SPF ?
SPF (Sender Policy Framework, RFC 7208) est un enregistrement TXT publié dans le DNS d'un domaine, qui liste les serveurs autorisés à envoyer des emails utilisant ce domaine dans l'adresse SMTP MAIL FROM. Le serveur destinataire lit l'enregistrement, le compare à l'adresse IP qui se connecte, puis renvoie pass, fail, softfail, neutral, none, temperror ou permerror. DMARC s'appuie ensuite sur ce résultat, à condition que le domaine du MAIL FROM soit aligné avec celui de l'en-tête From visible.
Qu'est-ce que la limite de 10 requêtes DNS du SPF ?
La section 4.6.4 du RFC 7208 impose aux destinataires d'arrêter après 10 termes déclenchant une requête DNS lors de l'évaluation d'un enregistrement SPF. Les mécanismes include, a, mx, ptr et exists ainsi que le modificateur redirect comptent tous ; ip4, ip6 et all ne coûtent rien. La limite est récursive : chaque include apporte aussi les requêtes de l'enregistrement qu'il désigne. C'est pourquoi un enregistrement comptant seulement quatre ou cinq include dépasse régulièrement la limite.
Que se passe-t-il quand un enregistrement SPF dépasse 10 requêtes ?
Le destinataire arrête l'évaluation et renvoie permerror, traité comme un échec SPF pour chaque message, y compris ceux envoyés par vos propres serveurs. Si ces messages ne portent pas non plus de signature DKIM alignée, DMARC échoue aussi et l'email peut être mis en quarantaine ou rejeté. La panne est silencieuse côté expéditeur : rien ne change dans votre DNS, l'enregistrement peut donc franchir la limite le jour où un fournisseur ajoute une plage à son propre include.
Qu'est-ce qu'une requête vide en SPF ?
Une requête vide est une requête DNS effectuée pendant l'évaluation SPF qui ne renvoie rien : soit NXDOMAIN, soit une réponse NOERROR sans enregistrement. La section 4.6.4 du RFC 7208 indique que les implémentations devraient limiter les requêtes vides à deux et recommande deux par défaut ; au-delà, le résultat est permerror. En pratique, une requête vide signifie que l'enregistrement désigne encore un hôte ou un include qui n'existe plus.
Mon enregistrement SPF doit-il se terminer par -all ou par ~all ?
-all (fail) est l'état final. Il indique aux destinataires que l'expéditeur n'est pas autorisé, et c'est ce qui donne au SPF un pouvoir de restriction réel. ~all (softfail) est un qualificateur de transition : le domaine indique que l'expéditeur n'est probablement pas autorisé, mais demande aux destinataires de ne pas rejeter sur cette seule base. Commencez par ~all, le temps de confirmer via vos rapports DMARC que tous vos expéditeurs légitimes sont couverts, puis passez à -all. ?all est neutre et, selon la section 8.2 du RFC 7208, doit être traité exactement comme si aucun enregistrement n'existait.
Qu'est-ce que le flattening SPF, et est-ce sans risque ?
Le flattening remplace les termes include, a et mx par les plages ip4 et ip6 vers lesquelles ils se résolvent à l'instant T. Recopié à la main, l'enregistrement obtenu ne coûte aucune requête DNS ; un service géré le publie derrière un unique include hébergé, soit une seule requête. C'est le seul moyen fiable de ramener sous la limite de 10 un enregistrement comptant de nombreux expéditeurs. Fait une seule fois à la main, il est dangereux : l'enregistrement fige un instantané et continue d'autoriser d'anciennes plages après qu'un fournisseur a changé les siennes. Il n'est sûr que si un mécanisme le résout de nouveau et le republie à intervalle régulier.
Ce vérificateur SPF est-il gratuit ?
Oui, et aucune inscription n'est nécessaire. La recherche s'exécute dans votre navigateur via des résolveurs DNS-over-HTTPS publics : l'enregistrement SPF vous parvient donc sans transiter par nos serveurs. Nous recevons en revanche le nom de chaque domaine vérifié. Ce nom déclenche une vérification indépendante depuis nos propres serveurs, dont nous conservons le résultat, y compris l'enregistrement SPF lui-même, afin de maintenir à jour notre index public de domaines. Un enregistrement SPF est une donnée DNS publique, interrogeable par n'importe qui.