SPF

01 — DéfinitionQu'est-ce que SPF ?

Le SPF, pour Sender Policy Framework, est un mécanisme d'authentification des emails défini par la RFC 7208. Il repose sur un principe simple : publier, dans le DNS de votre domaine, la liste des serveurs autorisés à envoyer des emails en votre nom. Quand un serveur destinataire reçoit un message prétendant venir de votre domaine, il vérifie que l'adresse IP de l'expéditeur figure bien dans cette liste.

C'est le plus ancien des trois protocoles d'authentification email (SPF, DKIM, DMARC). Introduit en 2004 et standardisé en 2014, il reste une brique fondamentale : sans SPF, DMARC ne peut pas fonctionner correctement.

SPF ne protège pas tout. Il vérifie l'adresse d'enveloppe (Return-Path), pas celle visible dans le champ From: que voit l'utilisateur. Un attaquant peut donc passer SPF tout en affichant visuellement votre domaine. C'est précisément pour combler cette faille que DMARC a été inventé.

Considérer SPF seul comme une protection est une erreur répandue. SPF + DKIM + DMARC forment un trio indissociable : chacun comble les angles morts des deux autres.

02 — MécaniqueComment SPF fonctionne

Voici ce qui se passe quand un serveur destinataire reçoit un email prétendant venir de votredomaine.fr :

1. Le serveur extrait l'adresse IP de l'expéditeur (l'IP du serveur SMTP qui lui a envoyé le message).
2. Il extrait le domaine d'enveloppe (Return-Path, aussi appelé MAIL FROM en SMTP).
3. Il interroge le DNS pour récupérer l'enregistrement TXT commençant par v=spf1 sur ce domaine.
4. Il évalue cet enregistrement, en suivant les mécanismes dans l'ordre (include, a, mx, ip4, ip6, etc.).
5. Si l'IP d'origine correspond à un mécanisme : le résultat est pass. Si elle ne correspond à rien : le résultat dépend du qualificateur all final (pass, fail, softfail, neutral).
6. Ce résultat est ensuite utilisé par DMARC pour décider du traitement final de l'email.

Point essentiel : SPF ne vérifie pas l'adresse visible par l'utilisateur (champ From:). Il ne vérifie que l'enveloppe technique. C'est le rôle de DMARC d'exiger ensuite un alignement entre le domaine d'enveloppe vérifié par SPF et le domaine visible.

03 — SyntaxeComprendre un enregistrement SPF

Un enregistrement SPF typique ressemble à ceci :

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:192.0.2.10 ~all

Décomposition :

• v=spf1 — version du protocole. Toujours présent en premier, identique pour tous les domaines.
• include:domain — autorise les IPs déclarées dans le SPF d'un autre domaine. Le plus fréquent pour les services tiers : include:_spf.google.com pour Google Workspace, include:spf.protection.outlook.com pour Microsoft 365. Chaque include compte pour 1 lookup.
• ip4:x.x.x.x ou ip4:x.x.x.0/24 — autorise directement une IP ou une plage d'IPs IPv4. Ne compte pas dans la limite des 10 lookups.
• ip6:... — équivalent IPv6.
• a — autorise les IPs déclarées par l'enregistrement A du domaine (le ou les serveurs web). 1 lookup.
• mx — autorise les IPs des serveurs de messagerie déclarés par l'enregistrement MX. 1 lookup.
• exists:domain — autorise si l'enregistrement existe. Utilisé pour des macros avancées. 1 lookup.
• redirect=domain — délègue l'évaluation à un autre domaine. Alternative à include mais moins flexible.
• ~all, -all, etc. — qualificateur final (voir section suivante).

04 — QualificateursChoisir entre ~all, -all, ?all

Le qualificateur final définit ce qui se passe pour un email dont l'IP ne correspond à aucun mécanisme déclaré. Quatre options.

-all (fail) — strict

Rejet strict. Un email non listé est considéré comme frauduleux et doit être rejeté par le destinataire. C'est l'objectif cible une fois le déploiement stabilisé.

~all (softfail) — souple

Accepté mais marqué comme suspect (typiquement rangé dans le spam). Utile pendant la phase de déploiement, quand on n'est pas encore certain d'avoir listé toutes les sources d'envoi. Reste un signal utile pour DMARC.

?all (neutral) — sans avis

Déclare explicitement « je ne sais pas ». Équivaut à ne pas avoir de SPF pour les emails non listés. À éviter en production.

+all (pass) — tout autoriser

Autorise n'importe quel expéditeur à envoyer en votre nom. Ne jamais utiliser : cela désactive SPF complètement et laisse votre domaine librement usurpable.

Recommandation pratique

Commencer le déploiement en ~all pendant 1 à 3 mois, le temps d'analyser les rapports DMARC et d'identifier toutes les sources légitimes. Basculer ensuite en -all une fois la liste stabilisée.

05 — LimitesCe que SPF ne fait pas

SPF est une brique nécessaire mais largement insuffisante seule. Ses limitations sont importantes à comprendre.

• Ne vérifie pas le From: visible — SPF ne regarde que l'enveloppe (Return-Path), pas l'adresse affichée à l'utilisateur. Un attaquant peut envoyer depuis son propre domaine (qui passe SPF) tout en affichant visuellement votre domaine dans le champ From:. C'est exactement le trou que comble DMARC.
• Casse avec la redirection d'email — quand un email est transféré (redirection automatique, liste de diffusion), l'IP d'envoi devient celle du serveur intermédiaire, qui n'est pas dans votre SPF. Résultat : SPF échoue même pour des emails légitimes. DKIM résout ce problème car il survit au transit.
• Limite des 10 lookups — un SPF trop complexe (trop d'include) tombe en permerror et invalide toute la vérification.
• Ne signe pas le contenu — SPF ne garantit pas que le message n'a pas été modifié en transit. Seul DKIM apporte cette garantie cryptographique.
• Pas de rapports — SPF seul ne vous dit pas qui a essayé d'envoyer en votre nom. C'est DMARC qui apporte cette visibilité via ses rapports RUA et RUF.

06 — PiègesLes erreurs fréquentes

• Plusieurs enregistrements SPF — la tentation est grande d'ajouter un second enregistrement pour un nouveau service. Erreur : un domaine ne doit avoir qu'un seul enregistrement SPF. Toujours fusionner dans un seul.
• Dépassement des 10 lookups — chaque include, a, mx, exists compte. Un include qui lui-même en contient d'autres compte chaque sous-lookup. Les grands services (Salesforce, HubSpot) peuvent à eux seuls consommer 3-5 lookups. Vérifier avec un outil comme dmarcian SPF survey.
• Solution : SPF flattening — quand la limite est atteinte, certains services (Valimail, dmarcian, EasyDMARC) permettent de remplacer les include par les IPs correspondantes mises à jour dynamiquement.
• Oublier un service d'envoi — Calendly, Stripe, HubSpot, Typeform, Zendesk, Pipedrive, Gusto, Sendgrid, Mailjet… chaque outil qui envoie un email au nom de votre domaine doit être dans votre SPF. Sinon DMARC les bloquera.
• Mettre +all ou oublier all — sans qualificateur final, le comportement par défaut dépend des serveurs destinataires et devient imprévisible. Toujours terminer par ~all ou -all.
• Inclure Microsoft 365 avec la mauvaise syntaxe — la bonne valeur est include:spf.protection.outlook.com, pas include:outlook.com.
• Ne pas publier de SPF sur les sous-domaines inutilisés — un sous-domaine qui n'envoie jamais d'email devrait avoir un SPF v=spf1 -all pour empêcher son usurpation.

07 — DéploiementComment mettre en place SPF

08 — FAQQuestions fréquentes

Dois-je absolument avoir SPF ?

Oui. Sans SPF, la plupart des grands fournisseurs (Gmail, Yahoo, Microsoft) dégradent votre délivrabilité, voire refusent vos emails. Depuis février 2024, Gmail et Yahoo exigent SPF + DKIM + DMARC pour tout expéditeur envoyant plus de 5 000 messages/jour.

SPF fonctionne-t-il sans DMARC ?

Techniquement oui, SPF est antérieur à DMARC. Mais sans DMARC, les serveurs destinataires appliquent leurs propres règles plus ou moins strictes au résultat SPF. Le duo SPF + DMARC est recommandé, le trio SPF + DKIM + DMARC est la norme professionnelle.

Comment tester mon enregistrement SPF ?

Plusieurs outils gratuits : dig TXT votredomaine.fr en ligne de commande, MXToolbox SPF check, dmarcian SPF Survey (qui compte les lookups), ou envoyer un email vers mail-tester.com pour un rapport complet.

Pourquoi SPF casse-t-il avec la redirection ?

Quand un email est redirigé, l'IP d'envoi finale devient celle du serveur qui redirige, qui n'est pas dans votre SPF. SPF échoue alors même pour des emails parfaitement légitimes. Deux solutions : utiliser SRS (Sender Rewriting Scheme) côté serveur redirigeant, ou s'appuyer sur DKIM (qui lui survit aux redirections).

Mon domaine n'envoie pas d'email, dois-je quand même publier un SPF ?

Oui, explicitement : v=spf1 -all. Cela déclare qu'aucun serveur n'est autorisé à envoyer en votre nom. Sans cette déclaration, un attaquant peut usurper votre domaine pour du phishing. Particulièrement important pour les sous-domaines inutilisés.