Vérifiez un enregistrement SPF, développez chaque include et comptez les requêtes DNS face à la limite de 10
Runs in your browser. Only the lookup you start is sent to cloudflare-dns.com or dns.google; nothing else leaves your device.Un vérificateur SPF lit l'enregistrement TXT qui liste les serveurs autorisés à envoyer du courrier pour un domaine, suit chaque include et redirect et compte les requêtes DNS. La RFC 7208 autorise au plus 10 requêtes et 2 requêtes vides ; un enregistrement qui dépasse l'une des deux limites échoue chez tous les destinataires, aussi correct qu'il paraisse.
Cette page a été traduite automatiquement à partir de l'original anglais. Aucune personne n’a encore relu la traduction : c’est la version anglaise qui fait foi. Lire l'original en anglais
Saisissez le domaine, comme example.com, dans le champ Domaine.
Appuyez sur Vérifier SPF pour lire l'enregistrement et suivre chaque include.
Lisez, sous le verdict, le nombre de requêtes DNS sur 10 et la façon dont l'enregistrement se termine.
Lisez Développé, chaque requête numérotée pour voir quel include ajoute le plus de requêtes.
Appuyez sur Copier l'arbre pour garder l'enregistrement développé.
Saisissez un domaine et la page demande à un résolveur public DNS-over-HTTPS (Cloudflare ou Google, à votre choix) ses enregistrements TXT, choisit celui qui commence par v=spf1 et le lit terme par terme. Chaque include: et redirect= est suivi, et les enregistrements vers lesquels ils pointent sont lus de la même façon : tout l'arbre des réseaux autorisés tient sur un seul écran.
Ce qui compte, c'est le nombre de requêtes DNS. La section 4.6.4 de la RFC 7208 limite une vérification à 10 termes qui nécessitent le DNS : include, a, mx, ptr, exists et redirect comptent chacun pour un, où qu'ils soient dans l'arbre, tandis que ip4, ip6 et all ne comptent pas. Chaque terme compté est numéroté dans l'arbre : quand un enregistrement dépasse, vous voyez quel include l'a fait passer au-dessus. Les requêtes qui ne trouvent rien, appelées requêtes vides (void), sont limitées à 2, et un nom qui n'existe plus est affiché comme void.
Le verdict indique ce que les destinataires feront réellement : deux enregistrements SPF sous un même nom sont une erreur permanente, +all laisse n'importe qui envoyer au nom du domaine, ?all ou l'absence de all ne donne aucune réponse pour les serveurs non listés, ptr est déconseillé et les termes après all ne sont jamais lus. ~all demande aux destinataires de marquer le courrier des serveurs non listés ; -all leur demande de le faire échouer. Chaque ligne cite la section de la RFC 7208 dont elle vient.
Ce qu'il ne fait pas : il vérifie l'enregistrement, pas un message. Les termes contenant des macros comme %{i} sont remplis à partir de l'adresse d'envoi de chaque message ; ils sont donc comptés mais pas interrogés. Il ne peut pas dire si l'adresse d'un serveur donné est couverte, sauf si cette adresse figure dans l'enregistrement.
L'onglet générateur écrit un enregistrement à partir de vos choix, avec les includes de Google Workspace et Microsoft 365 documentés par ces fournisseurs, et indique combien de requêtes il utilise avant celles des fournisseurs eux-mêmes.
Le domaine que vous saisissez est envoyé au résolveur que vous choisissez, car une requête en a besoin. Rien d'autre ne quitte votre appareil.
La RFC 7208 autorise un destinataire à faire au plus 10 requêtes DNS en vérifiant un enregistrement SPF, en comptant chaque include, a, mx, ptr, exists et redirect de tout l'arbre. Au-delà de 10, le résultat est une erreur permanente et SPF échoue pour chaque message, même provenant de serveurs listés.
Les deux sont valides. Un enregistrement qui finit par -all demande aux destinataires de faire échouer le courrier des serveurs non listés ; ~all leur demande de l'accepter mais de le marquer comme suspect. Beaucoup de domaines commencent par ~all le temps de trouver chaque expéditeur, puis passent à -all. Finir par +all ou sans all n'offre aucune protection.
Non. La RFC 7208 impose qu'un domaine publie exactement un enregistrement TXT commençant par v=spf1. Avec deux, les destinataires ne peuvent pas choisir et renvoient une erreur permanente, si bien que SPF échoue pour tout le courrier. Fusionnez-les en un seul enregistrement en gardant chaque include et adresse des deux.
Un terme ip4 ou ip6 contient déjà la plage d'adresses, donc le vérifier ne demande aucune requête DNS. Include, a, mx, exists, ptr et redirect nécessitent tous au moins une requête pour savoir ce qu'ils représentent. Remplacer un include stable par ses plages d'adresses est le moyen habituel de passer sous 10.
Oui, le nom de domaine part vers le résolveur DNS public que vous choisissez, Cloudflare ou Google, car une requête DNS en a besoin. Le résolveur voit les noms interrogés et votre adresse IP, comme pour toute requête DNS. Rien d'autre ne quitte votre appareil, et ce site ne conserve rien de la vérification.
Une requête vide est une requête DNS qui ne trouve rien : le nom n'existe pas, ou il existe sans enregistrement du type demandé. La RFC 7208 demande aux destinataires d'en tolérer au plus 2, car un enregistrement rempli de noms morts est une attaque courante contre les destinataires. Supprimez les noms qui n'existent plus.
Toujours bloqué ? Poser une question sur Vérificateur SPF et toute personne qui connaît la réponse peut répondre. Aucun compte nécessaire.