Enregistrement SPF : le guide de référence complet

La syntaxe d'un enregistrement SPF

Un enregistrement SPF est une suite de mécanismes, chacun précédé d'un qualificateur optionnel, éventuellement complétée par des modificateurs. Exemple représentatif d'une entreprise qui envoie via une suite bureautique et un serveur applicatif propre :

exemple.fr.  IN TXT  "v=spf1 include:_spf.google.com ip4:203.0.113.10 -all"

Les mécanismes

Mécanisme	Rôle	Coût en lookups DNS
ip4:	Autorise une adresse IPv4 ou un bloc CIDR (ip4:203.0.113.0/24)	0
ip6:	Autorise une adresse IPv6 ou un bloc CIDR	0
a	Autorise les IP des enregistrements A/AAAA du domaine (ou d'un autre : a:mail.exemple.fr)	1
mx	Autorise les IP des serveurs de réception (enregistrements MX) du domaine	1 (+ la résolution de chaque nom MX)
include:	Importe la politique SPF d'un autre domaine — le mécanisme de délégation aux prestataires	1 + les lookups du domaine inclus
exists:	Correspond si le nom construit (généralement via macros) résout en A — usage avancé	1
all	Correspond toujours ; placé en dernier, il fixe le sort de tout ce qui n'a pas été listé	0

Un huitième mécanisme, ptr, existe dans la norme mais y est explicitement déconseillé : coûteux, peu fiable, il ne devrait plus apparaître dans aucun enregistrement récent.

Les qualificateurs

Chaque mécanisme peut être préfixé d'un qualificateur qui détermine le résultat en cas de correspondance :

Qualificateur	Résultat si le mécanisme correspond	Usage typique
+ (défaut)	pass	Implicite : écrire include: équivaut à +include:
-	fail	-all : tout émetteur non listé est rejeté
~	softfail	~all : suspect, accepté mais marqué
?	neutral	Aucune opinion — rarement justifié

En pratique, le qualificateur ne se voit presque que sur all, où son choix engage toute la politique — nous y revenons dans les bonnes pratiques.

Les modificateurs

Modificateur	Rôle
redirect=	Remplace entièrement l'évaluation par celle du domaine désigné (compte 1 lookup). Utile pour centraliser la politique de plusieurs domaines en un seul endroit.
exp=	Désigne un enregistrement TXT dont le texte sert de message d'explication en cas d'échec. Peu de destinataires l'affichent réellement.

redirect= diffère d'include: sur un point essentiel : include: importe une politique en plus du reste de l'enregistrement, tandis que redirect= s'y substitue entièrement (il ne s'applique d'ailleurs que si aucun mécanisme n'a correspondu, et rend le all local inutile).

Dernier détail de syntaxe souvent ignoré : une chaîne TXT est limitée à 255 caractères. Un enregistrement plus long doit être découpé en plusieurs chaînes au sein du même enregistrement TXT — les destinataires les concatènent. Ce qui est interdit, c'est de publier deux enregistrements SPF distincts, comme nous le verrons.

La limite des 10 lookups DNS et ses parades

La RFC 7208 impose une borne stricte : l'évaluation d'un enregistrement SPF ne doit pas déclencher plus de 10 résolutions DNS. Comptent dans ce budget les mécanismes include:, a, mx, ptr et exists:, ainsi que le modificateur redirect= — et le décompte est récursif : un include: qui en contient trois autres consomme quatre lookups à lui seul. Les mécanismes ip4:, ip6: et all ne coûtent rien. La norme borne par ailleurs à 2 les résolutions « à vide » (qui ne renvoient aucun résultat), un second plafond moins connu qui produit les mêmes symptômes.

Au-delà de la limite, le destinataire renvoie un permerror : l'enregistrement est considéré comme invalide et SPF échoue entièrement, comme s'il n'existait pas. Le danger est que la panne est silencieuse et différée : l'enregistrement fonctionne des mois sous la barre, puis l'ajout d'un prestataire de plus la franchit, et le courrier légitime se met à échouer sans qu'aucun message d'erreur ne remonte à personne. Notre guide sur la limite de lookups SPF détaille le décompte exact et le diagnostic pas à pas.

Les parades, par ordre de préférence :

1. Faire l'inventaire et élaguer. La plupart des enregistrements gonflés contiennent des include: de prestataires abandonnés depuis des années. Chaque mécanisme doit correspondre à un émetteur réel et actuel.
2. Préférer ip4:/ip6: pour les serveurs à IP stable. Un serveur applicatif maison n'a pas besoin d'un include: : son bloc d'adresses, publié en dur, coûte zéro lookup.
3. Segmenter par sous-domaine. Faire émettre l'emailing marketing depuis news.exemple.fr et la facturation depuis billing.exemple.fr donne à chaque sous-domaine son propre enregistrement — donc son propre budget de 10 lookups — tout en isolant les réputations.
4. Aplatir en dernier recours. Le flattening remplace les include: par les blocs IP qu'ils résolvent. Le gain est immédiat, mais le risque est réel : les fournisseurs changent leurs plages d'IP sans préavis, et un enregistrement aplati non maintenu finit par rejeter du courrier légitime. La technique, ses variantes automatisées et ses pièges sont détaillés dans notre guide du flattening SPF.

Une voie plus avancée encore — le mécanisme exists: combiné aux macros — permet de valider une IP en un seul lookup ; elle est puissante mais complexe et se justifie surtout dans les infrastructures d'envoi à très grande échelle.

Les résultats SPF : pass, fail, softfail et les autres

L'évaluation SPF produit l'un des résultats suivants, que le destinataire consigne dans l'en-tête Received-SPF (ou Authentication-Results) du message :

Résultat	Signification	Traitement habituel
pass	L'IP émettrice est autorisée par l'enregistrement	Le message poursuit son chemin ; SPF est utilisable par DMARC
fail	L'IP n'est pas autorisée et la politique est stricte (-)	Rejet ou forte pénalité de filtrage
softfail	L'IP n'est pas autorisée, politique indulgente (~)	Accepté mais marqué ; pèse dans le score antispam
neutral	Le domaine ne se prononce pas (?)	Traité peu ou prou comme une absence de SPF
temperror	Erreur DNS transitoire (timeout, serveur injoignable)	Réessai ultérieur, généralement sans conséquence
permerror	Enregistrement invalide : syntaxe, doublon, dépassement de lookups	SPF inutilisable — souvent pire qu'une absence

Un septième cas, none, signifie simplement qu'aucun enregistrement SPF n'a été trouvé pour le domaine.

Deux de ces résultats méritent une vigilance particulière. softfail est souvent laissé en place indéfiniment alors qu'il n'était censé être qu'une étape de transition — il affaiblit la posture sans que rien ne l'exige. Et permerror est le plus sournois : il ne vient jamais d'un attaquant mais toujours d'une erreur de configuration côté domaine — doublon d'enregistrement, faute de syntaxe, dépassement de lookups. Notre article dédié au permerror SPF recense les causes réelles et leur correction, cas par cas.

SPF seul ne suffit pas : l'alignement DMARC

Revenons à la distinction posée au début : SPF valide le domaine d'enveloppe, jamais le From: visible. Un attaquant peut donc publier un SPF irréprochable pour son propre domaine, émettre depuis ses serveurs dûment autorisés — SPF affiche pass — et inscrire votre domaine dans le From: que lira sa victime. SPF n'y voit rien : il n'a jamais regardé cette adresse.

C'est DMARC qui referme cette brèche en exigeant l'alignement : pour que SPF compte aux yeux de DMARC, le domaine d'enveloppe validé doit correspondre au domaine du From: visible. En mode relaxed (le défaut), une correspondance au niveau du domaine organisationnel suffit — bounces.exemple.fr s'aligne avec exemple.fr ; en mode strict (aspf=s), l'égalité doit être exacte. Le fonctionnement complet des politiques et des rapports est traité dans notre page de référence DMARC.

Cette dépendance révèle le talon d'Achille de SPF : le transfert. Quand un serveur intermédiaire fait suivre un message — redirection d'une boîte, alias, liste de diffusion —, il le réémet depuis sa propre IP, qui ne figure évidemment pas dans le SPF du domaine d'origine : SPF échoue. Les mécanismes de réécriture comme SRS (Sender Rewriting Scheme) « réparent » SPF en substituant le domaine du transféreur dans l'enveloppe — mais ce domaine-là ne s'aligne plus avec le From: d'origine, et l'échec ne fait que changer de nature.

La conclusion s'impose d'elle-même : SPF ne doit jamais porter seul l'authentification. DKIM, dont la signature cryptographique voyage dans le message et survit à la plupart des transferts, prend le relais précisément là où SPF casse — notre page de référence DKIM en détaille le fonctionnement. Un domaine correctement protégé combine les deux, et laisse DMARC exiger qu'au moins l'un des deux passe aligné.

Recettes SPF : Microsoft 365 et Google Workspace

Les deux grandes suites d'envoi couvrent l'immense majorité des messageries d'entreprise ; voici leurs enregistrements canoniques.

Microsoft 365 publie l'ensemble de ses IP d'émission derrière un unique include :

v=spf1 include:spf.protection.outlook.com -all

Google Workspace procède de même :

v=spf1 include:_spf.google.com -all

Dans les deux cas, l'include du fournisseur consomme plusieurs lookups à lui seul (il se décompose en sous-includes) : le budget de 10 n'est pas entamé de moitié, mais il n'est plus intact. Une entreprise en cohabitation — migration en cours, entités séparées — combine les deux dans un seul enregistrement :

v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all

C'est légitime et courant, mais le budget de lookups restant se réduit d'autant : chaque prestataire additionnel (emailing, facturation, CRM, support) devra y trouver sa place. Les cas particuliers — sous-domaines dédiés, connecteurs, routage hybride, décompte précis des lookups de chaque suite — sont traités dans notre guide SPF pour Microsoft 365 et Google Workspace.

Deux règles transversales pour tous les prestataires : n'ajoutez que l'include documenté officiellement par le fournisseur (les variantes glanées sur des forums sont la première source de doublons et de mécanismes morts), et ajoutez-le dans l'enregistrement existant — jamais dans un second enregistrement.

Bonnes pratiques pour un SPF durable

Un seul enregistrement SPF par domaine. La règle est absolue : s'il existe deux enregistrements TXT commençant par v=spf1, les destinataires renvoient permerror et les deux sont ignorés. Ce doublon naît presque toujours d'un ajout de prestataire fait à la hâte : on crée une nouvelle ligne au lieu de compléter l'existante. Tout nouveau mécanisme se fusionne dans l'enregistrement unique.

Visez -all, tolérez ~all en transition. Le qualificateur final est votre déclaration de politique : -all affirme que la liste est exhaustive et que le reste doit être rejeté ; ~all dit « probablement illégitime, mais laissez passer en marquant ». Le softfail est un état de chantier, utile le temps de fiabiliser l'inventaire des émetteurs — pas une destination. Quant à +all, il autorise la terre entière à émettre pour votre domaine et doit être corrigé dès qu'il est repéré. Les nuances entre ces variantes sont disséquées dans SPF -all ou ~all : quelle différence.

Couvrez aussi les domaines qui n'envoient rien. Un domaine parqué se protège avec la politique vide v=spf1 -all : aucun serveur n'est autorisé, l'usurpation devient détectable immédiatement.

Surveillez, ne supposez pas. Un enregistrement SPF vit : les prestataires changent, les équipes en ajoutent, les IP bougent. Les rapports agrégés DMARC sont le seul moyen de voir qui émet réellement au nom du domaine et où SPF échoue ; une revue périodique de l'enregistrement à leur lumière évite l'érosion silencieuse. En cas de doute immédiat, vérifier son enregistrement SPF ne prend que quelques minutes, et notre analyseur SPF/DMARC gratuit compte les lookups, détecte les doublons et note la posture complète du domaine en quelques secondes.

Pensez délivrabilité, pas seulement sécurité. Les grandes messageries exigent désormais une authentification correcte pour accepter le courrier en volume, et un SPF bancal pèse directement sur le placement en boîte de réception. Si vos messages légitimes atterrissent en spam malgré un SPF valide, les causes sont souvent ailleurs — réputation, volume, engagement — comme l'expliquent notre diagnostic emails en spam malgré SPF et DKIM et notre guide de délivrabilité Gmail.

FAQ

Combien de temps une modification SPF met-elle à s'appliquer ?

Le délai est celui de la propagation DNS : la valeur de TTL de l'enregistrement TXT, souvent entre 5 minutes et 24 heures. Les serveurs qui ont l'ancienne version en cache continuent de l'utiliser jusqu'à expiration. Avant une modification sensible (passage à -all, retrait d'un include), abaissez temporairement le TTL pour pouvoir revenir en arrière rapidement.

SPF s'applique-t-il automatiquement aux sous-domaines ?

Non. Contrairement à DMARC, SPF ne s'hérite pas : chaque sous-domaine qui émet du courrier — ou qui apparaît dans une identité HELO — a besoin de son propre enregistrement. Un sous-domaine sans SPF renvoie none, ce qui laisse le champ libre à l'usurpation. D'où l'intérêt de publier v=spf1 -all sur les sous-domaines qui n'envoient jamais rien.

Que se passe-t-il si mon domaine n'a aucun enregistrement SPF ?

Le résultat est none : le destinataire n'a aucun élément pour juger, et la plupart des grandes messageries pénalisent ou refusent aujourd'hui le courrier en volume non authentifié. Surtout, sans SPF ni DKIM, DMARC ne peut rien valider : la protection du domaine est inexistante. Publier un SPF est la première étape, jamais la dernière.

Peut-on avoir deux enregistrements SPF sur le même domaine ?

Non — c'est l'erreur classique. Deux enregistrements TXT commençant par v=spf1 produisent un permerror et l'invalidation des deux. Si un prestataire vous demande « d'ajouter son SPF », il faut fusionner son mécanisme dans l'enregistrement existant, sur une seule et même ligne logique.

SPF chiffre-t-il ou signe-t-il mes emails ?

Non plus. SPF est une pure liste d'autorisation d'adresses IP : il ne chiffre rien, ne signe rien et ne garantit pas l'intégrité du contenu. La preuve cryptographique qu'un message n'a pas été altéré relève de DKIM, et la cohérence avec l'adresse visible relève de DMARC — les trois sont complémentaires, pas interchangeables.

-all ou ~all : que choisir en pratique ?

~all pendant la phase d'inventaire, -all en régime de croisière. Si votre enregistrement est complet et vérifié depuis plusieurs semaines de rapports DMARC sans faux négatif, rien ne justifie de rester en softfail : -all rend votre politique opposable et prive les usurpateurs de la zone grise.