Sécurité email

SPF : comprendre et configurer l'enregistrement qui protège vos emails

Équipe Cyber-Guard · 2026-10-14 · 7 min de lecture

SPF (Sender Policy Framework) est la plus ancienne des trois protections email, avec DKIM et DMARC. Son principe est simple : vous publiez dans votre DNS la liste des serveurs autorisés à envoyer des emails pour votre domaine, et les messageries qui reçoivent un email vérifient qu'il vient bien de l'un d'eux.

Simple sur le papier, SPF est pourtant l'enregistrement qui casse le plus souvent. Un service oublié, une limite technique dépassée, et vos propres emails partent en spam.

Ce que SPF vérifie, et ce qu'il ne vérifie pas

SPF contrôle l'adresse d'enveloppe de l'email, celle qui sert aux retours d'erreur (appelée Return-Path), et non l'adresse affichée dans le champ « De » que voit le destinataire. Un fraudeur peut donc passer SPF avec son propre domaine tout en affichant le vôtre.

C'est pour cela que SPF seul ne suffit pas : c'est DMARC qui exige que le domaine validé par SPF corresponde à celui affiché. Les deux vont ensemble, voir notre guide Comment configurer DMARC.

Lire un enregistrement SPF

v=spf1 include:_spf.google.com include:spf.votre-outil.com ip4:203.0.113.10 -all

v=spf1 : la version, obligatoire et toujours en premier.
include: : autorise les serveurs d'un service tiers (messagerie, newsletter, CRM). Le service vous donne la valeur exacte.
ip4: et ip6: : autorisent une adresse ou une plage précise, par exemple votre propre serveur.
a et mx : autorisent les serveurs désignés par les enregistrements A ou MX de votre domaine.
-all ou ~all : ce qu'il faut faire de tout le reste. -all signifie « refuser », ~all « accepter mais marquer comme suspect ».

N'utilisez jamais +all, qui autorise le monde entier à envoyer en votre nom, ni le mécanisme ptr, déconseillé par la norme.

Les trois règles qui évitent la plupart des pannes

Un seul enregistrement SPF par domaine

Si deux enregistrements TXT commencent par v=spf1, SPF est considéré comme invalide. C'est l'erreur classique quand un nouveau prestataire demande « d'ajouter son SPF » : il faut fusionner sa mention include: dans l'enregistrement existant, pas en créer un second.

Dix consultations DNS au maximum

Pour vérifier SPF, le serveur destinataire a le droit de faire au plus dix requêtes DNS. Chaque include:, a, mx et redirect= en consomme au moins une, et un include: peut lui-même en contenir d'autres. Au-delà de dix, SPF échoue en erreur permanente, comme s'il n'existait pas. Les mentions ip4:, ip6: et all ne comptent pas.

Pour rester sous la limite, retirez les services que vous n'utilisez plus. Méfiez-vous de « l'aplatissement » (remplacer les include: par les adresses IP qu'ils contiennent) : si le prestataire change ses serveurs, votre SPF devient faux sans que vous le sachiez.

Bien choisir la fin : -all ou ~all

Avec -all, un email venu d'un serveur non listé peut être refusé directement. Avec ~all, il est accepté mais marqué. Pendant la mise en place, ~all évite de bloquer un service oublié. Une fois tous vos services listés et DMARC en place, -all est le réglage le plus strict, et c'est celui que recommande CyberGuard.

Les cas particuliers à ne pas oublier

Les sous-domaines n'héritent pas du SPF du domaine principal. Si factures.votre-domaine.fr envoie des emails, il lui faut son propre enregistrement.
Un domaine qui n'envoie aucun email doit quand même être protégé : publiez v=spf1 -all, et une politique DMARC en p=reject.
Les emails transférés automatiquement depuis une autre boîte échouent souvent à SPF, puisque c'est le serveur de transfert qui les renvoie. C'est normal : DKIM, qui survit au transfert, prend alors le relais pour DMARC.

Vérifier votre SPF

Après chaque modification, attendez la propagation DNS, en général de quelques minutes à quelques heures, puis testez. CyberGuard vérifie votre SPF, votre DKIM et votre DMARC en 2 minutes et vous signale un enregistrement absent, souple ou mal formé.