Vérifier un enregistrement SPF, ou en construire un
Le SPF tombe en panne en silence. Il fonctionne un an, quelqu’un ajoute un service de plus, l’enregistrement dépasse la limite de dix requêtes DNS, et à partir de là tous les destinataires le considèrent comme cassé — sans la moindre erreur nulle part. Ici, vous voyez le compte.
- S’exécute dans votre navigateur, pas sur notre serveur
- Sans inscription
- Sans filigrane
Chargement de l’outil…
Comment ça marche
- Saisissez votre domaine. Ajoutez une adresse IP si vous voulez savoir si ce serveur précis a le droit d’envoyer.
- Lisez le résultat, le nombre de requêtes et les constats ; dépliez l’arborescence pour voir ce que contient réellement chaque enregistrement inclus.
- Servez-vous du générateur plus bas pour assembler un enregistrement correct à partir des services que vous utilisez vraiment.
Pourquoi rien n’est envoyé
Toutes les opérations de cette page sont effectuées par du code qui tourne dans l’onglet de votre navigateur, avec le moteur qui affiche les pages web. Le fichier est lu depuis le disque vers la mémoire de l’onglet, transformé sur place, puis réécrit sous forme de téléchargement. Il n’est jamais envoyé où que ce soit — ni à nous, ni à un tiers.
Vérifiez-le vous-même
- Ouvrez les outils de développement de votre navigateur (F12) et choisissez l’onglet « Réseau ».
- Chargez votre fichier et lancez l’outil.
- Les seules requêtes que vous verrez téléchargent le code de l’outil lui-même — et, pour quelques outils lourds, leur moteur open source depuis un CDN public — plus un petit signal de visite vers loreatec.jp (adresse et titre de la page, rien de plus). Aucune ne transporte votre fichier.
Questions fréquentes
En quoi consiste exactement la limite de dix requêtes ?
Chaque include, a, mx, ptr, exists et redirect coûte une requête DNS, et celles contenues dans les enregistrements que vous incluez comptent aussi. La norme (RFC 7208) plafonne le total à dix. Un destinataire qui atteint le plafond s’arrête et renvoie une erreur, que la plupart traitent comme si vous n’aviez pas de SPF du tout. La cause habituelle : des prestataires dont un seul include en cache trois ou quatre autres. La solution : retirer les services que vous n’utilisez plus, ou remplacer des include par des adresses IP en clair — avec prudence, car ces listes vieillissent.
Pourquoi +all est-il si grave ?
Parce qu’il autorise tous les serveurs d’internet à envoyer au nom de votre domaine. C’est pire que de ne rien publier : sans enregistrement, un destinataire se rabat sur d’autres signaux ; avec +all, vous vous êtes explicitement porté garant du spammeur. Cela apparaît en général quand quelqu’un copie un exemple et change le mauvais caractère.
L’enregistrement doit-il finir par -all ou par ~all ?
Le -all signifie « rejeter tout le reste », le ~all « traiter tout le reste avec suspicion ». Commencez par ~all tant que vous découvrez encore ce qui envoie pour vous, puis passez à -all. La différence ne compte vraiment qu’une fois le DMARC en place — le DMARC est la règle qui dit au destinataire quoi faire lorsque ces vérifications échouent, et une politique DMARC de rejet rejette même avec un SPF en ~all. Ne restez pas en ~all pour toujours par prudence : c’est une étape, pas une destination.
Puis-je avoir deux enregistrements SPF ?
Non. Deux enregistrements v=spf1 sur le même nom constituent une erreur permanente, et les destinataires arrêtent l’évaluation. Cela arrive quand un service vous demande d’« ajouter cet enregistrement » et que vous ajoutez un second TXT au lieu de fusionner ses entrées dans celui que vous avez déjà.
Qu’est-ce qui est envoyé, et à qui ?
Les noms de domaine à consulter partent vers le service DNS public que vous avez choisi, depuis votre navigateur. Le serveur de ce site n’intervient pas et ne garde trace de rien.