Interrogez et validez l’enregistrement TXT SPF de n’importe quel domaine : mécanismes, qualificateurs, politique all et limite de 10 requêtes DNS. L’outil est gratuit, tourne dans votre navigateur via DNS-over-HTTPS, sans inscription et sans rien conserver.
Créez un compte Unspam gratuit pour enregistrer vos résultats et relancer ces vérifications à tout moment, afin de repérer une configuration défaillante avant qu’elle ne vous coûte cher. Sans carte bancaire.
SPF (Sender Policy Framework, défini par la RFC 7208) est la liste publiée des serveurs autorisés à envoyer des e-mails pour votre domaine. Il prend la forme d’un unique enregistrement DNS TXT sur le domaine d’envoi, commençant par v=spf1, suivi de mécanismes qui désignent les sources autorisées et d’une politique all finale. Lorsqu’un fournisseur de messagerie reçoit un message, il compare l’IP d’envoi à l’enregistrement SPF du domaine de l’enveloppe (Return-Path) et utilise le résultat comme l’un des signaux du placement en boîte de réception. SPF est aussi l’une des briques de DMARC : un enregistrement correct fait donc partie des exigences de Gmail, Yahoo et Microsoft, qui rejettent de plus en plus les envois en masse non authentifiés.
Tout enregistrement SPF valide commence par v=spf1. Si l’enregistrement ne débute pas par cette balise exacte, ou si aucun enregistrement TXT n’est renvoyé, le domaine n’a pas de politique SPF exploitable.
Ils désignent les sources que vous autorisez. include délègue au SPF d’un autre domaine (par exemple votre plateforme d’envoi), a et mx autorisent vos propres hôtes A et MX, et ip4 / ip6 listent des adresses précises ou des plages CIDR.
Le mécanisme final fixe le comportement par défaut pour tous ceux qui ne sont pas listés : -all est un échec strict (recommandé), ~all un échec souple (courant pendant les tests), ?all est neutre, et +all autorise n’importe qui (à ne pas utiliser).
SPF autorise au maximum 10 requêtes DNS lors de l’évaluation. Les mécanismes comme include, a et mx en consomment chacun, et les include imbriqués ajoutent les leurs : le checker suit donc toute la chaîne d’include pour compter le total réel et signale les enregistrements qui dépassent la limite. Dépliez le détail pour voir de quel mécanisme provient chaque requête.
Un domaine ne doit publier qu’un seul enregistrement TXT v=spf1. Si le checker en trouve deux ou plus, l’enregistrement est invalide et les fournisseurs renverront une PermError.
Un domaine ne peut publier qu’un seul enregistrement TXT commençant par v=spf1. Dès qu’un second est ajouté (souvent lors de la mise en place d’une nouvelle plateforme d’envoi), l’évaluation renvoie une PermError et SPF échoue de fait. Fusionnez toutes les sources dans un enregistrement unique comportant plusieurs mécanismes include.
Chaque mécanisme include, a, mx, ptr et exists déclenche des requêtes DNS, et les include imbriqués ajoutent les leurs. Dès que l’évaluation en nécessite plus de 10, le résultat est une PermError. Aplatissez ou supprimez les include inutiles pour rester sous la limite.
Terminer l’enregistrement par +all annonce au monde entier que tout serveur est autorisé à envoyer au nom de votre domaine, ce qui désactive complètement SPF et ouvre la porte à l’usurpation. Utilisez -all pour un échec strict, ou ~all le temps de confirmer vos sources.
Si la requête ne renvoie rien, ou un enregistrement TXT qui ne commence pas par v=spf1, le domaine n’a aucune politique applicable et DMARC n’a rien sur quoi s’aligner. Publiez un enregistrement unique commençant par v=spf1 et terminé par un all restrictif.
Une chaîne TXT unique est limitée à 255 caractères. Les enregistrements longs doivent être découpés en plusieurs chaînes entre guillemets à l’intérieur d’un seul enregistrement TXT (ce qui est valide), et non en enregistrements distincts. Les découper en enregistrements séparés provoque au contraire l’erreur de multiplicité.
