SPF

Renaud Garelli

Le SPF, signifiant “Sender Policy Framework”, est un protocole email permettant de garantir l’authenticité d’un domaine expéditeur, et ainsi de se prémunir contre les tentatives d’usurpation d’identité de ce dernier.

 

Au début des années 2000, lors de la popularisation progressive des emails, aucun mécanisme d’authentification n’avait été défini et il était donc très facile pour une personne mal intentionnée de falsifier l’adresse email émettrice (le FROM de l’entête de l’email) pour faire croire que l’email envoyé provenait d’une adresse email voulue.
Ce manque technique empêchait le destinataire de pouvoir déterminer de manière sûre si l’adresse email expéditrice était bien celle qui avait envoyé l’email en question, et posait donc un vrai problème de confiance sur le contenu échangé.
Il était donc possible sans aucune contrainte de se faire passer par exemple pour une adresse email du gouvernement, de la police, même encore d’une loterie pour facilement monter des arnaques ou du phishing.

 

Face à la multitude de spam et de tentative d’usurpation d’identité numérique qui sont vite devenus des problèmes majeurs dans le monde numérique (et donc également dans les emails), des protocoles ont peu à peu vu le jour dans le but de rajouter des mécanismes d’authentification et de sécurisation des emails.
Le but ici étant d’être en mesure de prouver que l’adresse expéditrice (d’un email reçu) est bien celle qu’elle prétend être, et donc que son authenticité soit prouvée.

 

Le protocole SPF est le premier protocole email qui a été créé dans le but de rajouter un mécanisme d’authentification du domaine expéditeur dans les emails.
Normalisé dans la RFC 7208, le SPF utilise un champ spécifique dans le DNS du domaine émetteur, afin d’indiquer quelles adresses IP ont le droit d’envoyer des emails en tant que ce domaine spécifique.
Le principe ici étant de lister l’ensemble des adresses IP qui sont susceptibles d’envoyer des emails en tant que ce domaine expéditeur, et ainsi permettre aux ESP de réception (gmail, hotmail, yahoo, etc) de déterminer si l’expéditeur d’un email reçu est bien celui qu’il prétend être.
Ainsi, les emails reçus dont l’expéditeur ne correspond pas aux adresses IP listées dans cet enregistrement DNS ont beaucoup plus de chances d’être de l’usurpation d’identité numérique, et peuvent ainsi etre plus facilement taggués en SPAM par les ESP email de réception.

 

L’enregistrement DNS du SPF est une simple entrée de type “TXT”, ou il est spécifié quelles adresses emails ou noms DNS sont autorisés à envoyer en tant que ce domaine expéditeur.
Voici un exemple de record SPF du domaine “france.fr” :

 

“v=spf1 ip4:83.166.152.41 include:turbo-smtp.com include:spf.protection.outlook.com -all”

 

Dans cet exemple, on peut déduire ceci :

 

– l’adresse IP  83.166.152.41 est autorisée

– les adresses IP inclues dans le SPF du domaine “turbo-smtp.com” sont autorisées (ceci permettant l’utilisation du SPF au travers d’un relai ou routeur email)

– les adresses IP inclues dans le SPF du domaine “spf.protection.outlook.com” sont autorisées (ceci permettant l’utilisation du SPF au travers du service de messagerie Outlook qu’utilise certainement ici le domaine “france.fr”)

 

–> Ces adresses IP et domaines relais sont donc autorisés au travers de cette entrée DNS du SPF à envoyer des emails de type “XXXXX@france.fr”

 

– les adresses IP autres que celles explicitement définies dans cet enregistrement SPF sont non pas autorisés, et ce de manière certaine (entrée “-all”)

 

Note : le “v=spf1” au départ indique qu’il s’agit bien d’une entrée pour le protocole SPF. Attention à ne pas confondre ce dernier avec le Sender ID, dont le champ DNS indique “spf2”, mais qui est un tout autre protocole d’authentification que le SPF.

 

Note: Il faut bien noter que le SPF authentifie un domaine (ou un sous-domaine) mais non pas une adresse email intégrale : ainsi grâce à l’enregistrement DNS d’exemple ci dessus, la validation SPF permettra de valider qu’un email reçu proviendra bien du domaine “france.fr”, mais ne donnera aucune garantie que l’émetteur était bien “sophie@france.fr” et non pas “paul@france.fr” par exemple.
Un risque de spoofing existe donc toujours malgré le SPF, même s’il ne pourra porter que sur la partie “username” de l’adresse email utilisée (le domaine étant quand à lui authentifié grâce au SPF) et non plus sur l’ensemble de l’adresse email (username + domaine)

 

Dans les faits, l’utilisation du SPF a été largement acceptée par les acteurs de l’emailing et représente aujourd’hui une norme couramment implémentée et utilisée. Tous les grands acteurs de l’emailing (ESP, routeurs email, etc) l’utilisent en permanence afin de réguler les tentatives d’usurpation d’identité des emails envoyés et reçus.
Les annonceurs et sociétés faisant de l’emailing de mass (bulk email) l’ont également largement implémentés, sous peine de voir un impact négatif sur leur réputation et délivrabilité (notamment depuis les dernières modification en 2024 de la politique de google et yahoo sur les emails marketing qui indiquent la nécessité de son implémentation)
Il faut toutefois noter que l’application du SPF n’est pas systématique sur tous les serveurs email du monde : de plus petit services d’hébergement emails, ou des services emails auto-hébergés, peuvent être configurés pour ne pas utiliser ce protocole, et sont donc plus susceptibles de laisser passer plus facilement les spam ou les phising reçus vers leur propres destinataires.

 

Le non-respect d’une politique SPF sur un email reçu (c’est à dire un email envoyé à partir d’une IP non autorisée) peut aboutir à la génération d’un soft bounce par le domaine de reception, afin d’indiquer que l’email n’a pas pu etre délivré au destinataire. La notification étant relative ici à une erreur temporaire, il n’ s’agira donc pas ici d’un hard bounce (voir ici pour plus de précision sur la différence entre les soft et les hard bounce)

 

Le protocole SPF présente néanmoins quelques faiblesses dans sa conception qui le rendent “incomplet” à lui-seul :

 

– l’authentification porte sur le domaine expéditeur et non pas sur l’adresse email dans sa totalité

– le fait d’autoriser les multiples IP d’un routeur ou provider email (tel que gmail, outlook, etc) peuvent favoriser les possibilités de contournement de ce protocole par des personnes mal-intentionnées qui auraient accès à l’envoi d’email au travers de ces mêmes IP également

– Le SPF supporte mal le passage par des “relais emails” : le fait d’envoyer un email à un destinataire qui à lui-même configuré le renvoi des emails reçus vers une autre boite email (au travers d’un relai email) va casser la protection SPF car l’IP du relai SMTP local n’est pas autorisé dans l’enregistrement SPF du domaine émetteur. Cela peut aboutir à des emails faussement rejetés ou perdus.

 

Afin de diminuer encore plus le risque d’usurpation d’identité numérique, le SPF est souvent configuré conjointement à d’autres mécanismes d’authentification tels que le DKIM et le DMARC. Ensemble, ils permettent une sécurisation maximale aussi bien pour le domaine émetteur que pour l’email destinataire, rendant ainsi les tentatives de fraudes beaucoup plus complexes.
Il faut toutefois bien garder en tête que la sécurisation au travers de ces whitelabels (SPF / DKIM / MARC) ne permet pas d’offrir une sécurité absolue et universelle contre les malveillances par email, mais ils en diminuent néanmoins largement le risque et la portée.