Saisissez n'importe quel domaine pour récupérer et valider son enregistrement SPF. Consultez la valeur complète de l'enregistrement, chaque mécanisme expliqué, et si la configuration est correcte.
Un enregistrement SPF (Sender Policy Framework) est un enregistrement DNS TXT qui autorise des serveurs de messagerie spécifiques à envoyer des e-mails au nom d'un domaine. C'est l'un des trois protocoles fondamentaux d'authentification des e-mails, aux côtés de DKIM et DMARC. Lorsqu'un message arrive, le serveur de messagerie destinataire interroge l'enregistrement SPF du domaine d'envoi pour vérifier que l'adresse IP d'expédition est autorisée.
Le SPF est fondamental pour la délivrabilité des e-mails. Sans enregistrement SPF valide, les e-mails de votre domaine ont plus de chances d'être marqués comme spam ou entièrement rejetés. La plupart des grands fournisseurs de boîtes de réception — Gmail, Outlook, Yahoo — considèrent les résultats SPF comme un signal de confiance principal. Google et Yahoo exigent désormais le SPF dans leurs exigences pour les expéditeurs en volume.
Un enregistrement SPF utilise un ensemble de mécanismes pour décrire les expéditeurs autorisés. Les mécanismes courants incluent ip4 et ip6 (adresses IP ou plages spécifiques), mx (les serveurs de messagerie du domaine) et include (délégation à l'enregistrement SPF d'un autre domaine). L'enregistrement se termine par un mécanisme all qui définit quoi faire des expéditeurs non listés explicitement : ~all (softfail), -all (hardfail) ou ?all (neutral).
Autorise une adresse IPv4 ou une plage CIDR spécifique. Exemple : ip4:203.0.113.1 ou ip4:203.0.113.0/24.
Autorise une adresse ou une plage IPv6 spécifique. Exemple : ip6:2001:db8::1.
Autorise les serveurs de messagerie listés dans les enregistrements MX du domaine. Utile lorsque vos serveurs de messagerie sortants et entrants sont les mêmes.
Importe et évalue l'enregistrement SPF d'un autre domaine. Utilisé pour autoriser des expéditeurs tiers comme Google Workspace ou SendGrid.
Autorise les adresses IP des enregistrements A ou AAAA du domaine. Utile pour les serveurs web qui envoient aussi du courrier.
Un Catch-All qui s'applique aux expéditeurs non couverts par les autres mécanismes. Préfixé par ~(softfail), -(hardfail) ou ?(neutral).
Preuves DNS en direct
Le vérificateur SPF récupère la politique TXT publique et expose les règles d'autorisation que les destinataires peuvent évaluer. C'est un diagnostic de configuration, pas une garantie que chaque message réel passera.
Un domaine sans politique SPF ne fournit aucune preuve d'autorisation SPF. Un domaine avec plusieurs enregistrements TXT v=spf1 produit une erreur SPF permanente plutôt que de les combiner automatiquement.
Lisez l'enregistrement renvoyé exactement tel que le DNS le publie. D'anciens include de fournisseurs, des espaces accidentels et une politique placée sur le mauvais sous-domaine peuvent tous modifier le résultat.
ip4 et ip6 identifient les réseaux directement. include, a, mx, exists et redirect peuvent déclencher des consultations DNS supplémentaires et peuvent dépendre d'enregistrements contrôlés par un autre fournisseur.
Une politique peut être syntaxiquement valide tout en autorisant les mauvais systèmes. Comparez chaque mécanisme à l'inventaire actuel des expéditeurs plutôt que de traiter une analyse au vert comme une validation de la configuration métier.
Lire la politique
La question utile n'est pas seulement de savoir si un enregistrement existe. C'est de savoir si l'enregistrement peut être évalué et si sa frontière d'autorisation correspond à votre flux de messagerie réel.
Le SPF évalue le domaine utilisé dans MAIL FROM ou HELO, pas nécessairement l'en-tête From visible. Une source qui passe peut donc être techniquement autorisée tout en échouant à l'alignement DMARC avec l'adresse que le destinataire voit.
~all et -all communiquent une force de politique différente pour les sources non correspondantes. ?all n'énonce aucune assertion positive. Une syntaxe invalide, des politiques en double ou une évaluation DNS excessive peuvent produire un permerror et doivent être corrigés plutôt qu'interprétés comme un échec ordinaire.
Comptez les mécanismes déclenchant des consultations DNS sur toute la chaîne d'include. L'enregistrement de premier niveau peut ne contenir que deux include alors que ces fournisseurs se déploient en assez d'opérations a, mx, include, exists ou redirect pour dépasser la limite RFC.
+all autorise tous les expéditeurs. De larges plages d'IP ou des include inutiles peuvent aussi faciliter l'usurpation. Un vérificateur SPF devrait vous aider à restreindre l'autorisation, pas seulement confirmer qu'une chaîne TXT commence par v=spf1.
Flux de diagnostic
Un contrôle discipliné relie la politique publiée aux identités d'envoi réelles.
Inspectez un message réellement envoyé ou les paramètres du fournisseur pour trouver le domaine return-path, puis interrogez ce domaine plutôt que de supposer que la racine organisationnelle est évaluée.
Identifiez le propriétaire de chaque autorisation include, plage d'IP, a et mx. Ne retirez les sources obsolètes qu'après avoir confirmé qu'elles n'envoient plus de courrier légitime.
Envoyez via chaque plateforme de production et inspectez spf=, smtp.mailfrom et l'alignement DMARC dans les en-têtes reçus. Cela détecte les décalages d'identité qu'une simple recherche DNS ne peut pas observer.
Si l'enregistrement est manquant ou structurellement incorrect, utilisez le Générateur d'enregistrement SPF pour rédiger une politique unique combinée, publiez-la, puis relancez ce vérificateur après expiration des caches DNS.
Limites des résultats
Le SPF est un signal au niveau du domaine. Il ne peut pas, à lui seul, répondre aux questions relatives aux destinataires, au contenu ou à l'authentification complète.
Le DMARC exige une identité SPF ou DKIM alignée. Un domaine return-path distinct peut passer le SPF alors que le domaine From visible reste non protégé.
Utilisez le Vérificateur DKIM et le Vérificateur DMARC pour ces enregistrements DNS et politiques distincts.
Les destinataires combinent l'authentification avec la réputation d'envoi, les taux de plaintes, le contenu, l'engagement et leurs propres filtres. Un passage SPF est une preuve nécessaire pour de nombreux expéditeurs, pas une garantie de boîte de réception.
L'enregistrement décrit qui peut envoyer pour un domaine. Utilisez le Vérificateur d'e-mails pour vérifier si une adresse de destination peut recevoir du courrier.
Référence du protocole
Les tableaux de bord des fournisseurs simplifient le SPF, mais les destinataires évaluent la politique publiée selon le protocole.
Le document RFC 7208 de l'IETF définit les identités SPF, les enregistrements TXT, les mécanismes, les qualificatifs, les limites DNS et les codes de résultat. C'est la référence officielle pour les enregistrements en double et le comportement permerror.
Après avoir corrigé le SPF, ajoutez la signature des messages avec le Générateur DKIM et publiez une politique alignée avec le Générateur DMARC.
Choisissez l'outil suivant selon le type de preuve : destinataire, découverte, DNS et infrastructure, ou workflow d'expéditeur.
Outils gratuits
Générez un enregistrement DNS SPF valide en quelques secondes. Ajoutez des serveurs, des directives include et votre politique. Gratuit, sans inscription.
Preuve de domaine ou d'infrastructure — pas une preuve de boîte.
Outils gratuits
Vérifiez l'enregistrement DKIM de tout domaine et sélecteur. Consultez la clé publique et confirmez la configuration de la signature. Gratuit, sans inscription.
Preuve de domaine ou d'infrastructure — pas une preuve de boîte.
Outils gratuits
Vérifiez l'enregistrement DMARC de tout domaine : politique, alignement, adresses de rapport et configuration. Gratuit, sans inscription.
Preuve de domaine ou d'infrastructure — pas une preuve de boîte.
Outils gratuits
Vérifiez les enregistrements A, AAAA, MX, TXT, NS ou CNAME de tout domaine. Consultation DNS en direct, résultats instantanés. Gratuit, sans inscription.
Preuve de domaine ou d'infrastructure — pas une preuve de boîte.
Outils email
Testez la délivrabilité d'un vrai email. Analysez SPF, DKIM, DMARC, DNS, listes noires, filtres anti-spam, en-têtes et contenu.
Diagnostic d'expéditeur ou de message — pas une découverte d'adresses.
Outils de vérification d'email
Vérifiez si une adresse e-mail est valide avec un email verifier gratuit qui exécute syntaxe, MX, SMTP de boîte, jetable, rôle et catch-all.
Preuve destinataire — pas la configuration de l'expéditeur ni du DNS.
Un domaine sans enregistrement SPF échoue aux contrôles SPF. Les serveurs destinataires traitent cela comme un résultat neutre, mais combiné à d'autres signaux, cela augmente la probabilité de spam. Google et Yahoo exigent désormais des enregistrements SPF pour tous les expéditeurs en volume. Tout domaine qui envoie des e-mails devrait publier un enregistrement SPF.
Avoir deux enregistrements TXT ou plus commençant par v=spf1 sur le même domaine provoque une erreur permanente SPF (permerror). L'évaluation SPF échoue entièrement et tous les e-mails de ce domaine échoueront au SPF. Vous devez regrouper toutes les règles dans un seul enregistrement SPF.
Un échec SPF signifie que l'adresse IP d'envoi n'est pas autorisée dans l'enregistrement SPF du domaine. Le résultat dépend du mécanisme all : ~all provoque un softfail (suspect, mais généralement encore délivré), tandis que -all provoque un hardfail (généralement rejeté ou envoyé en spam). Un résultat neutre ?all n'a d'effet ni dans un sens ni dans l'autre.
Un permerror (erreur permanente) survient lorsque le SPF ne peut pas être évalué à cause d'un problème de configuration — le plus souvent parce que le domaine a plus d'un enregistrement SPF, ou que l'enregistrement contient trop de mécanismes de consultation DNS (plus de 10). Corrigez les permerrors immédiatement, car ils font échouer le SPF pour tous les e-mails de votre domaine.
Le SPF autorise un maximum de 10 consultations DNS pendant l'évaluation. Chaque mécanisme include, a, mx, ptr et exists compte pour une consultation, et les include imbriqués dans ceux-ci comptent également. Dépasser 10 consultations au total entraîne un permerror.
Si votre enregistrement SPF approche la limite de 10 consultations, envisagez l'aplatissement SPF — résoudre tous les include vers leurs adresses IP réelles et remplacer les mécanismes include par des entrées ip4/ip6 directes. Cela réduit le nombre de consultations à zéro pour ces entrées, mais vous devrez mettre à jour l'enregistrement chaque fois que votre fournisseur modifie ses plages d'IP.
Le SPF est la première étape. Associez-le à DKIM et DMARC pour protéger pleinement votre domaine. Puis gardez votre liste propre avec la vérification d'e-mails BillionVerify.
600 crédits gratuits/mois + 20/jour de connexion · Précision SMTP de 99,9% · Accès API immédiat · Sans carte bancaire
