Vérificateur d'enregistrement SPF

Qu'est-ce que la limite de requêtes SPF ?

Un enregistrement SPF est une ligne de texte dans le DNS qui énumère qui peut envoyer du courrier au nom de votre domaine. Les serveurs destinataires l'évaluent, et certains de ses termes les obligent à interroger encore le DNS : include, a, mx, ptr et exists, ainsi que le modificateur redirect. Le RFC 7208 y pose un plafond ferme : les implémentations doivent limiter ces termes à dix pendant l'évaluation, et si la limite est dépassée elles doivent renvoyer permerror.

Un permerror n'est pas un rejet. Il signifie que SPF ne s'est pas évalué : votre courrier arrive donc sans aucun pass SPF derrière lui, ce qui affaiblit à son tour DMARC et dégrade la délivrabilité par des voies dont personne ne vous rend compte. Rien n'échoue bruyamment, rien n'est journalisé, et l'enregistrement continue de paraître tout à fait raisonnable à la lecture.

Les autres termes sont gratuits. all, ip4, ip6 et le modificateur exp figurent dans le même paragraphe comme ne provoquant pas de requêtes : un enregistrement listant trois cents plages d'adresses ne coûte donc rien, tandis qu'un enregistrement à onze includes est déjà cassé. Toute l'affaire tient dans cette asymétrie, et cette page montre lesquels de vos termes puisent dans le budget.

Comment l'utiliser

1. Collez l'enregistrement. La valeur TXT elle-même, commençant par v=spf1. Les exemples couvrent un enregistrement simple, un chargé, un cassé par lui-même, et un enregistrement réel de quatre termes cassé malgré tout.
2. Lisez le budget. Trois nombres : ce que dépense cet enregistrement, la limite de dix, et combien de ses termes sont des includes dont le coût propre est ici inconnu.
3. Lisez les contrôles structurels. Ce qui se tranche à partir du texte seul : un all manquant, des termes après le all qui ne seront jamais atteints, +all, un redirect mort, ptr.

Pourquoi cet outil ne peut pas vous dire que votre enregistrement va bien

Tout sur ce site s'exécute dans votre navigateur, et un navigateur ne peut pas faire de requête DNS. Cette page peut donc compter les termes générateurs de requêtes dans l'enregistrement qu'elle a sous les yeux, et rien de plus. Chaque include coûte une requête plus ce que coûte son propre enregistrement, et cette seconde part exige le DNS.

Nous voulions savoir quelle importance cela a, alors nous avons résolu les enregistrements SPF des 250 domaines les plus fréquentés du web en suivant chaque include jusqu'au bout. 198 en publient un. Aucun ne dépassait dix requêtes au décompte superficiel — et quatre le dépassent une fois les includes suivis : leur SPF est donc en permerror aujourd'hui. Un décompte fait sans DNS n'en a trouvé aucun des quatre.

L'un de ces quatre se lit v=spf1 a mx include:iiko.ru include:amazonses.com -all. Quatre termes. C'est le quatrième bouton d'exemple de cette page, et l'outil l'annonce à quatre sur dix sans rien de structurellement fautif, parce que c'est toute l'information disponible sans interroger le DNS. En réalité il coûte quinze et ne s'évalue pas.

Voilà pourquoi le nombre ci-dessus est présenté comme un plancher et jamais comme un verdict. Sur l'ensemble du relevé, 86 des 198 enregistrements dissimulaient des requêtes supplémentaires derrière leurs includes — une médiane de deux de plus, et jusqu'à quinze de plus dans le pire cas. Tout outil qui vous montre un décompte superficiel sans le dire vous annonce qu'un enregistrement à neuf est tranquille alors qu'il peut être à vingt-trois.

Ce qui vaut d'être vérifié ici, et ce qui exige un résolveur

Bien des choses se décident à partir du texte seul, et ces contrôles sont la raison d'ouvrir cette page. Si l'enregistrement commence par v=spf1, car sans cela ce n'est tout simplement pas du SPF et il est ignoré. S'il se termine par un all, et avec quel qualificateur : +all autorise l'internet entier à envoyer au nom de votre domaine, ce qui n'est presque jamais l'intention. Si quelque chose suit le all, là où il ne sera jamais atteint, puisque l'évaluation s'arrête à la première correspondance et que all correspond toujours.

Également si un redirect côtoie un all, ce qui rend le redirect mort : il n'est consulté que si rien n'a correspondu. Si ptr apparaît, ce que la spécification déconseille. Et si l'enregistrement dépasse déjà dix requêtes avant qu'aucun include ne soit suivi, ce qui arrive et, quand cela arrive, ne souffre aucune ambiguïté.

Ce qui exige réellement un résolveur : le total véritable de requêtes, le fait que chaque include résolve bien vers un enregistrement, et la limite des requêtes vides — la spécification dit aussi que les implémentations devraient les plafonner à deux, ce qui ne se compte pas sans faire les requêtes. Pour cela, servez-vous d'un vérificateur qui résout, et traitez le nombre affiché ici pour le plancher qu'il est.

Une chose encore qu'il ne fait pas : il ne dit rien sur la justesse des adresses listées. SPF est une liste de qui peut envoyer ; aucun outil ne peut vous dire que cette liste correspond à vos expéditeurs réels.

Pourquoi est-ce gratuit ?

Ce n'est que de l'analyse de chaînes et un décompte, exécutés dans votre navigateur. Aucun résolveur à payer, aucun compte à créer — et l'absence de ce résolveur est annoncée clairement ci-dessus plutôt que dissimulée.

Rien de ce que vous collez n'est envoyé, conservé ni journalisé. Un enregistrement SPF est du DNS public, il n'a donc rien de secret ; simplement, le domaine que vous consultez ne regarde personne d'autre.