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 pour gros expéditeurs de Gmail, Yahoo, Outlook.com et Apple.
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. Supprimez les include des plateformes depuis lesquelles vous n’envoyez plus, ou déplacez une plateforme sur son propre sous-domaine avec son propre enregistrement. Aplatir un include en entrées ip4 fonctionne aussi, mais seulement chez un fournisseur aux adresses stables : Microsoft déconseille d’aplatir son propre include, parce que les adresses derrière changent et qu’une copie aplatie se périme sans le dire.
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é.
SPF autorise l’expéditeur d’enveloppe dans le Return-Path, pas l’adresse que voit votre lecteur. Un message peut passer SPF en affichant le From qu’il veut, d’où l’importance de l’alignement DMARC. Seul, SPF prouve très peu de choses.
Toutes les dates et tous les chiffres qu’Unspam publie sur les exigences applicables aux expéditeurs sont regroupés ici et vérifiés dans la documentation de chaque fournisseur. Dernière lecture : 16 août 2026.
| Fournisseur | Quoi | Valeur | S’applique à |
|---|---|---|---|
| Règles pour expéditeurs en masse en vigueur depuis source | février 2024 obligatoire | e-mails vers des adresses Gmail personnelles | |
| Durcissement de l’application depuis source | novembre 2025 observé Google parle d’un processus graduel et progressif, pas d’un interrupteur basculé à une date donnée. | e-mails vers des adresses Gmail personnelles | |
| Considéré comme expéditeur en masse à partir de source | 5 000 obligatoire C’est le chiffre de Google. Yahoo refuse d’en publier un. | e-mails vers des adresses Gmail personnelles | |
| Plafond du taux de plaintes pour spam source | 0,3 % obligatoire Google décrit l’effet comme progressif et non comme un seuil couperet : au-dessus du chiffre recommandé le placement en boîte de réception souffre déjà, et au plafond il souffre davantage. | tous les expéditeurs vers Gmail, pas seulement en masse | |
| Taux de plaintes pour spam à viser source | 0,1 % recommandé Postmaster Tools ne divise pas les plaintes par tout ce que vous avez envoyé. Il les rapporte aux messages signés DKIM parvenus dans la boîte de réception d’un destinataire actif, un expéditeur déjà filtré peut donc voir un taux artificiellement bas. | tous les expéditeurs vers Gmail, pas seulement en masse | |
| Yahoo | Règles pour expéditeurs en masse en vigueur depuis source | février 2024 obligatoire | e-mails vers Yahoo, AOL et les autres boîtes de Yahoo |
| Considéré comme expéditeur en masse à partir de source | non publié Yahoo déclare qu’il ne précisera pas de seuil de volume, aucun chiffre ne peut donc lui être attribué. | e-mails vers Yahoo, AOL et les autres boîtes de Yahoo | |
| Plafond du taux de plaintes pour spam source | 0,3 % obligatoire | e-mails vers Yahoo, AOL et les autres boîtes de Yahoo | |
| Outlook.com | Règles pour expéditeurs en masse en vigueur depuis source | mai 2025 obligatoire | Outlook.com et les autres boîtes grand public de Microsoft, jamais un locataire Microsoft 365 |
| Considéré comme expéditeur en masse à partir de source | 5 000 obligatoire La règle s’applique à tout domaine ayant déjà franchi le seuil, elle continue donc de s’appliquer les jours plus calmes. | Outlook.com et les autres boîtes grand public de Microsoft, jamais un locataire Microsoft 365 | |
| Ce qu’il advient des e-mails en échec source | 550 5.7.515 observé Le courrier non conforme est refusé pendant la conversation SMTP au lieu d’être classé dans le dossier indésirables. La page de politiques pour postmasters de Microsoft décrit encore le dossier indésirables comme première étape, un expéditeur peut donc voir l’un ou l’autre, mais c’est le rejet qu’il faut anticiper. | Outlook.com et les autres boîtes grand public de Microsoft, jamais un locataire Microsoft 365 | |
| SPF et DKIM doivent tous deux réussir, pas seulement DMARC source | obligatoire Plus strict que DMARC seul. DMARC est validé dès que SPF ou DKIM est aligné, et Outlook.com demande en plus que les deux contrôles réussissent. | Outlook.com et les autres boîtes grand public de Microsoft, jamais un locataire Microsoft 365 | |
| Apple | Règles pour expéditeurs en masse en vigueur depuis source | février 2025 obligatoire | e-mails vers iCloud Mail, me.com et mac.com |
| En-têtes ARC sur les e-mails transférés source | obligatoire Apple est le seul des quatre à le demander, ce qui est la vraie raison de s’intéresser à ARC. | e-mails vers iCloud Mail, me.com et mac.com |
Unspam lit tout cela à partir de votre seul nom de domaine.
Aucune requête DNS n’y accède. Il faut un vrai message ou un vrai historique d’envoi, et c’est précisément à cela que sert un test de placement en boîte de réception.
