SPF — Sender Policy Framework

Norme Internet Authentification par email Obsoletes RFC 4408 Published March 2026

ELI5: Imaginez que votre entreprise dispose d'un papier à en-tête officiel. SPF, c'est comme publier une liste des imprimantes autorisées à imprimer sur votre papier à en-tête. Quand quelqu'un reçoit une lettre prétendant venir de vous, il peut vérifier si elle provient d'une de vos imprimantes approuvées. Si ce n'est pas le cas, il sait que c'est probablement un faux.

Pourquoi cette RFC existe

SMTP a été conçu au début des années 1980 sans vérification d'expéditeur intégrée. N'importe quel serveur peut prétendre envoyer du courrier à partir de n'importe quel domaine — il n'y a rien dans le protocole de base pour l'empêcher. Cela a rendu l'usurpation d'adresse e-mail triviale : les spammeurs et les phisheurs pouvaient forger l'adresse d'expéditeur d'enveloppe pour usurper l'identité de banques, de collègues ou de toute marque de confiance.

SPF (Sender Policy Framework), standardisé dans la RFC 7208, résout ce problème en permettant aux propriétaires de domaines de publier un enregistrement DNS TXT qui liste explicitement les adresses IP et les serveurs autorisés à envoyer du courrier pour leur domaine. Les serveurs de courrier récepteurs interrogent cet enregistrement pendant la transaction SMTP et peuvent rejeter ou signaler les messages provenant de sources non autorisées.

La RFC 7208 a rendu obsolète la RFC 4408 expérimentale antérieure, promouvant SPF au statut de norme Internet complète avec des règles de traitement clarifiées et des exigences plus strictes pour les limites de recherche DNS.

Comment ça fonctionne

SPF fonctionne au niveau de l'enveloppe, non au niveau de l'en-tête du message. Le domaine vérifié est celui de la commande MAIL FROM (également appelé Return-Path ou expéditeur d'enveloppe), et non l'en-tête From: que les utilisateurs voient.

Le flux de vérification SPF

Un serveur d'envoi se connecte au récepteur et émet MAIL FROM:<user@example.com>.
Le récepteur extrait le domaine example.com de l'expéditeur d'enveloppe.
Le récepteur interroge DNS pour un enregistrement TXT au example.com commençant par v=spf1.
Le récepteur évalue les mécanismes de l'enregistrement SPF par rapport à l'adresse IP de connexion.
Le résultat est l'un de : pass, fail, softfail, neutral, none, temperror, ou permerror.

Exemple de transaction SMTP

# Le serveur d'envoi 198.51.100.25 se connecte
S: 220 mx.receiver.com ESMTP ready
C: EHLO mail.example.com
S: 250-mx.receiver.com Hello
S: 250 OK
C: MAIL FROM:<alice@example.com>
# Le récepteur vérifie maintenant : est-ce que l'enregistrement SPF de example.com autorise 198.51.100.25 ?
# Recherche DNS : example.com TXT "v=spf1 ip4:198.51.100.0/24 -all"
# 198.51.100.25 correspond à ip4:198.51.100.0/24 => résultat : pass
S: 250 OK
C: RCPT TO:<bob@receiver.com>
S: 250 OK

Détails techniques clés

Syntaxe de l'enregistrement SPF

Un enregistrement SPF est un enregistrement DNS TXT qui commence par la balise de version v=spf1 suivie d'une série de mécanismes et d'un qualificateur facultatif pour chacun. L'enregistrement est évalué de gauche à droite ; le premier mécanisme qui correspond détermine le résultat.

example.com. IN TXT "v=spf1 ip4:198.51.100.0/24 ip6:2001:db8::/32 include:_spf.mailertogo.com include:_spf.google.com -all"

Mécanismes

Mécanisme	Description
`ip4:<range>`	Correspond si l'IP de l'expéditeur se trouve dans la plage CIDR IPv4 donnée.
`ip6:<range>`	Correspond si l'IP de l'expéditeur se trouve dans la plage CIDR IPv6 donnée.
`a`	Correspond si l'IP de l'expéditeur est égale à un enregistrement A/AAAA du domaine.
`mx`	Correspond si l'IP de l'expéditeur est égale à un enregistrement A/AAAA de l'un des hôtes MX du domaine.
`include:<domain>`	Évalue récursivement l'enregistrement SPF d'un autre domaine. Un `pass` du domaine inclus compte comme une correspondance.
`exists:<domain>`	Correspond si un enregistrement DNS A existe pour le domaine donné (utilisé pour les macros avancées).
`redirect=<domain>`	Modificateur : remplace la vérification SPF actuelle entièrement par un enregistrement d'un autre domaine.
`all`	Correspond à tout. Généralement utilisé à la fin de l'enregistrement comme `-all` ou `~all`.

Qualificateurs

Qualificateur	Résultat	Signification
`+` (défaut)	pass	Expéditeur autorisé
`-`	fail	Non autorisé — rejeter le message
`~`	softfail	Probablement non autorisé — accepter mais signaler
`?`	neutral	Aucune assertion faite

La limite de 10 recherches

Pour prévenir les abus DNS, la RFC 7208 stipule que l'évaluation SPF ne doit pas nécessiter plus de 10 recherches DNS qui résultent en résolution de mécanisme. Les mécanismes qui déclenchent des recherches sont : include, a, mx, exists, redirect, et ptr (déprécié). Les mécanismes bruts ip4 et ip6 ne comptent pas. Dépasser 10 recherches produit un résultat permerror, ce qui signifie généralement aucune protection SPF.

La limite de recherche MX

De plus, le mécanisme mx ne doit pas résulter en plus de 10 noms MX à interroger, et chacun d'entre eux ne doit pas se résoudre en plus de 10 adresses A/AAAA. Le mécanisme ptr est explicitement déconseillé.

Expansion de macros

SPF prend en charge les macros qui se développent en valeurs spécifiques au contexte pendant l'évaluation. Les macros courantes incluent %{s} (expéditeur), %{l} (partie locale), %{d} (domaine), et %{i} (adresse IP). Celles-ci sont utilisées principalement dans les mécanismes exists: pour les politiques complexes par utilisateur ou par IP.

Exemples d'enregistrements DNS

Basique : plage d'IP unique

example.com. IN TXT "v=spf1 ip4:203.0.113.0/24 -all"

Typique : ESP tiers + Google Workspace

example.com. IN TXT "v=spf1 include:_spf.mailertogo.com include:_spf.google.com -all"

Domaine qui n'envoie pas d'e-mail

parked-domain.com. IN TXT "v=spf1 -all"

Utilisation de redirect

subdomain.example.com. IN TXT "v=spf1 redirect=example.com"

Erreurs courantes

Enregistrements SPF multiples : Un domaine doit avoir exactement un enregistrement SPF TXT. La publication de deux en entraîne un permerror. Si vous devez combiner des sources, fusionnez-les en un seul enregistrement.
Dépassement de la limite de 10 recherches : Chaque include: compte pour une recherche, et les propres mécanismes de l'enregistrement inclus comptent vers le total. Les chaînes d'inclusions provenant de plusieurs ESP épuisent rapidement la limite. Aplatissez votre enregistrement ou utilisez des sous-domaines.
Utilisation de ~all au lieu de -all : Softfail (~all) indique aux récepteurs que le message est suspect mais qu'ils ne doivent pas le rejeter. Pour une protection forte (et pour activer l'application de DMARC), utilisez -all.
Oublier le domaine Return-Path : SPF vérifie l'expéditeur d'enveloppe, non l'en-tête From:. Si votre ESP utilise son propre domaine Return-Path, l'enregistrement SPF de votre domaine est irrelevant pour les vérifications SPF. Vous avez besoin soit d'un alignement Return-Path personnalisé, soit de DKIM + DMARC.
Utilisation du mécanisme ptr déprécié : La RFC 7208 décourage explicitement ptr car il est lent, peu fiable et crée une charge sur l'infrastructure DNS inversée.
Utilisation de type SPF (99) : Le type d'enregistrement DNS SPF dédié a été défini dans la RFC 4408 mais déprécié dans la RFC 7208. Utilisez toujours les enregistrements TXT.

Impact sur la délivrabilité

SPF est l'un des trois piliers de l'authentification e-mail (aux côtés de DKIM et DMARC). Son impact sur la délivrabilité est important :

Requis par les principaux fournisseurs : Gmail, Yahoo, Microsoft et Apple évaluent tous SPF. Depuis février 2024, Gmail et Yahoo exigent que SPF ou DKIM passent pour tous les expéditeurs, et les deux pour les expéditeurs en masse.
Alignement DMARC : SPF devient beaucoup plus puissant lorsqu'il est associé à DMARC, qui vérifie que le domaine authentifié par SPF s'aligne avec le domaine de l'en-tête From:. Sans DMARC, SPF seul ne peut pas empêcher l'usurpation d'identité de l'en-tête from.
Le transfert casse SPF : Quand un message est transféré via une liste de diffusion ou une règle .forward, l'IP d'envoi change mais l'expéditeur d'enveloppe reste souvent le même. Cela cause l'échec de SPF pour les messages légitimes. C'est l'une des raisons pour lesquelles DKIM et ARC existent.
Signal de réputation : Un enregistrement SPF correctement configuré (avec -all) signale aux récepteurs que vous prenez la sécurité du courrier électronique au sérieux et rend plus difficile pour les acteurs malveillants d'abuser de votre domaine.