Outils populaires

Thème

Test SPF — Vérifier un enregistrement SPF

Ce vérificateur SPF lit l'enregistrement de n'importe quel domaine comme le font les serveurs de messagerie destinataires : chaque include avec le coût de sa propre requête DNS, le total cumulé face à la limite de 10, les requêtes vides, et le résultat pour toute IP d'envoi, avec le terme qui a décidé.

Sources : les enregistrements TXT du domaine et chaque include, via Google Public DNS (Cloudflare 1.1.1.1 derrière) · check_host de la RFC 7208, exécuté sur notre serveur · rien n'est conservé

Exactement le nom saisi : le SPF n'a pas d'héritage, donc mail.example.com a besoin de son propre enregistrement.

Essayez

Qu'est-ce qu'un enregistrement SPF ?

Un enregistrement SPF est un enregistrement TXT qui liste les serveurs autorisés à envoyer des e-mails pour un domaine. Il commence par v=spf1, nomme les expéditeurs terme par terme, et se termine par ce que les destinataires doivent penser de tous les autres (RFC 7208, avril 2014, toujours la norme en vigueur).

Les destinataires le comparent à l'adresse du serveur qui se connecte et au domaine de l'expéditeur d'enveloppe, le MAIL FROM ou Return-Path, pas à la ligne From: qu'un lecteur voit. Relier le SPF à From:, c'est le travail de DMARC.

Un enregistrement ne couvre que le nom exact où il se trouve : le SPF n'a pas d'héritage, donc mail.example.com a besoin de son propre enregistrement. Un domaine qui n'envoie aucun e-mail devrait publier v=spf1 -all.

Un enregistrement SPF, terme par termegoogle.com · TXT · relevé le 24 octobre 2026 · TTL 5 minutes
v=spf1Versioninclude:_spf.google.comMécanisme · 1 requête~allQualificateur ~ · mécanisme all

L'include pointe vers _spf.google.com · 8 plages, aucune requête de plus

ip4:74.125.0.0/16ip4:209.85.128.0/17ip6:2001:4860:4864::/56ip6:2404:6800:4864::/56ip6:2607:f8b0:4864::/56ip6:2800:3f0:4864::/56ip6:2a00:1450:4864::/56ip6:2c0f:fb50:4864::/56~all

VersionExactement v=spf1, en premier : un enregistrement qui commence autrement n'est pas un enregistrement SPF.
Mécanismesinclude, a, mx, ip4, ip6, exists, ptr et all, essayés de gauche à droite : la première correspondance décide.
Qualificateurs+ pass (par défaut), - fail, ~ softfail, ? neutral, écrits devant un mécanisme.
Modificateursredirect= confie la vérification à un autre enregistrement ; exp= explique un fail.
L'enregistrement entier de google.com tient en trois termes : un destinataire récupère l'include, compare l'IP d'envoi à ses plages, ou arrive à ~all. Relevé via Google Public DNS le 24 octobre 2026.

Comment vérifier un enregistrement SPF

Saisissez un domaine ci-dessus : le vérificateur lit ses enregistrements TXT, retient celui qui commence par v=spf1, puis suit chaque include et chaque redirect comme le ferait un serveur destinataire, en comptant chaque requête DNS au passage.

À la main, demandez les enregistrements TXT : dig TXT example.com +short ou nslookup -type=TXT example.com. La réponse contient chaque enregistrement TXT à ce nom ; l'enregistrement SPF est celui qui commence par v=spf1, et un long enregistrement arrive en plusieurs chaînes entre guillemets que le SPF joint sans espace. Chaque include est une requête de plus, et il vous faudrait les compter vous-même.

Pour savoir si un serveur précis peut envoyer, passez à Tester une IP : le test exécute la même vérification pour cette adresse et montre le terme qui a correspondu.

dig TXT example.com +short

Chaque enregistrement TXT à ce nom, tel que votre résolveur l'a ; l'enregistrement SPF est celui qui commence par v=spf1. Relancez la commande pour chaque include.

Ce que montre dig, et ce qu'il ne montre pasgithub.com · dig TXT · relevé le 24 octobre 2026
console1 enregistrement TXT sur 24
$ dig TXT github.com @dns1.p08.nsone.net +norec +noall +answer
github.com.  300  IN  TXT  "v=spf1 ip4:192.30.252.0/22 include:spf.protection.outlook.com include:_netblocks.google.com include:_netblocks2.google.com include:mail.zendesk.com include:_spf.salesforce.com include:servers.mcsv.net include:mktomail.com include:sendgrid.net ip4:62.253.2" "27.114 ip4:166.78.69.169 ip4:166.78.69.170 ip4:166.78.71.131 ~all"

# puis chaque include, une requête à la fois :
$ dig +short TXT _spf.salesforce.com
"v=spf1 exists:%{i}._spf.mta.salesforce.com -all"
  1. Un enregistrement commence par v=spf1. Les 23 autres enregistrements TXT à côté (jetons de vérification et autres) n'ont pas d'importance pour le SPF, sauf pour la taille de la réponse.
  2. 2 chaînes, jointes sans espace. La coupure à 255 octets tombe dans ip4:62.253.227.114 : les destinataires rejoignent les chaînes, donc ce n'est pas un problème.
  3. TTL 5 minutes. La durée pendant laquelle les résolveurs peuvent garder cette copie après un changement. Le serveur de la zone indique 5 minutes ; un résolveur montre ce qui reste de sa copie.
  4. Chaque include est sa propre requête. Suivre l'enregistrement de github.com demande 10 requêtes, imbriqués compris. dig montre un nom à la fois : le décompte jusqu'à 10 est à faire vous-même.
Windows
$ nslookup -type=TXT github.com 8.8.8.8
PowerShell
# chaque enregistrement TXT à ce nom, depuis Google Public DNS
PS> Resolve-DnsName -Name github.com -Type TXT -Server 8.8.8.8
Cette page
/fr/spf-checker?domain=github.com
La réponse TXT de github.com depuis son propre serveur de noms : l'enregistrement SPF arrive en deux chaînes, jointes sans espace, parmi les autres enregistrements TXT du domaine.

Lire le résultat : l'arbre des includes

Le verdict dit ce que les destinataires obtiennent pour un expéditeur que l'enregistrement ne liste pas : valide avec sa terminaison (softfail pour ~all, fail pour -all), ou un permerror avec sa cause, ou « vérification impossible » quand le DNS n'a pas répondu.

La colonne marine est le budget de requêtes : une cellule par requête DNS, colorée selon l'include qui la dépense, le total cumulé face à 10, et les requêtes vides en anneaux. Après la 10e, les cellules deviennent rouges et la branche où les destinataires s'arrêtent est marquée.

La vue Arbre liste les constats, échecs en premier, chacun avec sa section de RFC et la correction, puis chaque requête dans l'ordre où un destinataire la pose.

Test SPF de github.com : 10 requêtes DNS sur 10, une requête vide, le coût de chaque include dans le budget de requêtesTest SPF de github.com : 10 requêtes DNS sur 10, une requête vide, le coût de chaque include dans le budget de requêtesLe verdictCe que les destinataires obtiennent pour un expéditeur que l'enregistrement ne liste pas, et la terminaison qui en décide.L'enregistrement, terme par termeChaque terme coloré selon son type ; un include porte la marque de son propriétaire et son propre coût en requêtes.Les constatsUn enregistrement, syntaxe valide, requêtes, requêtes vides, la terminaison, ptr, DMARC : échecs en premier, chacun avec sa correction.Le budget de requêtesChaque requête DNS en cellule, colorée selon l'include qui la dépense, face à la limite de 10.Le coût de chaque includeUne branche par include : ses propres cellules, ce qu'il imbrique et le total cumulé.Les requêtes videsDes anneaux pour les requêtes revenues vides ; la troisième met fin à la vérification.
Un test SPF de github.com : le verdict, l'enregistrement découpé en termes, les constats et le budget de requêtes avec le coût propre de chaque include. Sélectionnez un numéro pour voir ce que montre chaque partie.

La limite de 10 requêtes et « too many DNS lookups » (permerror)

Les destinataires comptent chaque terme qui exige une requête DNS, include, a, mx, ptr, exists et redirect, à travers chaque include imbriqué, et s'arrêtent à 10. La 11e donne permerror (RFC 7208 §4.6.4). ip4, ip6, all et exp ne coûtent rien.

C'est un permerror, pas un fail : ce qu'un destinataire en fait est son propre choix, mais sous DMARC un permerror ne compte jamais comme un pass. Et comme la vérification s'arrête à la première correspondance, un enregistrement au-delà de la limite passe encore pour les expéditeurs listés tôt et ne casse que pour ceux listés tard.

Le coût se cache dans les includes : include:_netblocks.mimecast.com en dépense 9 à lui seul, celui de Yandex 360 en dépense 8, celui de Freshdesk 7, celui de Mailgun 5. Les includes de Google et de Microsoft 365 coûtent 1 chacun. Pour passer sous 10, retirez les expéditeurs que vous n'utilisez plus et déplacez un expéditeur en masse vers un sous-domaine avec son propre enregistrement.

Qui dépense les 10 requêtesCoûts mesurés le 24 octobre 2026 · un enregistrement inventé d'includes réels

v=spf1 include:spf.protection.outlook.com include:_netblocks.mimecast.com include:mailgun.org include:sendgrid.net -all

17 requêtes nécessaires
Listé dans les 10 premières requêtes : passMicrosoft 3651Mimecast2–10
Listé après la requête 10 : permerrorMailgun11–15Twilio SendGrid16–17

Tous les autres obtiennent aussi permerror, pas le fail du -all de l'enregistrement : les destinataires s'arrêtent avant de l'atteindre.

Ce que coûte un includeL'include documenté par chaque fournisseur · mesuré le 24 octobre 2026
  • _netblocks.mimecast.comMimecast9 requêtes
  • _spf.yandex.netYandex 3608 requêtes
  • email.freshdesk.comFreshdesk7 requêtes
  • mailgun.orgMailgun5 requêtes
  • icloud.comiCloud+5 requêtes
  • spf.titan.emailTitan Email4 requêtes
  • secureserver.netGoDaddy3 requêtes
  • _spf.google.comGoogle Workspace1 requête
  • spf.protection.outlook.comMicrosoft 3651 requête
Requêtes comptées comme le fait la RFC 7208 §4.6.4 : l'include lui-même plus tout ce qu'il contient. Les décomptes en direct de cette page viennent toujours du parcours, pas de ce tableau.

Que sont les requêtes vides (void lookups) ?

Une requête vide est une requête qui revient sans aucun enregistrement : le nom n'existe pas (NXDOMAIN) ou existe sans l'enregistrement demandé. Les destinataires doivent en tolérer deux ; la troisième est permerror (RFC 7208 §4.6.4).

Un terme qui pointe vers un hôte disparu, a:old.example.com, n'est pas une erreur en soi : il ne correspond simplement pas et compte une requête vide. Il en va de même pour exists:%{i}._spf.mta.salesforce.com pour chaque expéditeur que Salesforce ne liste pas, ce qui explique pourquoi l'ordre des includes compte.

Une panne de serveur ou un délai dépassé n'est pas une requête vide : c'est un temperror, et les destinataires réessaient généralement plus tard.

Quatre réponses, trois issuesRFC 7208 §4.6.4

L'enregistrement propre de salesforce.com pour 192.0.2.1, relevé le 24 octobre 2026

v=spf1 include:_spf.google.com include:_spf.salesforce.com exists:%{i}._spf.corp.salesforce.com ~all

Requêtes vides2 / 2une troisième : permerror
  1. exists:%{i}._spf.mta.salesforce.com192.0.2.1._spf.mta.salesforce.com → NXDOMAIN · requête 3 · dans _spf.salesforce.com
  2. exists:%{i}._spf.corp.salesforce.com192.0.2.1._spf.corp.salesforce.com → NXDOMAIN · requête 4 · dans salesforce.com

Résultat : softfail, les deux requêtes vides permises étant dépensées

Le nom existe, pas l'enregistrementa:mail.example.com pour un nom toujours présent mais sans adresse : NOERROR sans réponse. Pas de correspondance, une requête vide, et la vérification continue.NODATAvide
Le nom n'existe pasexists:%{i}._spf.mta.salesforce.com construit un nom à partir de chaque IP d'envoi ; pour une adresse que Salesforce ne liste pas, la réponse est NXDOMAIN : une requête vide à chaque fois.NXDOMAINvide
La troisième requête videmx:shop.example.com, un nom disparu, après 2 requêtes vides déjà : les destinataires s'arrêtent ici.NXDOMAINpermerror
Aucune réponse du toutSERVFAIL ou délai dépassé pour include:_spf.vendor.example : le DNS est en panne, donc rien ne compte comme vide.SERVFAILtemperror, pas une requête vide

L'include include:spf.bmv.jp de blastmail commence par deux termes exists de ce genre : pour une adresse qu'il ne liste pas, il dépense à lui seul les deux requêtes vides permises.

Seule une réponse vide compte comme requête vide. Une panne est un temperror, et la vérification est retentée plus tard.

L'aplatissement SPF : quand il aide et quand il casse

Aplatir remplace un include par les adresses qu'il liste, pour que l'enregistrement coûte moins de requêtes. Cela marche pour des plages qui changent rarement, et se retourne contre vous quand un fournisseur ajoute un serveur que vous n'avez pas copié : ses e-mails échouent alors au SPF.

Microsoft déconseille d'aplatir include:spf.protection.outlook.com, et les includes de Google et de Microsoft coûtent déjà une requête chacun. Déplacer un expéditeur en masse vers un sous-domaine comme news.example.com lui donne un enregistrement, et 10 requêtes, à lui.

Un include, aplatimailgun.org · relevé le 24 octobre 2026

Avant

include:mailgun.org

Requêtes
5
Enregistrements récupérés
5
Octets dans votre enregistrement
19
Mailgun change une plage
pris en compte aussitôt

Après

ip4:159.135.224.0/20 ip4:69.72.32.0/20 ip4:204.220.90.0/23 ip4:204.220.92.0/22 +18 de plus

Requêtes
0
Octets dans votre enregistrement
450
Chaînes TXT nécessaires
2
Mailgun change une plage
votre copie est périmée

Le risque de la copie périmée. Vous copiez 22 plages aujourd'hui ; quand Mailgun en ajoute une, ses e-mails échouent au SPF jusqu'à ce que quelqu'un s'en aperçoive et mette l'enregistrement à jour.

  1. copié
  2. Mailgun ajoute une plage
  3. ses e-mails échouent au SPF
Aplatir seulement les plages qui changent rarement, comme les adresses de vos propres serveurs.
Ne pas aplatir Microsoft 365 : Microsoft dit que ses adresses d'envoi changent souvent, gardez donc l'include.
Préférer un sous-domaine par expéditeur en masse : chacun a un enregistrement, et 10 requêtes, à lui.
Aplatir échange des requêtes contre de la maintenance : la copie n'est juste que jusqu'à ce que le fournisseur change ses plages.

~all ou -all (et DMARC)

Le dernier terme dit ce qui arrive à tout expéditeur non listé. -all est fail, la déclaration la plus forte ; ~all est softfail, « probablement pas » ; ?all est neutral, que les destinataires traitent comme l'absence de SPF ; +all laisse tout le monde passer et ne devrait jamais être publié.

Entre ~all et -all, il n'y a pas de mauvaise réponse. Google documente ~all pour Google Workspace et Microsoft -all pour Microsoft 365. Avec DMARC en application, ~all laisse DMARC trancher sur DKIM : certains destinataires rejettent sur -all avant que DMARC voie une signature DKIM valide, donc un e-mail transféré peut rebondir (RFC 9989 §7.1).

Les quatre terminaisonsRFC 7208 §2.6 · RFC 9989 §7.1
~all
softfail« Probablement non autorisé » : les destinataires ne devraient pas rejeter sur cette seule base.
Documenté parGoogle WorkspaceMailguniCloud+
-all
failLa déclaration la plus forte : un destinataire peut rejeter le message en SMTP.
Documenté parMicrosoft 365ZendeskGoDaddy
?all
neutralAucune déclaration : les destinataires le traitent exactement comme l'absence de SPF.
Documenté parFastmailLes includes de IONOS et OVHcloud se terminent aussi par ?all : sans conséquence là, puisque seul un pass dans un include correspond.
+all
pass pour tout le mondeN'importe quel serveur d'Internet passe pour le domaine.
Ne le publiez jamais

-all avec DMARC à p=reject

  1. SPF : fail
  2. rejeté en SMTP
  3. DKIM jamais vérifié

Certains destinataires agissent d'abord sur le SPF : un message transféré avec une signature DKIM valide peut donc être refusé avant que DMARC s'exécute, et la perte n'apparaît jamais dans les rapports DMARC.

~all avec DMARC à p=reject

  1. SPF : softfail
  2. DMARC vérifie DKIM
  3. DKIM aligné : pass

DMARC décide. Sans signature DKIM, cependant, Microsoft dit que DMARC est en pratique ignoré pour les échecs ~all, et recommande -all pour cette raison.

~all comme -all sont des choix valables ; ?all ne dit rien, et +all laisse n'importe qui passer.

Erreurs SPF courantes et comment les corriger

La plupart des enregistrements cassés viennent de trois erreurs : un second enregistrement SPF ajouté à côté du premier au lieu de les fusionner, un include pour un fournisseur disparu depuis, et une valeur copiée depuis une documentation avec une faute de frappe.

La documentation des fournisseurs imprime elle-même certaines de ces erreurs : Mimecast écrit –all avec un tiret demi-cadratin, Postmark include: spf.mtasv.net avec une espace, Twilio SendGrid liste un mécanisme aaaa qui n'existe pas. Toute erreur de syntaxe rend tout l'enregistrement permerror. Un point final après un domaine, en revanche, est valide.

Huit enregistrements, huit résultatsExemples inventés d'erreurs réelles

Deux enregistrements SPFpermerror

v=spf1 include:_spf.google.com ~allv=spf1 include:sendgrid.net ~all

Correction : fusionnez-les en un seul : un v=spf1, chaque include une fois, une terminaison.

Plus de 10 requêtespermerror

v=spf1 include:_netblocks.mimecast.com include:mailgun.org -all

14 requêtes

Correction : retirez les expéditeurs que vous n'utilisez plus, ou donnez à un expéditeur en masse son propre sous-domaine.

Une troisième requête videpermerror

v=spf1 a:old.example.com mx:gone.example.net exists:%{i}.spf.example.org -all

3 vides

Correction : supprimez les termes dont les noms ont disparu, et placez les includes exists en dernier.

Un include sans enregistrement SPF derrièrepermerror

v=spf1 include:spf.retired-vendor.example -all

Correction : corrigez le nom, ou retirez le fournisseur que vous avez quitté.

Un tiret demi-cadratin dans –allpermerror

v=spf1 include:_netblocks.mimecast.com –all

Imprimé ainsi dans la documentation de Mimecast

Correction : un trait d'union simple : -all.

Une espace après include:permerror

v=spf1 a mx include: spf.mtasv.net ~all

Imprimé ainsi dans la documentation de Postmark

Correction : include:spf.mtasv.net

Un mécanisme aaaapermerror

v=spf1 aaaa:example.com ~all

Imprimé ainsi dans la documentation de Twilio SendGrid

Correction : a:example.com ; a correspond déjà aux enregistrements AAAA des expéditeurs IPv6.

Un point finalvalide

v=spf1 include:spf.protection.outlook.com. -all

Valide : la RFC 7208 §7.3 dit de ne pas le publier, mais les destinataires doivent l'accepter.

L'aide de Zendesk dit aussi « redirect: syntax is supported » : le modificateur s'écrit redirect= (RFC 7208 §6.1).

Chaque enregistrement est un exemple inventé ; les erreurs sont celles que les destinataires voient le plus.

Ce que Gmail, Yahoo et Microsoft exigent

Depuis février 2024, Gmail et Yahoo exigent de chaque expéditeur qu'il configure SPF ou DKIM. Les expéditeurs en masse ont besoin des deux, d'un enregistrement DMARC d'au moins p=none, et d'un domaine From: aligné avec l'un d'eux. Outlook.com demande aux expéditeurs à fort volume SPF et DKIM à la fois, et rejette ceux qui n'ont pas les deux depuis le 5 mai 2025.

Le seuil de Gmail est de plus de 5 000 messages par jour vers des comptes personnels ; Yahoo n'en publie aucun. Le SPF seul ne rend jamais un e-mail « aligné » : le domaine de MAIL FROM doit être le vôtre, pas le domaine de rebond du fournisseur.

Les règles des trois fournisseurs de messagerieLu sur les pages de chaque fournisseur, le 24 octobre 2026
GmailYahooOutlook.com
Seuil en masseGmailplus de 5 000 messages par jour vers des comptes Gmail personnels, comptés par domaine principalYahooaucun publié : « We will not specify a volume threshold »Outlook.complus de 5 000 par jour (blog de Microsoft) ; 5 000 ou plus depuis un même domaine From: (son article d'assistance)
Tous les expéditeursGmailSPF ou DKIM, plus DNS direct et inverse, TLS et un taux de spam inférieur à 0,3 %YahooSPF ou DKIM, plus DNS direct et inverse et un taux de spam inférieur à 0,3 %Outlook.comaucune règle stricte
Expéditeurs en masseGmailSPF et DKIM, DMARC (p=none suffit), From: aligné avec SPF ou DKIM, désabonnement en un clic pour les e-mails marketingYahooSPF et DKIM, DMARC au moins p=none et réussi, From: aligné avec SPF ou DKIM, désabonnement en un clicOutlook.comSPF doit passer et DKIM doit passer, DMARC au moins p=none, aligné avec SPF ou DKIM
En vigueur depuisGmail1 février 2024 ; rejets intensifiés à partir de novembre 2025Yahoofévrier 2024Outlook.com5 mai 2025 (rejet)
L'échec SPF s'affiche commeGmail4.7.275.7.27Yahoonon documenté pour le SPFOutlook.com550 5.7.515

Japon : le réglage le plus strict de NTT docomo, 「全て拒否する」, refuse les e-mails dont l'IP d'envoi n'est pas autorisée par l'enregistrement SPF du domaine, et ceux des domaines qui ne publient aucun enregistrement SPF. docomo.ne.jp

Sourcessupport.google.comsenders.yahooinc.comtechcommunity.microsoft.com

Les règles de chaque fournisseur telles que ses propres pages les énoncent le 24 octobre 2026.

Recherche SPF, dig et nslookup

dig et nslookup montrent les enregistrements TXT tels que votre résolveur les a : l'enregistrement SPF et tout ce qui se trouve d'autre à ce nom. Ils ne suivent pas les includes, ne comptent ni les requêtes ni les requêtes vides, et ne disent pas ce que déciderait un destinataire.

Une recherche SPF comme celle-ci parcourt tout l'enregistrement, donc les chiffres correspondent à ce que calcule un serveur destinataire. Utilisez dig pour un nom, ce vérificateur pour le verdict.

Trois façons de regarder le SPFCe que chacun montre
Ce vérificateurdig TXTnslookup -type=TXT
Montre les enregistrements TXTCe vérificateurOuidécoupés en termesdig TXTOuinslookup -type=TXTOui
Joint les chaînes d'un long enregistrementCe vérificateurOuicomme les destinatairesdig TXTNonmontre chaque chaîne à partnslookup -type=TXTNonmontre chaque chaîne à part
Suit chaque includeCe vérificateurOuitout l'arbredig TXTNonun nom par requêtenslookup -type=TXTNonun nom par requête
Compte les requêtes jusqu'à 10Ce vérificateurOuiun total cumulé, par includedig TXTNonà la mainnslookup -type=TXTNonà la main
Compte les requêtes videsCe vérificateurOuiavec les nomsdig TXTNonnslookup -type=TXTNon
Dit que deux enregistrements = permerrorCe vérificateurOuidig TXTNonaffiche les deuxnslookup -type=TXTNonaffiche les deux
Teste une IP d'envoiCe vérificateurOuicheck_host et le terme qui corresponddig TXTNonnslookup -type=TXTNon
Interroge votre propre résolveurCe vérificateurNonGoogle Public DNS, depuis notre serveurdig TXTOuinslookup -type=TXTOui
La même question posée de trois façons : dig et nslookup montrent ce que votre propre résolveur a, le vérificateur ce qu'un destinataire calcule.

Vérificateur SPF : questions fréquentes

Qu'est-ce qu'une vérification d'enregistrement SPF ?

Une vérification d'enregistrement SPF lit l'enregistrement SPF d'un domaine, l'enregistrement TXT qui commence par v=spf1, et le parcourt comme le fait un serveur de messagerie destinataire : chaque include et redirect suivi, chaque requête DNS comptée face à la limite de 10 et chaque réponse vide face à la limite de 2. Elle se termine par ce que les destinataires obtiennent pour un expéditeur non listé, ou par le permerror et sa cause.

Comment tester si une adresse IP est autorisée à envoyer des e-mails pour mon domaine ?

Choisissez Tester une IP, saisissez le domaine et l'adresse du serveur d'envoi, IPv4 ou IPv6, et si vous le souhaitez l'adresse MAIL FROM et le nom HELO. Le vérificateur exécute check_host pour cette adresse et montre pass, fail, softfail, neutral ou permerror, le terme exact qui a correspondu, son qualificateur et la chaîne d'includes qui y a mené.

Que signifie « SPF too many DNS lookups » ?

Cela signifie que vérifier l'enregistrement exige plus de 10 requêtes DNS, la limite de la RFC 7208. Chaque include, a, mx, ptr, exists et redirect en coûte une, y compris ceux imbriqués dans des includes. Les destinataires s'arrêtent à la 11e avec permerror : les expéditeurs listés après ce point cessent de passer le SPF. Retirez les includes inutilisés, ou déplacez un expéditeur vers un sous-domaine avec son propre enregistrement.

Qu'est-ce qu'un permerror SPF ?

Un permerror est le résultat SPF « cet enregistrement ne peut pas être évalué ». Il vient de plus de 10 requêtes DNS, de plus de 2 requêtes vides, de deux enregistrements SPF à un même nom, d'un include d'un nom sans enregistrement SPF, ou d'une erreur de syntaxe. Ce n'est pas un fail : les destinataires décident quoi en faire, mais sous DMARC il ne compte jamais comme un pass.

Qu'est-ce qu'une requête vide (void lookup) en SPF ?

Une requête vide est une requête DNS faite pour un terme SPF qui revient sans rien : le nom n'existe pas (NXDOMAIN) ou n'a pas d'enregistrement du type demandé. La RFC 7208 dit que les destinataires devraient en tolérer deux ; la troisième est permerror. Une panne de serveur ou un délai dépassé n'est pas une requête vide mais un temperror, que les destinataires réessaient généralement plus tard.

Mon enregistrement SPF doit-il se terminer par ~all ou -all ?

Les deux sont valables. -all (fail) est la déclaration la plus forte et Microsoft le documente pour Microsoft 365 ; ~all (softfail) est ce que Google documente pour Google Workspace. Avec une signature DKIM et DMARC à quarantine ou reject, ~all est souvent la terminaison la plus sûre, car certains destinataires rejettent sur -all avant que DMARC puisse accepter une signature DKIM valide.

Un domaine peut-il avoir deux enregistrements SPF ?

Non. Si un nom a deux enregistrements TXT qui commencent par v=spf1, les destinataires ne peuvent pas en choisir un et la vérification se termine en permerror avant toute requête, pour chaque expéditeur (RFC 7208 §4.5). Cela arrive en général quand l'enregistrement d'un nouveau fournisseur est ajouté à côté de l'ancien. Fusionnez-les en un seul enregistrement avec un v=spf1, chaque include une fois et une seule terminaison.

Qu'est-ce que l'aplatissement SPF, et faut-il l'utiliser ?

L'aplatissement remplace les includes par les plages d'IP qu'ils listent, pour que l'enregistrement exige moins de requêtes DNS. Il aide pour des plages qui changent rarement, mais une copie aplatie devient périmée dès que le fournisseur ajoute des serveurs, et leurs e-mails échouent alors au SPF. Préférez retirer les includes inutilisés ou donner à un expéditeur en masse son propre sous-domaine ; n'aplatissez jamais l'include de Microsoft 365.

Un sous-domaine a-t-il besoin de son propre enregistrement SPF ?

Oui. Le SPF n'a pas d'héritage : un enregistrement ne couvre que le nom exact où il est publié, donc mail.example.com ou news.example.com a besoin de son propre enregistrement s'il apparaît dans MAIL FROM ou HELO. C'est différent de DMARC, qui se rabat sur le domaine d'organisation. Un sous-domaine qui n'envoie aucun e-mail peut publier v=spf1 -all.

Pourquoi le SPF passe ici mais échoue chez Gmail ?

En général parce que Gmail a vérifié un autre domaine ou une autre adresse. Le SPF est évalué pour le domaine de MAIL FROM (Return-Path) et l'IP du serveur qui se connecte, qui peut être le domaine de rebond de votre fournisseur, pas le vôtre. Le transfert casse aussi le SPF, puisque l'IP du transitaire n'est pas dans votre enregistrement. Consultez l'en-tête Authentication-Results d'un vrai message et testez cette IP et ce domaine ici.

Quelle est la différence entre SPF, DKIM et DMARC ?

Le SPF liste les serveurs autorisés à envoyer pour un domaine et se vérifie sur l'expéditeur d'enveloppe. DKIM signe chaque message avec une clé publiée dans le DNS, donc la signature survit au transfert. DMARC les relie à l'adresse From: qu'un lecteur voit : un message passe DMARC quand SPF ou DKIM passe pour un domaine aligné avec From:, et la politique dit quoi faire sinon.

Combien de temps faut-il pour qu'un changement d'enregistrement SPF fasse effet ?

Aussi longtemps que les résolveurs gardent l'ancien enregistrement : jusqu'à son TTL, que fixe le domaine (300 secondes pour google.com et github.com, une heure pour microsoft.com lors de notre vérification). Les destinataires interrogent leur résolveur, donc un changement apparaît quand chaque copie en cache expire. Ce vérificateur montre le TTL tel que le serveur de noms du domaine le sert ; vérifiez à nouveau après ce délai.

Il vous manque quelque chose ?Suggérez une fonction ou un nouvel outil

Outils e-mail et DNS associés