Un courriel qui arrive en boîte de réception n’est jamais seulement un message. C’est aussi une chaîne de vérifications techniques destinées à savoir si l’expéditeur est légitime. Parmi elles, l’enregistrement SPF occupe une place centrale dans la lutte contre l’usurpation d’identité et le spam.
Un enregistrement SPF, pour Sender Policy Framework, est une règle publiée dans le DNS d’un nom de domaine afin d’indiquer quels serveurs sont autorisés à envoyer des e-mails pour ce domaine. Concrètement, il s’agit le plus souvent d’un enregistrement TXT ajouté à la zone DNS, lisible par les serveurs de messagerie qui reçoivent les messages.
Lorsqu’un e-mail arrive sur un serveur destinataire, celui-ci peut interroger le DNS du domaine indiqué dans l’enveloppe du message, souvent le domaine du Return-Path. Il compare ensuite l’adresse IP du serveur émetteur avec la liste des sources autorisées. Si l’adresse IP correspond, le contrôle SPF peut aboutir à un résultat positif. Sinon, le message peut être marqué comme suspect, placé en quarantaine ou rejeté selon la politique appliquée par le destinataire.
Le SPF ne vérifie pas le contenu du message, ne chiffre pas les échanges et ne garantit pas à lui seul qu’un courriel est fiable. Son rôle est plus précis : établir si le serveur qui envoie le message a le droit de le faire pour un domaine donné. Cette vérification simple reste pourtant essentielle, car l’usurpation d’adresse e-mail demeure l’une des techniques les plus utilisées dans les campagnes de phishing.
L’e-mail repose sur des protocoles anciens, conçus à une époque où la confiance entre serveurs était plus implicite qu’aujourd’hui. Par défaut, rien n’empêche techniquement un expéditeur malveillant d’inscrire une adresse apparente appartenant à une entreprise connue. Le SPF dans le DNS apporte une réponse partielle à ce problème en rendant publique la liste des serveurs légitimes.
Pour une organisation, l’enjeu est double. D’un côté, SPF contribue à protéger la réputation du domaine en réduisant le risque que des tiers l’utilisent pour envoyer du spam ou des messages frauduleux. De l’autre, il améliore la délivrabilité des e-mails authentiques, notamment les factures, confirmations de commande, newsletters ou messages transactionnels. Les grands fournisseurs de messagerie, dont Google, Microsoft et Yahoo, tiennent compte de ces mécanismes d’authentification dans leurs filtres.
SPF s’inscrit dans un écosystème plus large de sécurité des communications. Il ne remplace pas le chiffrement du transport, assuré dans de nombreux cas par TLS, dont le fonctionnement est expliqué dans cette analyse du protocole TLS lors d’une connexion HTTPS. Là où TLS protège le canal de transmission, SPF aide à valider l’origine technique d’un message.
Le fonctionnement d’un contrôle SPF suit une logique relativement directe. Un serveur reçoit un e-mail et relève l’adresse IP du serveur qui s’est connecté à lui. Il identifie ensuite le domaine utilisé dans l’enveloppe SMTP, puis interroge le DNS de ce domaine pour récupérer son enregistrement TXT SPF.
Le serveur destinataire lit alors la règle publiée. Celle-ci peut contenir des adresses IP, des plages réseau, des noms d’hôtes ou des références à d’autres domaines. Si l’adresse IP de l’expéditeur figure dans les sources autorisées, le résultat est généralement “pass”. Dans le cas contraire, le résultat peut être “fail”, “softfail”, “neutral” ou “none”, selon la configuration du domaine et les informations disponibles.
Cette vérification dépend fortement de la disponibilité du DNS. Si une erreur temporaire empêche la résolution, le serveur peut retourner un résultat “temperror”. Si la règle SPF est mal formée, trop complexe ou non conforme, il peut s’agir d’un “permerror”. Ces distinctions sont importantes : un mauvais paramétrage peut nuire à des messages légitimes, parfois sans que l’expéditeur s’en aperçoive immédiatement.
Un exemple courant d’enregistrement SPF est le suivant : v=spf1 ip4:192.0.2.10 include:exemple-service.com -all. La première partie, “v=spf1”, indique la version du mécanisme. L’élément “ip4” autorise une adresse IPv4 précise. Le mécanisme “include” délègue une partie de l’autorisation à un prestataire externe, par exemple une plateforme d’envoi d’e-mails. Enfin, “-all” signifie que toute autre source doit être considérée comme non autorisée.
Plusieurs mécanismes existent. “ip4” et “ip6” autorisent des adresses ou plages IP. “a” autorise les adresses associées à l’enregistrement A ou AAAA du domaine. “mx” autorise les serveurs de messagerie déclarés comme MX. “include” est très utilisé lorsque l’entreprise confie ses envois à des services comme Microsoft 365, Google Workspace, Sendgrid, Mailchimp ou Brevo.
L’usage d’IPv6 devient également plus fréquent dans les règles SPF. Les organisations qui migrent progressivement leurs infrastructures doivent penser à autoriser les adresses IPv6 de leurs serveurs d’envoi. Cette évolution s’inscrit dans un mouvement plus large décrit dans l’article consacré à la manière dont IPv6 remplace progressivement IPv4 sur Internet.
La fin d’une règle SPF contient souvent un qualificatif appliqué au mécanisme “all”. C’est lui qui indique au serveur destinataire comment interpréter les sources non listées. Le plus strict est -all, qui correspond à un échec explicite. Il signifie que seules les sources indiquées dans la règle doivent envoyer des e-mails pour le domaine.
Le qualificatif “~all”, appelé softfail, est plus souple. Il indique que les sources non listées ne sont probablement pas autorisées, mais laisse au destinataire une marge d’interprétation. Cette option est souvent utilisée pendant une phase de déploiement, lorsque l’organisation veut observer les effets de sa configuration sans provoquer trop de rejets.
Le qualificatif “?all” produit un résultat neutre, tandis que “+all” autorise pratiquement toutes les sources. Ce dernier est fortement déconseillé, car il vide SPF de son intérêt. Une politique efficace consiste généralement à commencer par une règle prudente, puis à durcir progressivement la configuration lorsque toutes les sources légitimes ont été identifiées.
SPF est utile, mais il présente plusieurs limites. La première tient au transfert d’e-mails. Lorsqu’un message est transféré par un serveur intermédiaire, l’adresse IP visible par le destinataire final peut être celle du serveur de transfert, et non celle du serveur initial autorisé. Dans ce cas, le contrôle SPF peut échouer même si le message d’origine était légitime.
Autre point sensible : un domaine ne doit publier qu’un seul enregistrement SPF valide. Lorsque plusieurs enregistrements TXT commençant par “v=spf1” existent pour le même domaine, les serveurs destinataires peuvent retourner une erreur permanente. Cette situation survient souvent après l’ajout successif de prestataires e-mail sans consolidation de la règle existante.
SPF impose aussi une limite de dix recherches DNS pour certains mécanismes comme “include”, “a”, “mx”, “ptr” ou “exists”. Au-delà, la vérification échoue avec un permerror. Cette contrainte oblige les administrateurs à maîtriser la complexité de leur règle, surtout lorsque plusieurs plateformes marketing, CRM et services transactionnels envoient des messages au nom du même domaine.
SPF ne fonctionne pas seul dans les stratégies modernes d’authentification e-mail. Il est généralement associé à DKIM et DMARC. DKIM ajoute une signature cryptographique au message, permettant de vérifier qu’il n’a pas été modifié et qu’il provient bien d’une source détenant la clé privée associée au domaine. DMARC, lui, définit une politique de traitement lorsque SPF ou DKIM échouent.
La notion d’alignement est essentielle. Avec DMARC, le domaine visible par l’utilisateur dans le champ “From” doit être cohérent avec le domaine validé par SPF ou DKIM. Sans cet alignement, un message peut passer SPF techniquement tout en échouant à la politique DMARC. C’est l’une des raisons pour lesquelles SPF seul ne suffit pas à protéger efficacement une marque contre l’usurpation.
Le DNS devient alors une brique de confiance critique. Comme les enregistrements SPF, DKIM et DMARC sont publiés dans le DNS, leur intégrité compte. Des mécanismes comme DNSSEC visent précisément à renforcer la confiance dans les réponses DNS, comme l’explique cette présentation de DNSSEC et de son rôle dans la sécurisation du DNS.
Avant de publier un SPF, il faut dresser l’inventaire complet des sources d’envoi. Cela inclut les serveurs internes, les outils de relation client, les plateformes d’e-mail marketing, les services de facturation, les systèmes de support et les applications métier. Oublier une source légitime peut dégrader la délivrabilité de messages importants.
Il est recommandé de privilégier une règle lisible, courte et maintenable. Les mécanismes “include” doivent être utilisés avec discernement, car chaque prestataire peut lui-même appeler d’autres domaines. Les grandes organisations documentent souvent les propriétaires de chaque autorisation, afin de pouvoir retirer rapidement une entrée devenue inutile après un changement d’outil.
La propagation dépend du TTL configuré dans le DNS. Un TTL court peut faciliter une phase de modification, tandis qu’un TTL plus long réduit la fréquence des requêtes. Cette logique de cache se distingue des mécanismes du web, mais elle rappelle l’importance des réponses réutilisées, un sujet également visible dans le fonctionnement du code HTTP 304 Not Modified et de son impact sur le cache.
Enfin, il est prudent de tester la règle après chaque modification et de surveiller les rapports DMARC lorsqu’ils sont activés. Ces rapports fournissent des informations concrètes sur les serveurs qui envoient réellement au nom du domaine. À l’échelle d’Internet, l’acheminement des données repose sur de nombreuses couches, dont le routage entre réseaux autonomes décrit dans l’analyse du protocole BGP entre réseaux autonomes. SPF intervient à un autre niveau, mais poursuit le même objectif général : rendre les échanges plus fiables et plus prévisibles.
