Qu'est-ce que SPF, et comment autorise-t-il tes serveurs d'envoi ?

Quand un serveur reçoit un email qui prétend venir de ton domaine, il se pose une question très simple : est-ce que l'IP qui m'envoie ce message a le droit d'émettre pour ce domaine ? Sans réponse, tout le monde peut se faire passer pour toi. SPF — Sender Policy Framework, défini par la RFC 7208 — est la première brique qui donne une réponse. Tu publies dans ton DNS la liste des serveurs autorisés à émettre en ton nom, et le destinataire compare. Ce guide explique ce qu'est SPF, à quoi ressemble l'enregistrement, ce que veulent dire les mécanismes, le fameux piège des 10 lookups, et pourquoi SPF seul ne protège pas ce que ton destinataire voit vraiment.

Le problème que SPF résout

À l'origine, le protocole email ne vérifie rien. N'importe quel serveur, n'importe où sur Internet, peut ouvrir une connexion et déclarer « je porte du courrier de la part de ton-domaine.fr ». Rien ne l'en empêche, et rien ne prévient le destinataire. C'est cette absence de contrôle qui a rendu le spam et l'usurpation triviaux pendant des années.

SPF referme une partie de cette faille avec une idée toute simple : tu es le seul à contrôler ton DNS, donc tu es le seul à pouvoir y publier officiellement la liste de tes serveurs d'envoi. Le destinataire lit cette liste et vérifie que l'IP en face y figure. Si oui, SPF passe ; sinon, SPF échoue et le message devient suspect.

Ce qu'est vraiment SPF — et ce qu'il vérifie exactement

Un détail est crucial et presque toujours mal compris : SPF ne vérifie pas l'adresse From: que ton utilisateur lit dans son client mail. Il vérifie l'enveloppe du message — techniquement le MAIL FROM de la session SMTP, aussi appelé Return-Path. C'est l'adresse à laquelle les rebonds reviennent, et elle est souvent différente du From: visible.

Concrètement : un email peut afficher From: comptabilite@ton-entreprise.fr tout en ayant une enveloppe MAIL FROM: bounce@un-autre-domaine.com. SPF valide alors un-autre-domaine.com, pas ton-entreprise.fr. C'est exactement la brèche qu'un attaquant exploite, et c'est pourquoi SPF seul ne suffit jamais — on y revient plus bas. Retiens dès maintenant cette distinction enveloppe ≠ From: visible : elle explique la moitié des malentendus sur l'authentification email.

À quoi ressemble un enregistrement SPF

SPF est un unique enregistrement TXT publié à la racine de ton domaine. Voici un exemple typique pour une entreprise qui envoie via Google Workspace, SendGrid et un serveur maison :

ton-domaine.fr.  IN TXT
  "v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.10 -all"

Décortiquons-le :

• v=spf1 — la version. Tout enregistrement SPF commence par là ; c'est ainsi que le destinataire le reconnaît.
• include:_spf.google.com — délègue à Google : « tout serveur que Google déclare autorisé pour ce sous-domaine l'est aussi pour moi ».
• include:sendgrid.net — pareil pour SendGrid, ton prestataire d'emailing.
• ip4:203.0.113.10 — une IP précise, ton serveur maison, autorisée en dur.
• -all — le qualificatif final : tout ce qui n'est pas listé au-dessus est rejeté strictement.

Un seul enregistrement, une seule ligne (même si on l'affiche sur plusieurs pour la lisibilité). C'est déjà le premier piège : il n'en faut qu'un — on y revient.

Les mécanismes, un par un

L'intérieur d'un enregistrement SPF est une suite de mécanismes que le destinataire évalue de gauche à droite jusqu'à trouver une correspondance :

• include: — délègue l'autorisation à un autre domaine. C'est le mécanisme le plus courant : ton fournisseur (Google, Microsoft 365, SendGrid, Mailchimp…) publie son SPF, et tu l'importes. Tu n'as pas à connaître ses IP, qui changent : lui les tient à jour.
• ip4: / ip6: — autorise une adresse IP précise ou un bloc entier (ex. ip4:203.0.113.0/24). Idéal pour tes propres serveurs, dont l'IP est stable.
• a — autorise les IP présentes dans les enregistrements A (ou AAAA) du domaine. Pratique si ton serveur web envoie aussi du courrier.
• mx — autorise les IP de tes serveurs de messagerie entrante (les enregistrements MX). Utile quand la même machine reçoit et émet.
• le qualificatif final all — le filet de sécurité qui décide du sort de tout le reste.

Chaque mécanisme peut porter un qualificatif : + (autorise, par défaut), - (rejette), ~ (softfail), ? (neutre). En pratique on ne le voit que sur all, et le choix y est décisif :

• -all (fail strict) — tout ce qui n'est pas listé est rejeté. C'est la bonne cible : une posture claire et défendable.
• ~all (softfail) — « probablement pas légitime, mais laisse passer en marquant ». Utile en phase de déploiement, le temps de tout inventorier.
• ?all (neutre) — aucune opinion. Autant ne rien publier ; ça ne protège pas.
• +all — à ne JAMAIS publier. Cela autorise le monde entier à émettre pour ton domaine. C'est l'équivalent d'une porte grande ouverte. Si tu le vois quelque part, corrige-le tout de suite.

Pour le détail de chaque qualificatif et des cas limites, on a écrit un guide dédié : comprendre le mécanisme all en SPF.

Le piège des 10 lookups DNS

Voici l'erreur la plus fréquente, et la plus vicieuse parce qu'elle est silencieuse. La RFC 7208 impose que l'évaluation d'un enregistrement SPF ne déclenche pas plus de 10 résolutions DNS. Chaque include:, chaque a, chaque mx compte pour au moins une résolution — et un include peut lui-même en contenir d'autres, en cascade.

Additionne : Google Workspace consomme plusieurs lookups, ton prestataire marketing quelques-uns, ton outil de facturation encore, ton support client encore… et tu dépasses 10 sans t'en apercevoir. Au-delà, le destinataire renvoie un permerror (erreur permanente) : SPF échoue entièrement, comme s'il n'existait pas. Ton courrier légitime peut alors être marqué comme suspect.

Le piège est vicieux car l'enregistrement paraît correct et fonctionne tant que tu restes sous la barre — puis un jour tu ajoutes un prestataire de plus, tu franchis la limite, et tout casse d'un coup sans message d'erreur visible. On détaille le diagnostic et les causes dans SPF : trop de lookups DNS, et si tu veux comprendre le message d'erreur lui-même, ce qu'est un permerror SPF le prend en main pas à pas.

La solution s'appelle l'aplatissement (flattening) : tu remplaces des include: gourmands par les blocs ip4:/ip6: correspondants, résolus une fois pour toutes. Tu économises des lookups au prix d'une maintenance : si le prestataire change ses IP, tu dois régénérer. C'est un compromis à gérer, expliqué en détail dans notre guide sur l'aplatissement d'un enregistrement SPF.

Les pièges courants au-delà des lookups

Deux autres erreurs cassent SPF discrètement :

• Deux enregistrements SPF sur le même domaine. La RFC est formelle : il ne doit exister qu'un seul enregistrement TXT commençant par v=spf1. Si tu en publies un deuxième — souvent en ajoutant un prestataire sans toucher à l'existant — le destinataire renvoie un permerror et les deux sont ignorés. La règle : fusionne tout dans un enregistrement unique. Deux include supplémentaires vont dans la ligne existante, pas dans une nouvelle.
• +all par mégarde. On l'a dit, mais ça mérite répétition : c'est la pire configuration possible. Un +all (ou un all sans qualificatif restrictif dans certaines lectures) revient à n'avoir aucune protection.

Si tu ne sais pas dans quel état est ton domaine, ne devine pas : vérifie ton enregistrement SPF en quelques secondes. Et si tu jongles entre Microsoft 365 et Google Workspace, le cas particulier de la cohabitation des deux include est traité dans SPF pour Microsoft 365 et Google Workspace.

Un cas concret : Microsoft 365 et Google Workspace

Prenons une situation très fréquente. Une entreprise migre de Microsoft 365 vers Google Workspace mais garde temporairement les deux actifs. L'enregistrement devient :

ton-domaine.fr.  IN TXT
  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"

Chacun des deux include déclenche plusieurs résolutions DNS. À deux prestataires majeurs, tu es déjà à la moitié du budget de 10 lookups. Ajoute la facturation, l'emailing marketing et le support, et le permerror te guette. C'est le scénario typique où l'aplatissement d'un des deux include devient nécessaire — et où l'on comprend, très concrètement, pourquoi la limite de lookups SPF mérite qu'on la surveille avant qu'elle ne morde.

Pourquoi SPF seul ne suffit pas

Reviens à la distinction du début : SPF valide l'enveloppe (MAIL FROM / Return-Path), pas le From: visible. Un attaquant peut donc configurer un SPF parfait pour son propre domaine, passer le contrôle sans problème, et afficher ton domaine dans le From: que ton correspondant lit. SPF n'y voit rien : il n'a jamais regardé cette adresse.

C'est une limite structurelle, pas un bug. SPF fait exactement ce pour quoi il est conçu — vérifier qui a le droit d'émettre depuis une IP donnée pour un domaine d'enveloppe. Il ne dit rien sur la cohérence entre l'enveloppe et le From: affiché. Cette cohérence, on l'appelle l'alignement, et c'est DMARC qui l'exige.

Le trio complet fonctionne ainsi :

1. SPF — autorise les IP émettrices (côté enveloppe).
2. DKIM — attache une signature cryptographique au message, prouvant qu'il n'a pas été altéré et qu'il vient bien d'un domaine donné.
3. DMARC — relie SPF et DKIM au From: visible et impose l'alignement, puis dit au destinataire quoi faire en cas d'échec (none, quarantine, reject).

Autrement dit, SPF est nécessaire mais pas suffisant. C'est la fondation ; DKIM ajoute la preuve d'intégrité ; DMARC pose le toit qui protège enfin l'adresse que lit l'humain. Publier un bon SPF sans DMARC, c'est verrouiller une fenêtre en laissant la porte ouverte.

Ta feuille de route SPF

Pour poser un SPF propre et durable, procède dans cet ordre :

1. Inventorie tes émetteurs. Liste tout ce qui envoie en ton nom : messagerie, marketing, facturation, support, applis internes. On en oublie toujours — les rapports DMARC aident à les débusquer.
2. Publie un enregistrement unique commençant par v=spf1, avec un include: par prestataire et un ip4:/ip6: par serveur maison.
3. Compte tes lookups. Reste sous 10. Si tu dépasses, aplatis les include les plus gourmands.
4. Termine par -all dès que tu es sûr de ton inventaire (passe par ~all le temps de valider si tu préfères la prudence).
5. Ne publie jamais deux enregistrements ni +all.
6. Enchaîne sur DKIM puis DMARC — c'est le seul chemin vers une vraie protection.

Tu n'as pas à faire tout ça à l'aveugle. Lance une vérification gratuite et instantanée de la posture SPF, DKIM et DMARC de ton domaine avec notre analyseur DMARC gratuit : il te montre ton SPF actuel, compte tes lookups, repère les doublons et te donne une note claire. Et quand tu voudras passer de la surveillance à la protection réelle, Thomas, ton RSSI virtuel, nomme chaque émetteur, génère le DNS exact à coller et te dit quand durcir sans casser un seul email légitime.

Analyse ton domaine gratuitement → et vois où en est ton SPF en quelques secondes.