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

À quoi ressemble un enregistrement SPF

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

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

Dans le détail :

• 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, le prestataire d'emailing.
• ip4:203.0.113.10 — une IP précise, le 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 : le fournisseur (Google, Microsoft 365, SendGrid, Mailchimp…) publie son SPF, qu'il suffit d'importer. Inutile de 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 les serveurs maison, dont l'IP est stable.
• a — autorise les IP présentes dans les enregistrements A (ou AAAA) du domaine. Pratique quand le serveur web envoie aussi du courrier.
• mx — autorise les IP des 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 le domaine. C'est l'équivalent d'une porte grande ouverte. Repéré quelque part, il se corrige 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.

L'addition monte vite : Google Workspace consomme plusieurs lookups, le prestataire marketing quelques-uns, l'outil de facturation encore, le support client encore… et la barre des 10 est franchie sans que personne s'en aperçoive. Au-delà, le destinataire renvoie un permerror (erreur permanente) : SPF échoue entièrement, comme s'il n'existait pas. Le courrier légitime peut alors être marqué comme suspect.

Le piège est vicieux car l'enregistrement paraît correct et fonctionne tant que le total reste sous la barre — puis un jour un prestataire de plus s'ajoute, la limite est franchie, 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 pour 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) : les include: gourmands sont remplacés par les blocs ip4:/ip6: correspondants, résolus une fois pour toutes. L'économie de lookups se paie en maintenance : si le prestataire change ses IP, il faut 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. Dès qu'un deuxième est publié — souvent en ajoutant un prestataire sans toucher à l'existant — le destinataire renvoie un permerror et les deux sont ignorés. La règle : tout fusionner 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.

Dans le doute sur l'état réel d'un domaine, mieux vaut vérifier que deviner : contrôler son enregistrement SPF prend quelques secondes. Et pour qui jongle 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

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

exemple.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, la moitié du budget de 10 lookups est déjà consommée. S'y ajoutent la facturation, l'emailing marketing et le support, et le permerror 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

Retour à 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 le domaine d'une victime dans le From: que le 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.

La feuille de route SPF

Pour poser un SPF propre et durable, l'ordre est le suivant :

1. Inventorier les émetteurs. Lister tout ce qui envoie au nom du domaine : messagerie, marketing, facturation, support, applis internes. On en oublie toujours — les rapports DMARC aident à les débusquer.
2. Publier un enregistrement unique commençant par v=spf1, avec un include: par prestataire et un ip4:/ip6: par serveur maison.
3. Compter les lookups. Rester sous 10. Au-delà, aplatir les include les plus gourmands.
4. Terminer par -all dès que l'inventaire est sûr (avec un passage par ~all le temps de valider, si la prudence prime).
5. Ne jamais publier deux enregistrements ni +all.
6. Enchaîner sur DKIM puis DMARC — c'est le seul chemin vers une vraie protection.

Rien de tout cela ne se fait à l'aveugle. Une vérification gratuite et instantanée de la posture SPF, DKIM et DMARC d'un domaine est accessible via notre analyseur DMARC gratuit : il montre le SPF actuel, compte les lookups, repère les doublons et rend une note claire. Et au moment de passer de la surveillance à la protection réelle, Thomas, le RSSI virtuel, nomme chaque émetteur, génère le DNS exact à coller et indique quand durcir sans casser un seul email légitime.

Analyser un domaine gratuitement et voir où en est son SPF en quelques secondes.