Qu’est-ce que le protocole SPF et comment fonctionne-t-il ?

25 septembre 2026

Votre entreprise envoie un email parfaitement légitime. Pourtant, à l’arrivée, le serveur de messagerie du destinataire se pose une question : qui prouve que cet expéditeur a réellement le droit d’envoyer ce message au nom de ce domaine ?

C’est là qu’intervient le SPF, ou Sender Policy Framework. Ce protocole d’authentification permet au propriétaire d’un domaine d’indiquer, via un enregistrement TXT dans son DNS, quels serveurs et quelles adresses IP sont autorisés à envoyer des mails en son nom. À la réception, le serveur peut alors vérifier cette politique SPF et identifier plus facilement un envoi légitime, une erreur de configuration ou une tentative d’usurpation.

Le SPF constitue donc une première ligne de protection contre le spam, le phishing et l’utilisation frauduleuse de votre identité. Il joue également un rôle important dans la sécurité, la réputation de votre domaine et la délivrabilité de vos campagnes email.

SPF (pour Sender Policy Framework) est un protocole d’authentification, comme DKIM ou DMARC. Il permet aux serveurs de réception des emails que vous envoyez de vous identifier comme expéditeur légitime, et donc de limiter l’envoi global de spam dans le monde. Surtout, ce processus d’authentification limite les risques de phishing (ou hameçonnage, en bon français), puisque SPF associe votre nom de domaine d’envoi à des adresses IP spécifiques, rendant l’usurpation d’identité beaucoup plus compliquée.

Le protocole SPF est donc un outil essentiel pour toute organisation qui utilise l’email comme canal de communication avec ses clients. Après tout, vous voulez que vos courriels soient acceptés par les boîtes de réception vers lesquelles vous envoyez. Mais SPF est bien plus que ça et répond d’abord à un besoin concret : celui d’échanges plus sûrs sur Internet.

SPF autorise un ou plusieurs expéditeurs, identifiés par des adresses IP autorisées, à envoyer des emails depuis un nom de domaine ou sous-domaine donné. Non seulement ce protocole facilite la tâche des serveurs de réception, puisqu’ils savent qui peut envoyer des emails, mais en plus il limite les possibilités de phishing.

Comme l’enregistrement SPF intègre la liste des adresses IP autorisées à envoyer des emails depuis un nom de domaine donné, il indique que vous possédez bien le domaine à partir duquel vous envoyez. Si une adresse IP qui envoie au nom de votre domaine n’est pas listée dans l’entrée SPF de ce domaine, cette IP sera considérée comme illégitime par le serveur de destination.

C’est aussi pour cette raison que l’utilisation d’adresses fournies par les webmails grand public comme Gmail, Microsoft Outlook ou Yahoo Mail pour effectuer des envois de masse est plus que déconseillée. Non seulement ces fournisseurs limitent ce type de campagnes, mais en plus, de votre côté, vous ne pourrez pas prouver que vous possédez bien ces noms de domaine (à moins, bien évidemment, que vous ne possédiez Google).

Enfin, en publiant un enregistrement SPF pour votre domaine, vous montrez au monde de l’emailing votre volonté de bien faire : vous adoptez un comportement d’expéditeur légitime (ce que vous êtes, après tout). Cela ne peut qu’améliorer votre délivrabilité sur le long terme et réduire le risque de voir vos messages bloqués.

Mais concrètement, comment le protocole fonctionne-t-il ? Depuis le début de cet article, nous parlons d’enregistrements, de serveurs et d’adresses IP, sans trop préciser comment tout ceci s’agence. Rentrons donc dans le détail.

En tant que norme d’authentification, SPF repose sur l’échange d’informations entre le serveur d’expédition (celui que vous utilisez) et les serveurs de destination. Quand vous envoyez un email, votre destinataire (enfin, son serveur de messagerie en tout cas) peut lire l’adresse IP de la machine qui lui transmet le message. Le contrôle, invisible pour l’utilisateur, se déroule en quatre temps :

• Pendant la session SMTP, le serveur d’envoi annonce une adresse de retour (le Return-Path, aussi appelé adresse d’enveloppe ou MAIL FROM).
• Le serveur du destinataire extrait le nom de domaine de cette adresse et envoie une requête DNS pour récupérer l’enregistrement TXT qui commence par v=spf1.
• Il compare l’adresse IP de connexion avec les sources autorisées listées dans cet enregistrement.
• Il obtient un résultat (pass, fail, softfail, neutral, none, permerror ou temperror) et applique sa propre politique de filtrage.

Si l’adresse IP du serveur d’expédition correspond à une des adresses inscrites dans l’enregistrement SPF, le serveur de réception considérera le message comme légitime. Dans le cas contraire, l’adresse IP d’envoi sera considérée comme illégitime, ce qui pourra entraîner un rejet de l’email, voire une mise en spam. Notez que le contrôle porte sur le domaine de l’adresse de retour, et non sur l’adresse visible dans le champ « De : » : nous y reviendrons dans la partie consacrée aux limites.

L’enregistrement SPF est un enregistrement DNS de type TXT, publié dans la zone DNS de votre nom de domaine. Il tient en une chaîne de texte unique, lue de gauche à droite par le serveur qui effectue le contrôle. Voici un exemple d’enregistrement SPF pour une entreprise qui envoie depuis son propre serveur et via Mailjet :

v=spf1 ip4:192.0.2.10 include:spf.mailjet.com ~all

Décomposons-le. La balise v=spf1 indique la version du protocole : elle est obligatoire et doit toujours figurer en tête. Viennent ensuite les mécanismes, qui listent les émetteurs autorisés (ici une adresse IP et les serveurs de Mailjet), puis un mécanisme final all, précédé d’un qualificateur, qui dit quoi faire des messages provenant de tout autre serveur.

Trois règles de base à retenir : un domaine ne doit publier qu’un seul enregistrement SPF, chaque chaîne de texte est limitée à 255 caractères, et l’ensemble doit rester lisible et concis. Si vous devez autoriser plusieurs services, vous les regroupez dans le même enregistrement au lieu d’en créer un deuxième.

Les mécanismes décrivent qui a le droit d’envoyer des mails pour ce domaine. Les plus courants sont les suivants :

Mécanisme	Rôle	Exemple
ip4 / ip6	Autorise une adresse IP ou une plage d’adresses	ip4:192.0.2.0/24
a	Autorise les adresses IP liées à l’enregistrement A du domaine (souvent le serveur web)	a
mx	Autorise les serveurs de messagerie déclarés dans les enregistrements MX	mx
include	Reprend la politique SPF d’un autre domaine, typiquement celui d’un fournisseur d’envoi	include:spf.mailjet.com
exists	Condition avancée fondée sur l’existence d’un enregistrement DNS	exists:%{i}.exemple.fr
all	Correspond à tous les autres serveurs, toujours placé à la fin	~all

Le mécanisme ptr existe encore, mais la RFC 7208 déconseille son utilisation, car il est lent et peu fiable.

Chaque mécanisme peut être précédé d’un qualificateur, qui définit le résultat renvoyé en cas de correspondance :

Qualificateur	Résultat	Effet attendu côté réception
+ (par défaut)	Pass	La source est autorisée
–	Fail	La source n’est pas autorisée, le message peut être rejeté
~	SoftFail	La source est probablement non autorisée, le message est accepté mais marqué comme suspect
?	Neutral	Le domaine ne se prononce pas

En pratique, ~all est une bonne base pendant la mise en place, tandis que -all correspond à la politique la plus stricte, une fois tous vos services recensés. À proscrire absolument : +all, qui autorise n’importe quel serveur de la planète à envoyer en votre nom.

Publier un enregistrement SPF ne prend que quelques minutes, et les bénéfices se font sentir aussi bien sur la sécurité de votre domaine que sur la performance de vos campagnes. Voici pourquoi utiliser le SPF est devenu une solution de base pour prévenir la fraude.

Le premier bénéfice est défensif. Sans SPF, rien n’empêche un tiers d’envoyer des emails en utilisant votre domaine dans l’adresse de retour. Ces attaques par usurpation servent à piéger vos clients, vos partenaires ou vos propres collaborateurs : faux avis de paiement, fausses factures, faux formulaire de mise à jour d’identifiants… Le SPF aide les serveurs de réception à repérer ces messages, puisqu’ils proviennent de serveurs absents de votre liste.

Un domaine protégé, c’est aussi une marque protégée. Un domaine régulièrement usurpé finit par être associé à des tentatives d’hameçonnage, ce qui abîme la confiance de vos destinataires bien au-delà du canal email. En déclarant clairement vos serveurs légitimes, vous réduisez la surface d’attaque et vous aidez les fournisseurs de messagerie à détecter les faux messages.

Le second bénéfice touche à la délivrabilité. Les fournisseurs de boîtes de réception s’appuient sur l’authentification pour évaluer la réputation d’un expéditeur : un domaine authentifié envoie un signal de sérieux, un domaine sans SPF paraît suspect par défaut, et peut plus facilement finir sur une liste noire ou déclencher les filtres anti spam. Depuis février 2024, Gmail et Yahoo exigent d’ailleurs que tous les expéditeurs authentifient leurs messages avec SPF ou DKIM, et que les expéditeurs de gros volumes combinent SPF, DKIM et DMARC.

Autrement dit, un enregistrement SPF correct n’est plus une option pour qui envoie des newsletters ou des emails transactionnels. Il ne garantit pas l’arrivée en boîte de réception (le contenu, l’engagement et l’hygiène de vos listes comptent aussi), mais son absence ou une erreur de configuration pénalise vos taux de livraison dès le départ.

Pour configurer un enregistrement SPF, vous devez recenser tous les services qui envoient des emails pour votre domaine, rédiger une valeur unique qui les autorise, puis la publier chez votre hébergeur. Voici la méthode générique, suivie de la procédure propre à Mailjet.

Commencez par l’inventaire, c’est l’étape la plus souvent négligée. Listez tout ce qui envoie des emails avec votre domaine : votre messagerie professionnelle dans le cloud (Google Workspace, Microsoft 365), votre plateforme d’emailing, votre CRM, votre outil de facturation, votre site web ou l’application qui envoie vos notifications via API ou SMTP. Chaque service oublié verra ses messages échouer au contrôle.

Rédigez ensuite votre enregistrement. Chaque fournisseur indique dans sa documentation le mécanisme include à ajouter : include:_spf.google.com pour Google Workspace, include:spf.protection.outlook.com pour Microsoft 365, include:spf.mailjet.com pour Mailjet. Une entreprise qui utilise les deux derniers publiera par exemple :

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

Il reste à publier l’enregistrement :

• Connectez-vous à l’espace client de votre registrar ou de votre offre d’hébergement (OVHcloud, Cloudflare, Gandi, etc.), rubrique gestion de la zone DNS.
• Vérifiez s’il existe déjà un enregistrement TXT commençant par v=spf1 : si oui, modifiez-le au lieu d’en ajouter un second, et supprimez les éventuels doublons.
• Sinon, créez un enregistrement de type TXT, laissez le champ sous-domaine vide (ou saisissez @) et collez votre code SPF dans la valeur.
• Enregistrez, puis patientez le temps de la propagation DNS, qui prend de quelques minutes à quelques heures selon le TTL.

Un conseil souvent oublié : pour un domaine qui n’envoie aucun email (un domaine de marque réservé, par exemple), publiez simplement v=spf1 -all. Vous empêchez ainsi les fraudeurs de l’utiliser à votre place.

Évidemment, Mailjet vous permet de paramétrer les enregistrements SPF pour vos différents domaines. Sans reprendre l’intégralité de notre documentation très bien faite, voici les grandes étapes à suivre pour configurer SPF avec nos services.

Dans votre compte Mailjet, rendez-vous dans les Informations du compte, puis cliquez sur « Configuration de l’authentification SPF/DKIM ». En parallèle, ouvrez la page correspondant à votre domaine sur le site de votre hébergeur, pour trouver vos enregistrements DNS (selon votre hébergement, le menu s’appelle souvent « Zone DNS »).

Cliquez sur le bouton « Gérer » correspondant au nom de domaine que vous voulez valider. Dans la page suivante, vous trouverez les éléments à copier et coller dans la zone DNS de votre hébergeur. Si votre domaine possède déjà un enregistrement SPF, ajoutez simplement include:spf.mailjet.com à l’enregistrement existant, juste avant le mécanisme all.

Bravo, vous venez de créer un nouvel enregistrement SPF ! Vous devriez pouvoir suivre la progression de la validation de cet enregistrement depuis votre page Mailjet.

Notez que si vous configurez un nouveau domaine pour obtenir votre enregistrement SPF, nous vous encourageons chaudement à faire de même avec votre enregistrement DKIM. Après tout, les informations dont vous avez besoin du côté de Mailjet sont réunies sur la même page, et vos envois n’en seront que plus sécurisés. C’est d’ailleurs tout l’intérêt d’associer SPF, DKIM et DMARC dès la configuration de votre domaine.

Une fois l’enregistrement publié, il faut vérifier qu’il est bien visible et correctement interprété. Une simple faute de frappe suffit à rendre toute la politique inopérante, et vous ne le découvrirez souvent qu’en constatant une baisse de vos ouvertures.

Plusieurs méthodes, de la plus technique à la plus accessible, permettent de tester votre configuration :

• Dans un terminal, la commande nslookup -type=txt votredomaine.fr (Windows) ou dig TXT votredomaine.fr +short (macOS, Linux) affiche les enregistrements TXT publiés.
• Les outils en ligne gratuits, comme le SPF Record Check de MXToolbox, le SPF Surveyor de dmarcian ou la Google Admin Toolbox, analysent la syntaxe et comptent les recherches DNS.
• Le test le plus concret consiste à vous envoyer un email, puis à ouvrir ses en-têtes (« Afficher l’original » dans Gmail) : la ligne Authentication-Results doit afficher spf=pass.

Répétez ce test après chaque ajout ou retrait d’un service, car la moindre modification de la zone DNS peut changer le résultat.

L’erreur la plus répandue concerne la limite de 10 recherches DNS. Pour éviter de surcharger les serveurs, la norme plafonne à 10 le nombre de requêtes DNS nécessaires pour évaluer un enregistrement. Les mécanismes include, a, mx, exists, ptr et le modificateur redirect comptent chacun, y compris les requêtes déclenchées à l’intérieur des include. Les mécanismes ip4, ip6 et all, eux, ne comptent pas. Au-delà de 10, la vérification renvoie une erreur permanente (permerror), et le message est traité comme s’il n’était pas authentifié.

Pour corriger ce problème, supprimez les include de services que vous n’utilisez plus, remplacez certains include par des plages ip4 lorsque le fournisseur le permet, ou déplacez des flux d’envoi sur un sous-domaine dédié doté de son propre enregistrement.

Les autres erreurs classiques : deux enregistrements SPF publiés sur le même domaine (également sanctionné par un permerror), une faute de syntaxe dans un mécanisme, un service oublié ou un +all laissé par défaut.

Si le SPF est un outil très efficace, il n’en reste pas moins limité. Du fait de son grand âge (à l’échelle de l’histoire d’Internet, évidemment), il n’a pas vraiment évolué, et les mauvais acteurs ont appris à le contourner.

Certains spammeurs se contentent désormais d’usurper l’adresse contenue dans le champ « De : » présent dans l’en-tête, plutôt que de chercher à usurper le nom de domaine de l’adresse de retour, seule vérifiée par SPF. Ils peuvent aussi chercher à se faire passer pour quelqu’un d’autre avec une adresse du type « marketing[at]amazom[point]com », présentant un enregistrement SPF légitime aux serveurs de destination (puisque contenant de « vraies » informations). Le lecteur inattentif pourra avoir l’impression de recevoir un email légitime d’une plateforme d’e-commerce bien connue et cliquer sur des liens nocifs.

En outre, SPF n’aura pas d’effet si votre email est transféré : le serveur qui effectue le transfert n’étant pas listé dans votre enregistrement, la vérification échoue chez le destinataire final.

Enfin, bien évidemment, si la mise en place de SPF envoie un signal positif aux fournisseurs d’accès à Internet (FAI) et aux webmails, elle ne vous garantit pas une délivrabilité optimale. SPF n’est qu’un outil dans l’arsenal mis à votre disposition pour atteindre les boîtes de réception. Veillez donc à suivre les bonnes pratiques de l’emailing.

C’est pourquoi, pour contourner ces problèmes, nous vous recommandons chaudement d’associer votre enregistrement SPF à des enregistrements DKIM et DMARC, qui vous permettent de protéger toujours un peu plus votre identité d’expéditeur.

Chaque protocole joue un rôle distinct. DKIM (DomainKeys Identified Mail) appose une signature cryptographique sur le message, grâce à une clé publique publiée dans votre DNS : elle prouve que le contenu n’a pas été modifié et résiste au transfert. DMARC relie ensuite SPF et DKIM au domaine visible dans le champ « De : » (on parle d’alignement), indique au destinataire quelle politique appliquer en cas d’échec (none, quarantine ou reject) et vous envoie des rapports sur les messages envoyés en votre nom. Une fois ce socle en place, BIMI permet même d’afficher le logo de votre marque dans certaines boîtes de réception compatibles.

Si le SPF est une norme ancienne, elle a également fait ses preuves : le fait qu’elle soit toujours largement utilisée aujourd’hui en est la meilleure démonstration. Aussi, avant de commencer vos envois avec ce nouveau nom de domaine rutilant que vous venez de créer, ayez le bon réflexe : recensez vos services, publiez votre enregistrement SPF, puis vérifiez-le.

Notez que le SPF est loin d’être le seul protocole existant vous permettant d’effectuer des envois d’emails plus sûrs. Dans cet article, nous avons évoqué DKIM, DMARC et BIMI, qui complètent la sécurisation de votre stratégie d’emailing. Pour aller plus loin, notre guide de la délivrabilité réunit les bonnes pratiques qui vous aideront à atteindre la boîte de réception.

Utilisez un outil en ligne comme MXToolbox ou dmarcian : il récupère votre enregistrement, contrôle la syntaxe et compte les recherches DNS. Complétez par un test réel : envoyez un email vers une adresse Gmail ou Yahoo, affichez le message original et vérifiez que le résultat indique spf=pass. Un résultat softfail ou fail signale une source d’envoi absente de votre enregistrement.

Non. Un domaine ne doit publier qu’un seul enregistrement TXT SPF, commençant par v=spf1. En présence de deux lignes, les serveurs renvoient une erreur permanente et considèrent le domaine comme non authentifié. Pour autoriser plusieurs services, fusionnez leurs mécanismes dans un enregistrement unique. En revanche, chaque sous-domaine peut disposer de son propre enregistrement.

Elle apparaît lorsque l’évaluation de votre enregistrement nécessite plus de 10 requêtes DNS, la limite fixée par la RFC 7208. Chaque include, a ou mx en consomme au moins une, et les include imbriqués s’additionnent. Le résultat est un permerror : faites le ménage dans les services inutilisés ou répartissez vos envois sur des sous-domaines.

Non. SPF ne contrôle que l’adresse de retour et ne survit pas au transfert. Pour une protection complète contre l’usurpation, combinez-le avec DKIM et DMARC, désormais attendus par les principaux fournisseurs de messagerie. Ensemble, ces trois protocoles couvrent le serveur émetteur, l’intégrité du message et l’alignement avec l’adresse visible par vos destinataires.