Aller au contenu

Vérifiez votre SPF, validateur gratuit

Cherchez le SPF de tout domaine pour trouver et tester l’enregistrement publié, valider sa syntaxe, suivre les includes et compter les requêtes DNS. Gratuit, sans compte.

SPF : définition

SPF (Sender Policy Framework) est une méthode d’authentification e-mail par DNS qui liste les systèmes autorisés à utiliser un domaine comme expéditeur SMTP de l’enveloppe. Un test public montre la politique qu’un destinataire peut trouver, pas qu’un e-mail précis a passé SPF ni que le domaine authentifié s’alignait pour DMARC.

Lire votre résultat SPF

RésultatSignificationQue faire
SPF valideLe test a trouvé une politique SPF lisible pour le domaine saisi.Vérifiez que chaque mécanisme vise un expéditeur actif, et testez un vrai e-mail à part.
Pas de SPFAucune politique v=spf1 sur le domaine exact saisi.Confirmez le domaine MAIL FROM, puis publiez le SPF fourni par les systèmes qui envoient vraiment.
Plusieurs SPFPlusieurs politiques v=spf1 sur le même nom, d’où une erreur permanente.Recensez chaque expéditeur autorisé et regroupez les mécanismes en une politique.
9 ou 10 requêtes DNSLe SPF est au plafond RFC 7208 ou presque, sans marge pour un changement chez un fournisseur.Retirez les anciens expéditeurs et suivez la chaîne d’includes avant qu’elle tourne en permerror.
PermError ou plus de 10La politique n’est pas évaluable de façon fiable : syntaxe, doublons, dépendances cassées ou trop de requêtes DNS.Corrigez la cause signalée et retestez ; réessayer l’envoi ne répare pas une erreur permanente.
~all ou -allSoftfail et fail disent des choses différentes sur l’autorisation, mais le destinataire décide du traitement final.Recensez chaque expéditeur légitime avant de durcir le qualificateur, puis validez courrier réel et alignement DMARC.

Bien tester SPF

  1. 1. Trouvez le domaine évalué par SPF. Ouvrez les en-têtes complets d’un e-mail reçu et trouvez l’identité smtp.mailfrom ajoutée par le destinataire près du résultat SPF. Un return path du fournisseur ou un sous-domaine dédié peut différer du From visible.
  2. 2. Saisissez ce domaine exact. Saisissez seulement le domaine, sans boîte, protocole ni chemin. Sans e-mail sous la main, prenez le domaine des consignes actuelles du fournisseur et voyez le résultat comme une preuve de configuration, pas un test d’e-mail réel.
  3. 3. Lisez les mécanismes dans l’ordre. Examinez ip4, ip6, a, mx, include, exists, all, et tout redirect. Un include lance une autre politique, pas un simple nom d’expéditeur.
  4. 4. Suivez les requêtes imbriquées. RFC 7208 admet au plus dix termes à requête DNS sur toute l’évaluation. Les termes imbriqués puisent dans le même budget : compter les seuls includes visibles ne suffit pas.

Ce que ce test peut prouver

Le test prouve ce que le DNS public renvoie pour le nom saisi, si une politique SPF est lisible et comment ses mécanismes visibles et imbriqués usent le budget de requêtes DNS. Son interprétation suit RFC 7208. Il ne voit pas votre inventaire privé, ignore l’identité évaluée sauf si vous la donnez et ne garantit pas la boîte de réception.

Pour Google Workspace, prenez l’identité MAIL FROM du domaine personnalisé dans l’en-tête fiable. Le guide de dépannage SPF de Google sépare lui aussi le test DNS public du résultat réel du message.

Corrigez, puis retestez le message

Recensez d’abord messagerie, plateformes marketing, systèmes transactionnels, ticketing, facturation et appareils. Retirez les anciens expéditeurs avant d’ajouter des mécanismes ou d’aplatir les includes. Pour un SPF hors limite, suivez la procédure de réparation PermError et nommez un responsable pour chaque dépendance.

Quand le DNS faisant autorité sert le changement, relancez ce test. Envoyez ensuite un nouvel e-mail par chaque chemin modifié et vérifiez identité évaluée, IP de connexion, résultat SPF et domaine From visible dans un en-tête Authentication-Results fiable. Testez DMARC à part : un SPF qui passe sur un return path non aligné ne donne pas un DMARC aligné.

Tests et correctifs SPF liés

SPF : définitionGénérateur SPFTrop de requêtes DNSSyntaxe SPFTest DMARCScore de sécurité e-mail

Base de connaissances e-mail

Un test SPF peut-il tester un e-mail précis ?

Non. Un test SPF par domaine lit la politique DNS publique. Pour vérifier un e-mail précis, lisez l’en-tête Authentication-Results fiable ajouté par le destinataire : identité smtp.mailfrom, IP de connexion et résultat SPF.

Tester le domaine racine ou un sous-domaine ?

Testez l’identité MAIL FROM ou HELO exacte du chemin d’envoi. Un sous-domaine de return path peut publier un SPF différent du domaine organisationnel : la racine n’est donc pas toujours la bonne cible.

Un SPF valide fait-il passer DMARC ?

Non. DMARC exige que le domaine authentifié par SPF s’aligne sur le From visible, ou qu’une signature DKIM alignée passe. Un SPF public valide ne prouve pas seul l’alignement SPF ou DMARC d’un e-mail.

L’aplatissement SPF règle-t-il toujours l’excès de requêtes ?

Non. Retirez d’abord les anciens expéditeurs et clarifiez qui gère quoi. L’aplatissement copie les plages IP des fournisseurs, qui vieillissent quand elles changent : il faut un suivi fiable et un responsable des mises à jour.

Quels termes SPF comptent dans la limite de dix ?

Les mécanismes include, a, mx, ptr et exists et le modificateur redirect coûtent des requêtes DNS. Les termes imbriqués puisent dans le même budget. Les mécanismes ip4, ip6 et all et le modificateur exp ne comptent pas.