Si la messagerie électronique est aujourd’hui l’un des moyens de communication les plus utilisés, tant dans le monde professionnel que dans la sphère personnelle, derrière chaque e-mail envoyé se cache une structure technique complexe destinée à garantir la sécurité, l’authenticité et la bonne livraison des messages. Parmi ces mécanismes, le SPF, ou Sender Policy Framework, joue un rôle fondamental. Il repose sur le système DNS pour aider les serveurs de messagerie à identifier les sources autorisées à envoyer des e-mails pour un domaine donné. Si ce mécanisme est bien configuré, il limite efficacement les risques d’usurpation d’adresse (spoofing), un fléau récurrent dans les campagnes de phishing.

Comprendre le fonctionnement du SPF dans l’écosystème des DNS

Pour bien appréhender le fonctionnement du protocole SPF, il est essentiel de replacer ce mécanisme dans son contexte historique et technique. SPF, ou Sender Policy Framework, est le fruit d’une longue évolution des technologies de messagerie et de la sécurité numérique. Ce protocole est né au début des années 2000, en réponse directe à la montée en puissance des menaces liées à l’usurpation d’identité dans les e-mails, aussi appelée spoofing.

À cette époque, l’e-mail, bien qu’omniprésent dans les entreprises, était encore dépourvu de mécanismes standardisés de vérification de l’expéditeur. Tout serveur pouvait se présenter comme « expediteur@entreprise.com » sans que le destinataire n’ait un moyen fiable de vérifier l’authenticité de ce message. C’est dans ce contexte qu’est née l’idée du SPF. Le protocole a été proposé pour la première fois en 2003 par Paul Vixie, célèbre ingénieur américain spécialiste des infrastructures DNS et fondateur de l’organisation Internet Systems Consortium (ISC), basée à Redwood City, en Californie. La proposition initiale a été intégrée dans les réflexions de la communauté IETF (Internet Engineering Task Force), qui pilote la standardisation des protocoles Internet. Le SPF est officiellement défini dans le RFC 4408, publié en avril 2006. Cette spécification, bien qu’améliorée par la suite (notamment via le RFC 7208 de 2014), reste la base du fonctionnement actuel de SPF.

Mais pour comprendre le rôle du SPF, il faut d’abord s’intéresser à un élément fondamental d’Internet : le DNS (Domain Name System). Créé dans les années 1980 à l’Université de Californie (Berkeley), le DNS agit comme un immense annuaire distribué qui permet à un ordinateur de traduire un nom de domaine (comme monsite.fr) en adresse IP. Mais le DNS ne se limite pas à la résolution de noms : il est aussi le support de nombreux enregistrements liés à la messagerie (MX), aux redirections (CNAME) ou aux politiques de sécurité, comme le SPF via les enregistrements TXT. Un enregistrement TXT dans le DNS est un champ libre dans lequel le propriétaire d’un domaine peut insérer n’importe quelle donnée textuelle. C’est là que les règles SPF sont définies, dans une syntaxe normalisée. Lorsqu’un serveur de messagerie reçoit un e-mail, il interroge les DNS publics du domaine de l’expéditeur pour y lire cet enregistrement et comparer l’adresse IP du serveur émetteur avec la liste autorisée. Si l’adresse IP ne figure pas dans la règle, plusieurs actions sont possibles : le message peut être rejeté, classé comme spam ou accepté sous réserve, en fonction de la politique du serveur récepteur. Voici un exemple d’enregistrement SPF :

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all

Décomposons cette ligne ligne par ligne :

• v=spf1 : cette balise indique la version du protocole SPF utilisée. À ce jour, seule la version 1 est normalisée et déployée à grande échelle. Les tentatives de version 2 ont été abandonnées au profit de DMARC, un protocole complémentaire ;
• ip4:192.0.2.0/24 : cela autorise toute adresse IP comprise dans la plage 192.0.2.0 à 192.0.2.255 à envoyer des e-mails pour ce domaine. L’utilisation du préfixe CIDR permet d’indiquer une plage d’adresses, utile pour les infrastructures à plusieurs serveurs ;
• include:_spf.google.com : ce mécanisme permet d’inclure les règles SPF définies dans un autre domaine, ici _spf.google.com, ce qui est courant lorsque vous utilisez des services tiers comme Google Workspace. Cela évite de recopier à la main tous les serveurs IP de Google ;
• -all : cet opérateur indique une politique stricte : tous les serveurs qui ne sont pas explicitement listés seront considérés comme non autorisés. Le tiret - signifie « fail dur », c’est-à-dire que le message doit être rejeté sans ambiguïté.

Ce format, bien que lisible pour un humain averti, est avant tout conçu pour être lu par les machines. C’est la raison pour laquelle le SPF est considéré comme un protocole déclaratif : Il ne chiffre pas, ne signe pas, n’envoie pas de signal actif. Il fournit une règle passive que d’autres systèmes peuvent consulter en temps réel, de façon décentralisée. La montée en puissance du cloud et des services SaaS dans les années 2010 a multiplié les défis liés à SPF. De nombreux outils marketing, CRM, plateformes transactionnelles ou services de newsletters envoient des e-mails au nom des entreprises. Chacun d’eux doit être référencé dans la politique SPF du domaine, ce qui a poussé à une meilleure gestion des zones DNS, souvent centralisées par les fournisseurs comme OVH (France), Cloudflare (États-Unis), IONOS (Allemagne) ou Gandi (France).

Enfin, notons que le SPF n’est pas un outil de protection du contenu d’un message. Il n’empêche pas un attaquant d’envoyer un e-mail avec un corps trompeur, ni de falsifier des pièces jointes. Sa seule fonction est de vérifier que le serveur d’envoi est légitimement autorisé par le propriétaire du domaine. C’est une brique de confiance dans un écosystème de sécurité beaucoup plus large.

Configurer correctement son enregistrement SPF pour une délivrabilité optimale

La configuration d’un enregistrement SPF ne se limite pas à ajouter quelques lignes dans une zone DNS. Elle suppose une compréhension fine de votre infrastructure d’envoi, des services tiers utilisés et des implications sur la réputation de votre domaine. Une mauvaise configuration peut entraîner le classement systématique de vos e-mails dans le dossier spam, voire leur rejet pur et simple par les serveurs de réception. Voici les étapes et bonnes pratiques à suivre pour une configuration optimale :

• Recenser tous les services d’envoi :
  Il faut dresser un inventaire exhaustif de tous les serveurs et plateformes susceptibles d’envoyer des e-mails pour le compte de votre domaine. Cela inclut :
  • Vos serveurs SMTP internes (hébergés sur site ou en cloud)
  • Vos hébergeurs web (par exemple, OVH, IONOS, Infomaniak)
  • Les services de newsletters : Mailchimp, Brevo (ex-Sendinblue), ActiveCampaign…
  • Les CRM comme HubSpot, Salesforce, Zoho, etc.
  • Les services d’envoi transactionnel : Amazon SES, Mailgun, Postmark, etc.
• Limiter le nombre de requêtes DNS :
  Chaque directive include: ou redirect= génère une requête DNS. La norme SPF impose un maximum de 10 requêtes DNS par vérification. Si ce seuil est dépassé, la vérification échoue automatiquement. Pour éviter cela :
  • Évitez les include: inutiles
  • Utilisez des IPs directes quand c’est possible (ip4: ou ip6:)
  • Ne cumulez pas les sous-services d’un même prestataire s’ils sont déjà regroupés dans un enregistrement unique
• Choisir le mécanisme final approprié :
  C’est le dernier élément de votre enregistrement SPF, et il a une forte influence sur le comportement du serveur de réception. Trois options sont possibles :
  • -all (fail strict) : rejette catégoriquement les messages non conformes. À utiliser dans un environnement maîtrisé.
  • ~all (softfail) : marque les messages comme suspects. Recommandé lors des phases de transition.
  • ?all (neutral) : ne donne pas d’avis, laisse le serveur destinataire décider. À éviter dans les environnements professionnels.
• Valider et tester l’enregistrement SPF :
  Avant de déployer votre configuration en production, utilisez des outils spécialisés pour tester et simuler l’interprétation de votre enregistrement :
  • MXToolbox SPF Lookup
  • Kitterman SPF Tester
  • Mail-tester pour des tests en condition réelle (Voir notre sujet sur MailPoet)
• Un seul enregistrement SPF par domaine :
  Le DNS ne permet pas plusieurs enregistrements TXT distincts contenant des directives SPF. Si vous avez plusieurs sources d’envoi, regroupez toutes les directives dans un seul enregistrement, même s’il est long. En cas de doublon, le comportement devient imprévisible et risque de bloquer vos envois.

Pour vous aider à visualiser les éléments critiques à prendre en compte lors de la configuration d’un SPF, voici un tableau de référence :

Une bonne configuration SPF ne garantit pas à elle seule la délivrabilité, mais elle constitue un socle essentiel pour bâtir une réputation d’expéditeur saine. C’est aussi une exigence de plus en plus souvent imposée par les hébergeurs de messagerie comme Google, Microsoft ou Yahoo, qui filtrent désormais très activement les messages ne respectant pas les bonnes pratiques SPF, DKIM et DMARC.

Le SPF, une pièce du puzzle dans l’authentification des e-mails

Depuis les débuts de l’email dans les années 1970 avec les travaux de Ray Tomlinson au sein du laboratoire BBN à Cambridge (Massachusetts), la messagerie électronique n’a cessé d’évoluer. Cependant, elle a été conçue à une époque où la sécurité n’était pas une priorité. C’est cette absence de contrôle à l’origine qui a permis à des menaces telles que le spoofing ou l’usurpation d’identité d’exploser avec l’essor du web. Pour y répondre, les experts ont développé plusieurs protocoles d’authentification complémentaires (dont le SPF fait partie) afin de garantir l’origine, l’intégrité et la légitimité des messages électroniques.

Le SPF se focalise exclusivement sur la vérification du chemin d’envoi : Il établit une correspondance entre l’adresse IP de l’émetteur du message et les serveurs autorisés à envoyer des e-mails pour un domaine donné. Bien qu’essentiel, ce mécanisme ne protège ni le contenu du message, ni la structure de l’en-tête, et encore moins les tentatives de falsification du nom de l’expéditeur visible (From). C’est pourquoi d’autres briques ont été ajoutées à l’architecture de sécurisation de l’email. Voici un résumé des trois principaux piliers de l’authentification email moderne :

• SPF : vérifie que l’adresse IP de l’expéditeur est autorisée à envoyer des e-mails pour un domaine, via une requête DNS vers un enregistrement TXT. C’est une vérification d’infrastructure, qui ne prend pas en compte le contenu du message.
• DKIM (DomainKeys Identified Mail) : introduit en 2004 par Yahoo! et Cisco, ce protocole permet au domaine émetteur de signer ses messages à l’aide d’une clé cryptographique privée. Le serveur de réception vérifie cette signature avec une clé publique publiée dans le DNS. Cela garantit que le message n’a pas été modifié entre l’envoi et la réception.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) : créé en 2012 par un groupe d’acteurs majeurs de l’email (notamment Google, Microsoft, Yahoo! et PayPal), DMARC s’appuie sur les résultats des tests SPF et DKIM pour appliquer une politique claire : accepter, mettre en quarantaine ou rejeter les messages non conformes. Il permet aussi de recevoir des rapports d’authentification détaillés, très utiles pour surveiller les tentatives de fraude ou les erreurs de configuration.

Ensemble, ces trois protocoles forment une trinité de protection indispensable. Mais leur ordre de mise en place compte. En général, on commence par SPF (plus simple), on ajoute DKIM (plus technique), puis on termine par DMARC, qui orchestre le tout. Dans la pratique, l’impact d’une configuration correcte est considérable :

• Les serveurs de messagerie comme Gmail, Outlook, Yahoo ou ProtonMail tiennent désormais compte des résultats SPF, DKIM et DMARC pour décider de la légitimité d’un e-mail ;
• Les plateformes comme Google Workspace exigent une configuration complète de ces trois mécanismes pour garantir la meilleure délivrabilité ;
• Les grandes entreprises, les administrations, mais aussi les TPE/PME sont de plus en plus ciblées par des attaques par usurpation de domaine. Sans SPF/DKIM/DMARC, elles deviennent des relais involontaires de campagnes frauduleuses.

Il faut noter que les protocoles d’authentification continuent de se perfectionner. Des technologies comme BIMI (Brand Indicators for Message Identification), qui permet d’afficher un logo certifié dans les boîtes de réception, s’appuient directement sur la mise en place d’un DMARC strict. En d’autres termes, une configuration SPF rigoureuse est un prérequis pour accéder à des outils de confiance de nouvelle génération.

Le SPF n’est donc pas une fin en soi. Il est une brique d’un édifice plus large, qui reflète la maturité numérique d’une organisation. Il est à la messagerie ce que le HTTPS est à la navigation web : une norme de base, mais absolument indispensable. Sans lui, c’est la porte ouverte aux abus, aux filtres de spam agressifs, et à une réputation d’expéditeur fragilisée.