SPF (Sender Policy Framework) est le premier rempart de l’authentification email. Il permet de déclarer dans votre DNS quels serveurs sont autorisés à envoyer des emails pour votre domaine. Simple en apparence, il cache des subtilités qui piègent même les admins expérimentés.
À quoi sert SPF, concrètement ?
Quand un serveur de réception reçoit un email de contact@votredomaine.com, il se pose une question : “Ce serveur a-t-il le droit d’envoyer pour ce domaine ?”
Pour répondre, il consulte l’enregistrement SPF de votredomaine.com dans le DNS. Cet enregistrement liste les IP et serveurs autorisés.
Sans SPF : n’importe quel serveur peut prétendre envoyer pour vous. C’est la porte ouverte au spoofing.
Avec SPF : seuls les serveurs que vous avez explicitement autorisés passent la vérification.
Anatomie d’un enregistrement SPF
Un enregistrement SPF est un record DNS de type TXT placé à la racine de votre domaine :
v=spf1 include:_spf.google.com include:spf.sendinblue.com ip4:203.0.113.50 -all
Décortiquons chaque partie :
| Élément | Rôle |
|---|---|
v=spf1 | Version du protocole (obligatoire, toujours en premier) |
include: | Autorise les serveurs déclarés dans le SPF d’un autre domaine |
ip4: / ip6: | Autorise une IP ou un bloc CIDR spécifique |
a | Autorise l’IP pointée par le record A de votre domaine |
mx | Autorise les IP de vos serveurs MX |
redirect= | Redirige vers le SPF d’un autre domaine (remplace tout) |
-all | Rejeter tout ce qui ne correspond pas (fail) |
~all | Marquer comme suspect (softfail) |
?all | Neutre, aucun avis |
Les qualificateurs
Chaque mécanisme peut être préfixé par un qualificateur :
+(pass, par défaut), autorisé-(fail), rejeté~(softfail), suspect, accepté mais marqué?(neutral), aucune indication
Bonne pratique : utilisez toujours -all en production. Le ~all est un compromis acceptable pendant la phase de déploiement.
La limite des 10 lookups DNS
C’est le piège le plus courant. La RFC 7208 impose une limite stricte : un enregistrement SPF ne peut pas provoquer plus de 10 résolutions DNS.
Chaque include:, a, mx, redirect et exists compte pour un lookup. Les ip4: et ip6: ne comptent pas (ce sont des valeurs statiques).
Exemple qui dépasse la limite
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:spf.sendinblue.com include:servers.mcsv.net include:_spf.salesforce.com include:mail.zendesk.com include:spf.freshdesk.com -all
Ce record semble correct, mais chaque include: peut lui-même contenir des include: imbriqués. Google à lui seul déclenche 3-4 lookups. Au total, vous dépassez facilement 10.
Conséquence : permerror, le SPF est invalide, les emails échouent la vérification.
Solutions
- Remplacez les
include:par desip4:/ip6:pour les services dont les IP sont stables - Utilisez un service de “flattening” qui résout les
include:en IP à intervalles réguliers - Dédiez un sous-domaine par service (
marketing.votredomaine.compour Mailchimp, etc.)
Vérifiez le nombre de lookups de votre SPF avec notre SPF Checker gratuit, il affiche le détail de chaque résolution.
Configuration pas à pas
1. Inventoriez vos sources d’envoi
Listez tous les services qui envoient des emails pour votre domaine :
- Votre serveur mail (Exchange, Postfix, etc.)
- Services marketing (Mailchimp, Brevo, HubSpot…)
- Services transactionnels (SendGrid, SES, Postmark…)
- CRM (Salesforce, Pipedrive…)
- Support (Zendesk, Freshdesk…)
Un audit Sender Audit gratuit vous montre automatiquement toutes les sources détectées.
2. Construisez votre enregistrement
Pour chaque service, trouvez le mécanisme SPF à ajouter (généralement dans leur documentation). Assemblez le tout :
v=spf1 include:_spf.google.com include:spf.sendinblue.com ip4:203.0.113.50 -all
Outil gratuit : notre SPF Generator vous aide à construire votre record et vérifie automatiquement la limite de 10 lookups.
3. Publiez dans votre DNS
Ajoutez un record TXT à la racine de votre domaine (@). Attention : il ne doit y avoir qu’un seul enregistrement SPF par domaine. Si vous en avez déjà un, modifiez-le plutôt que d’en ajouter un second.
4. Testez
Utilisez le SPF Checker pour valider :
- La syntaxe est correcte
- Le nombre de lookups est ≤ 10
- Tous vos services sont inclus
- Le qualificateur final est
-all
SPF et DMARC : le lien
SPF seul ne suffit pas. Pour que SPF contribue à DMARC, il faut que le domaine du Return-Path (enveloppe) s’aligne avec le domaine du From: (en-tête visible).
Beaucoup de services tiers utilisent leur propre domaine comme Return-Path, dans ce cas, SPF passe mais DMARC échoue sur l’alignement SPF. C’est pourquoi DKIM est indispensable en complément.
Pour comprendre comment tout s’articule, consultez notre guide sur DMARC.
Erreurs courantes
- Plusieurs enregistrements SPF sur le même domaine → invalide
- Dépasser 10 lookups →
permerror - Utiliser
+all→ autorise tout le monde (pire que pas de SPF) - Oublier un service → ses emails échouent SPF
- Ne pas maintenir le record → un service arrêté laisse des includes inutiles qui gaspillent des lookups
Allez plus loin
- Configurer DKIM, l’autre pilier de l’authentification
- Configurer DMARC, lier SPF et DKIM ensemble
- Comprendre les blacklists, quand la réputation tourne mal
- SPF Generator, créez votre record en quelques clics
- Audit gratuit, vérifiez tout en 30 secondes
Des questions ? Rejoignez la communauté sur Matrix.