Qu'est-ce qu'un enregistrement SPF ?
Un enregistrement SPF (Sender Policy Framework, RFC 7208) est un enregistrement TXT de votre domaine qui liste les serveurs autorisés à envoyer des emails en son nom. Quand un message arrive, le serveur de réception lit l'enregistrement SPF du domaine de l'expéditeur d'enveloppe (le Return-Path, pas l'adresse From visible) et vérifie si l'IP d'envoi figure dans la liste.
Un domaine ne peut avoir qu'un seul enregistrement SPF. Deux enregistrements qui commencent par v=spf1 font échouer chaque vérification SPF avec une PermError : quand vous ajoutez un nouveau service, modifiez donc l'enregistrement existant au lieu d'en ajouter un autre. Depuis février 2024, Gmail et Yahoo exigent que chaque expéditeur utilise SPF ou DKIM, et que les expéditeurs en masse utilisent SPF, DKIM et DMARC ensemble.
Comment créer un enregistrement SPF
Votre fournisseur de messagerie, vos services de newsletter et d'emails transactionnels, votre help desk, votre CRM, et tout serveur ou site web qui envoie des emails depuis votre domaine. En oublier un est la cause la plus fréquente d'échec SPF.
Choisissez chaque fournisseur ci-dessus, ajoutez les autres domaines include et saisissez vos propres serveurs sous forme d'adresses IPv4 ou IPv6. N'utilisez mx que si vos serveurs de réception envoient aussi des emails.
~all (soft fail) est le point de départ habituel. Passez à -all (fail) quand vous êtes sûr que la liste est complète. Surveillez le compteur de requêtes : il doit rester à 10 ou moins.
Ajoutez-le comme enregistrement TXT avec l'hôte @ (ou le sous-domaine qui envoie les emails), en remplaçant tout enregistrement v=spf1 existant. Vérifiez-le ensuite avec le vérificateur SPF.
Advertisement
La syntaxe de l'enregistrement SPF expliquée
Un enregistrement SPF est une liste de termes lus de gauche à droite. Le premier qui correspond à l'IP d'envoi détermine le résultat.
La balise de version. Elle doit être le premier terme : c'est grâce à elle que les serveurs de réception reconnaissent l'enregistrement TXT comme SPF.
Autorise tout ce que contient l'enregistrement SPF d'un autre domaine, par exemple include:_spf.google.com. Chaque requête faite dans cet enregistrement compte aussi dans votre limite.
Autorisent une adresse ou une plage CIDR, par exemple ip4:203.0.113.10 ou ip6:2001:db8::/48. Ils ne coûtent aucune requête DNS.
Autorisent les IP de l'enregistrement A/AAAA du domaine ou de ses hôtes MX. Pratique, mais chacun coûte une requête, et mx peut entraîner jusqu'à 10 requêtes supplémentaires en interne.
Ce qu'il faut faire de tous les autres serveurs : soft fail, fail ou neutral. Ne publiez jamais +all, qui permet à n'importe qui d'envoyer des emails au nom de votre domaine.
redirect= confie toute la vérification à l'enregistrement d'un autre domaine. exists: est utilisé avec des macros par certains gros expéditeurs. ptr est lent, et la RFC 7208 recommande de ne pas le publier.
~all ou -all : soft fail ou fail ?
-all indique aux serveurs de réception que les emails de tout serveur non listé échouent au contrôle SPF, et beaucoup les rejettent. ~all les marque en soft fail (échec léger) : les serveurs ne devraient pas les rejeter pour cette seule raison, mais peuvent les considérer comme suspects. ?all est neutre et n'offre aucune protection.
Les instructions de Google Workspace utilisent ~all et l'exemple de Microsoft pour Microsoft 365 utilise -all. Les deux fonctionnent. Une fois DMARC publié, c'est la politique DMARC (p=quarantine ou p=reject) qui décide du sort des emails en échec : beaucoup de domaines gardent donc ~all pour éviter de rejeter des emails légitimes transférés et laissent DMARC appliquer la politique. Si le domaine n'envoie aucun email, publiez v=spf1 -all.
Advertisement
Exemples d'enregistrements SPF
Copiez celui qui correspond le mieux à votre configuration, ou créez le vôtre avec le générateur ci-dessus. Chacun est un seul enregistrement TXT sur votre domaine.
v=spf1 include:_spf.google.com ~allv=spf1 include:spf.protection.outlook.com -allv=spf1 ip4:203.0.113.10 include:_spf.google.com include:mailgun.org ~allv=spf1 include:zohomail.com ~allv=spf1 mx ip4:198.51.100.0/24 ip6:2001:db8::/48 -allv=spf1 -allLa limite de 10 requêtes DNS
La RFC 7208 plafonne une vérification SPF à 10 requêtes DNS. Chaque include, a, mx, ptr, exists et redirect en coûte une, de même que chacun de ces termes dans les enregistrements que vous incluez. ip4, ip6 et all sont gratuits. Une vérification qui nécessite une 11e requête s'arrête sur une PermError, que DMARC compte comme un échec SPF. Les serveurs de réception devraient aussi n'autoriser que 2 requêtes vides (void lookups : des noms qui n'existent pas ou ne renvoient aucun enregistrement).
Les fournisseurs ne coûtent pas tous la même chose. Nous avons compté chaque include le 5 octobre 2026, requêtes imbriquées comprises :
_spf.google.com et spf.protection.outlook.com listent directement leurs plages d'IP. Amazon SES, Brevo, Mailjet, Zendesk et Fastmail coûtent aussi 1 requête.
Chacun renvoie vers un autre enregistrement qui lui est propre.
Les boîtes mail des hébergeurs enchaînent souvent plusieurs includes.
Un seul d'entre eux plus quelques autres services peut épuiser tout le budget.
Advertisement
Comment corriger un enregistrement SPF avec trop de requêtes
Supprimez les services que vous n'utilisez plus. Les anciens outils de newsletter et les comptes d'essai sont les coupables habituels.
Remplacez `a` et `mx` par `ip4`/`ip6` quand vos propres serveurs ont des adresses fixes.
Déplacez les envois en masse vers un sous-domaine, comme news.example.com, avec son propre enregistrement SPF et ses propres 10 requêtes.
Vérifiez si un service a vraiment besoin d'un include. Beaucoup d'expéditeurs utilisent leur propre domaine de retour (bounce) : SPF passe alors sur le leur, et l'alignement DMARC vient de DKIM.
Méfiez-vous de l'aplatissement SPF (SPF flattening). Remplacer les includes par des listes d'IP copiées fonctionne jusqu'à ce qu'un fournisseur change ses IP : les emails commencent alors à échouer sans prévenir.
Erreurs SPF courantes
Deux enregistrements SPF sur le même domaine, par exemple un par fournisseur. Fusionnez-les en un seul.
Utiliser
+all, qui autorise tout Internet.Publier l'enregistrement sur le mauvais nom. SPF est vérifié sur le domaine de l'expéditeur d'enveloppe, et les sous-domaines n'en héritent pas.
Ajouter des mécanismes après
all. Les serveurs de réception ne les évaluent jamais : ces expéditeurs ne sont donc pas autorisés.Oublier un expéditeur, comme le serveur web qui envoie les messages du formulaire de contact.
Utiliser l'ancien type d'enregistrement SPF (type 99). La RFC 7208 l'a abandonné : publiez uniquement du TXT.
Advertisement
SPF, DKIM et DMARC fonctionnent ensemble
SPF seul n'empêche pas quelqu'un de falsifier l'adresse From que voient vos lecteurs. DKIM signe chaque message, et DMARC relie les deux au domaine From visible et indique aux serveurs de réception que faire en cas d'échec. Configurez les trois :
Vérifiez l'enregistrement publié, ses includes imbriqués et son nombre de requêtes.
Créez une paire de clés DKIM et l'enregistrement TXT selector._domainkey.
Créez une politique DMARC avec des adresses de rapport.
Lisez les résultats SPF, DKIM et DMARC d'un vrai message.