SPF (Sender Policy Framework)

Comment fonctionne le SPF

Le protocole SMTP (RFC 5321), qui régit l’envoi des emails depuis 1982, ne vérifie pas l’identité de l’expéditeur. N’importe quel serveur peut envoyer un email en prétendant venir de n’importe quel domaine. C’est cette faille qui permet le spoofing email et qui alimente la majorité des attaques de phishing.

SPF (Sender Policy Framework) a été conçu pour corriger ce problème. Le principe est simple : le propriétaire d’un domaine publie un enregistrement TXT dans sa zone DNS qui liste les serveurs autorisés à envoyer des emails en son nom. Le serveur destinataire peut alors vérifier si l’email provient d’un serveur légitime ou non.

Le mécanisme en détail

Prenons un exemple concret. Votre entreprise utilise le domaine exemple.fr et envoie ses emails via Microsoft 365.

1. Vous publiez dans le DNS de exemple.fr un enregistrement SPF : v=spf1 include:spf.protection.outlook.com ~all
2. Un serveur (IP 203.0.113.50) envoie un email avec l’adresse d’enveloppe contact@exemple.fr
3. Le serveur destinataire reçoit cet email et interroge le DNS de exemple.fr pour récupérer l’enregistrement SPF
4. Le DNS répond : v=spf1 include:spf.protection.outlook.com ~all
5. Le serveur destinataire vérifie si l’IP 203.0.113.50 fait partie des serveurs autorisés par Microsoft 365
6. Si oui : SPF pass — l’email est considéré comme légitime
7. Si non : SPF fail ou softfail — l’email est suspect

Tout ce processus est invisible pour l’utilisateur. Il se joue en quelques millisecondes entre les serveurs, avant même que l’email n’apparaisse dans la boîte de réception.

SPF vérifie l’enveloppe, pas l’adresse visible

Point technique qui change tout : SPF ne vérifie pas l’adresse “From” que l’utilisateur voit dans son client email. Il vérifie l’adresse d’enveloppe (Return-Path / MAIL FROM), celle qui est utilisée par les serveurs SMTP pour le routage du message.

Un attaquant peut donc envoyer un email avec sa propre adresse d’enveloppe (qui passe le SPF de son domaine) tout en affichant direction@votre-entreprise.fr dans le champ From visible. Le destinataire voit l’adresse usurpée, mais SPF ne détecte rien d’anormal.

C’est la raison pour laquelle SPF seul ne protège pas contre le spoofing. Il faut DMARC pour relier la vérification SPF à l’adresse From visible (on appelle ça l’alignement).

Structure d’un enregistrement SPF

Un enregistrement SPF est un enregistrement DNS de type TXT qui commence toujours par v=spf1. Chaque élément qui suit déclare un type de serveur autorisé. Voici les mécanismes les plus courants, définis dans la RFC 7208.

Les mécanismes

Mécanisme	Fonction	Exemple
include:domaine	Autorise les serveurs déclarés dans le SPF d’un autre domaine	include:spf.protection.outlook.com
ip4:adresse	Autorise une adresse IPv4 ou un bloc CIDR	ip4:203.0.113.0/24
ip6:adresse	Autorise une adresse IPv6	ip6:2001:db8::/32
a	Autorise l’IP pointée par l’enregistrement A du domaine	a
mx	Autorise les serveurs MX du domaine	mx
redirect=domaine	Remplace le SPF par celui d’un autre domaine	redirect=_spf.exemple.fr

Les qualifieurs (all)

La directive all termine l’enregistrement SPF et définit le traitement des serveurs qui ne correspondent à aucun mécanisme listé :

Qualifieur	Signification	Recommandation
~all	Softfail — accepter mais marquer comme suspect	Recommandé en phase de déploiement
-all	Hardfail — rejeter l’email	Recommandé une fois la configuration validée
?all	Neutre — aucune indication	Déconseillé (ne sert à rien)
+all	Pass — tout autoriser	Dangereux — ne jamais utiliser

Exemples d’enregistrements SPF courants

Hébergement email OVH uniquement :

v=spf1 include:mx.ovh.com ~all

Microsoft 365 :

v=spf1 include:spf.protection.outlook.com ~all

Google Workspace :

v=spf1 include:_spf.google.com ~all

Plusieurs services (Microsoft 365 + Mailchimp) :

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ~all

Configuration complète (OVH + Microsoft 365 + Google Workspace) :

v=spf1 include:mx.ovh.com include:spf.protection.outlook.com include:_spf.google.com ~all

Notez qu’il ne doit y avoir qu’un seul enregistrement SPF par domaine. Si vous utilisez plusieurs services, tous les include doivent figurer dans le même enregistrement TXT.

La limite des 10 lookups DNS

La RFC 7208 (section 4.6.4) impose une limite stricte : un maximum de 10 résolutions DNS (lookups) est autorisé lors de la vérification d’un enregistrement SPF. Au-delà, la vérification échoue avec une erreur PermError.

Quels mécanismes consomment des lookups

Chaque mécanisme qui nécessite une requête DNS supplémentaire compte comme un lookup :

Mécanisme	Coûte un lookup ?
include:	Oui (+ les lookups du SPF inclus)
a	Oui
mx	Oui
redirect=	Oui
ip4: / ip6:	Non

Le piège, c’est que les include sont récursifs. Quand vous écrivez include:spf.protection.outlook.com, le serveur doit résoudre le SPF de Microsoft, qui contient lui-même d’autres include. Un seul include:spf.protection.outlook.com consomme à lui seul 2 à 3 lookups.

Le problème en pratique

Une PME qui utilise Microsoft 365 pour l’email, Mailchimp pour le marketing, HubSpot pour le CRM et un système de ticketing atteint facilement 12 à 15 lookups. L’enregistrement SPF déborde et la vérification échoue systématiquement — ce qui revient à ne pas avoir de SPF du tout.

Calcul pour un cas typique :

Service	Include	Lookups consommés
Microsoft 365	include:spf.protection.outlook.com	~3
Mailchimp	include:servers.mcsv.net	~1
HubSpot	include:spf.hubspot.com	~2
Salesforce	include:_spf.salesforce.com	~2
Outil de ticketing	include:spf.zendesk.com	~2
Total		~10-12

Vous êtes déjà à la limite, et le moindre ajout de service provoque un PermError.

Solutions

SPF flattening : remplacer les include par les adresses IP réelles des serveurs d’envoi. Au lieu de include:spf.protection.outlook.com, vous listez directement les blocs IP de Microsoft. Les ip4: et ip6: ne consomment aucun lookup. L’inconvénient : si le fournisseur change ses IP (ce qui arrive), votre SPF devient obsolète. Des services de SPF flattening dynamique gèrent cette mise à jour automatiquement.

Sous-domaines dédiés : envoyer les emails marketing depuis marketing.exemple.fr et les emails transactionnels depuis transac.exemple.fr. Chaque sous-domaine a son propre enregistrement SPF avec sa propre limite de 10 lookups. C’est la solution la plus propre et celle recommandée par les principaux fournisseurs.

Consolider les services : si vous utilisez un service qui ne fait que relayer des emails via un autre (ex : un CRM qui envoie via votre Microsoft 365), vous n’avez pas besoin de deux include. Seul le serveur réellement utilisé pour l’envoi doit figurer dans le SPF.

SPF seul ne suffit pas

SPF corrige une partie du problème d’authentification email, mais il présente trois limites structurelles qui expliquent pourquoi il doit être complété par DKIM et DMARC.

1. SPF ne vérifie pas l’adresse visible

Comme expliqué plus haut, SPF vérifie l’adresse d’enveloppe (Return-Path), pas le champ From que l’utilisateur voit. Un attaquant peut envoyer un email depuis son propre serveur (avec un Return-Path qu’il contrôle et qui passe SPF) tout en affichant l’adresse de votre directeur général dans le champ From. Le destinataire voit dg@votre-entreprise.fr et ne se doute de rien.

2. SPF casse avec le transfert d’email

Quand un destinataire configure un transfert automatique de son email, le message est réexpédié depuis un serveur intermédiaire. Ce serveur n’est pas dans l’enregistrement SPF du domaine d’origine. Résultat : l’email légitime échoue au contrôle SPF. C’est un problème courant avec les redirections d’anciennes adresses email ou les listes de diffusion.

3. SPF ne prouve pas l’intégrité du message

SPF vérifie d’où vient l’email, mais pas si le contenu a été modifié en transit. Un serveur intermédiaire pourrait altérer le corps du message ou les en-têtes sans que SPF ne détecte quoi que ce soit.

Le trio SPF + DKIM + DMARC

C’est la combinaison des trois protocoles qui offre une protection réelle :

• SPF déclare les serveurs autorisés à envoyer pour votre domaine
• DKIM signe cryptographiquement chaque email sortant, ce qui prouve que le message n’a pas été altéré et identifie le domaine signataire
• DMARC vérifie l’alignement entre l’adresse From visible et les domaines vérifiés par SPF ou DKIM, puis applique une politique (accepter, mettre en quarantaine ou rejeter)

Avec un DMARC en p=reject, SPF correctement configuré et DKIM actif, l’usurpation de votre domaine exact devient impossible. C’est le standard recommandé par l’ANSSI et par Google (qui exige DMARC pour les expéditeurs de plus de 5 000 emails/jour depuis février 2024).

Pour aller plus loin : notre guide Configurer SPF, DKIM et DMARC détaille la mise en place complète étape par étape.

Configurer SPF étape par étape

1. Inventorier tous les services d’envoi

Avant de toucher au DNS, listez tous les services et serveurs qui envoient des emails pour votre domaine. Pas seulement le serveur email principal — pensez aussi aux :

• Plateforme email principale (Microsoft 365, Google Workspace, OVH)
• Outil de marketing email (Mailchimp, Sendinblue/Brevo, HubSpot)
• CRM qui envoie des emails (Salesforce, Pipedrive, HubSpot)
• Système de ticketing (Zendesk, Freshdesk)
• Outil de facturation (Pennylane, Qonto, Tiime)
• Application métier (ERP, plateforme SaaS interne)
• Serveur SMTP interne (si vous en avez encore un)

Chaque service oublié dans le SPF verra ses emails échouer à la vérification. C’est la source d’erreur numéro un.

2. Récupérer les directives SPF de chaque service

Chaque fournisseur publie dans sa documentation la directive include à ajouter. Quelques exemples courants :

Service	Directive SPF
Microsoft 365	include:spf.protection.outlook.com
Google Workspace	include:_spf.google.com
OVH	include:mx.ovh.com
Mailchimp	include:servers.mcsv.net
Sendinblue/Brevo	include:spf.sendinblue.com
HubSpot	include:spf.hubspot.com
Salesforce	include:_spf.salesforce.com
Zendesk	include:mail.zendesk.com

Si un service fournit une adresse IP plutôt qu’un domaine d’include, utilisez ip4: ou ip6: (ces mécanismes ne consomment pas de lookup DNS, ce qui est un avantage).

3. Construire l’enregistrement SPF

Assemblez toutes les directives dans un seul enregistrement TXT. L’ordre des mécanismes n’a pas d’importance technique, mais par convention on commence par les services principaux.

Exemple pour une PME utilisant Microsoft 365 et Brevo :

v=spf1 include:spf.protection.outlook.com include:spf.sendinblue.com ~all

Vérifiez que le total ne dépasse pas 10 lookups DNS. Si c’est le cas, envisagez d’utiliser des sous-domaines dédiés pour le marketing ou les emails transactionnels.

4. Ajouter l’enregistrement dans votre zone DNS

Connectez-vous à l’interface de gestion DNS de votre registrar (OVH, Cloudflare, Gandi, etc.) et ajoutez un enregistrement TXT sur la racine du domaine (@) avec votre enregistrement SPF complet. Utilisez un TTL de 3600 secondes (1 heure).

5. Vérifier la propagation

Après la modification, attendez quelques minutes (jusqu’à une heure selon le TTL précédent) puis vérifiez :

En ligne de commande :

dig TXT exemple.fr +short

ou

nslookup -type=txt exemple.fr

Vous devez voir votre enregistrement SPF dans la réponse.

Vérifiez votre SPF, DKIM et DMARC en une seule analyse avec notre vérificateur de sécurité email. L’outil détecte les erreurs de configuration, les lookups excessifs et les services manquants.

6. Surveiller avec les rapports DMARC

Une fois le SPF en place, configurez DMARC avec l’option de reporting (rua=) pour recevoir des rapports quotidiens. Ces rapports vous montrent quels serveurs envoient des emails pour votre domaine et si la vérification SPF passe ou échoue. C’est le seul moyen fiable de détecter un service oublié ou une tentative d’usurpation.

Erreurs courantes de configuration SPF

Plusieurs enregistrements SPF sur le même domaine

La RFC 7208 est formelle : un seul enregistrement SPF est autorisé par domaine. Si votre zone DNS contient deux enregistrements TXT commençant par v=spf1, le résultat est un PermError et la vérification échoue. C’est une erreur fréquente quand deux personnes configurent le DNS séparément — le prestataire email ajoute un SPF, puis le prestataire marketing ajoute le sien.

La solution : fusionnez les deux enregistrements en un seul, en regroupant tous les include.

Dépasser la limite des 10 lookups

Déjà traité en détail plus haut. Symptôme : vos emails passent parfois et échouent parfois, ou vous voyez SPF PermError dans les en-têtes. Utilisez un outil de validation SPF pour compter vos lookups avant de publier l’enregistrement.

Passer à -all trop tôt

Le hardfail (-all) demande aux serveurs destinataires de rejeter tout email non autorisé. Si vous avez oublié un service d’envoi dans votre SPF (une application de facturation, un outil RH qui envoie des notifications), ses emails seront rejetés silencieusement. Vos fournisseurs ou clients ne recevront pas certains emails et personne ne vous préviendra.

L’approche recommandée : déployez avec ~all (softfail), analysez les rapports DMARC pendant 4 à 8 semaines pour vérifier que tous les flux sont couverts, puis passez à -all en confiance.

Oublier un service d’envoi

C’est l’erreur la plus courante et la plus difficile à détecter. Votre directeur commercial utilise un CRM qui envoie des emails à vos prospects depuis votre-domaine.fr. Le CRM n’est pas dans le SPF. Résultat : tous ses emails échouent au contrôle SPF et finissent en spam chez vos prospects. Personne ne s’en rend compte pendant des semaines parce que le commercial ne vérifie pas ses taux de livraison.

Prévention : faites le tour de tous les départements (commercial, marketing, support, comptabilité, RH) et demandez quels outils envoient des emails. Complétez avec les rapports DMARC qui listent exhaustivement les serveurs qui envoient pour votre domaine.

Ne pas configurer SPF sur les sous-domaines

Si vous utilisez marketing.votre-domaine.fr ou support.votre-domaine.fr pour envoyer des emails, ces sous-domaines ont besoin de leur propre enregistrement SPF. L’enregistrement SPF du domaine principal ne s’applique pas automatiquement aux sous-domaines.

Inversement, si vous n’utilisez pas un sous-domaine pour l’email, publiez un enregistrement SPF vide pour le bloquer :

v=spf1 -all

Cela empêche un attaquant d’usurper un sous-domaine que vous ne surveillez pas.

Comment nophi.sh vérifie votre SPF

Le vérificateur de sécurité email de nophi.sh analyse la configuration DNS de votre domaine en quelques secondes. L’outil vérifie :

• La présence d’un enregistrement SPF et sa syntaxe
• Le nombre de lookups DNS et le risque de dépassement de la limite de 10
• La couverture des services d’envoi déclarés
• Le qualifieur all et le niveau de protection associé
• La configuration DKIM sur les sélecteurs courants (10 sélecteurs testés)
• La politique DMARC et le niveau d’application (none, quarantine, reject)
• La présence d’un enregistrement BIMI pour l’affichage du logo de marque

Le résultat est un score de A à F avec des recommandations concrètes pour chaque point. Si votre SPF est absent, mal configuré ou dépasse les 10 lookups, l’outil vous explique exactement ce qu’il faut corriger et comment le faire.

Testez la sécurité email de votre domaine maintenant — résultat en 30 secondes, aucune inscription requise.

Pour une mise en place complète de SPF, DKIM et DMARC sur votre domaine, consultez notre guide pas à pas.