Le fonctionnement du SPF a été initialement défini par la norme RFC4408 (https://tools.ietf.org/html/rfc4408) en avril 2006.
Le principe est simple : communiquer une liste des serveurs mails autorisés à émettre des messages en son nom (càd : avec une adresse email utilisant son nom de domaine).
Avant la création du SPF, il était impossible d’empêcher un tiers d’émettre un mail en simulant l’expédition depuis une adresse email de son choix. N’importe qui pouvait par exemple envoyer un mail en tant que president@elysee.gouv.fr, ou service-client@ma-banque.fr.
L’ usurpation d’identité et le phishing étaient fréquents car moins facilement détectables.
Le SPF a apporté un moyen de sécuriser les échanges par mail en permettant à n’importe quel propriétaire de nom de domaine d’indiquer, dans sa zone DNS, la liste des serveurs autorisés à émettre des mails en son nom.
Un mail en @societe.fr émis par un serveur présent dans cette liste doit alors être considéré comme un message légitime, tandis qu’un mail émis par un serveur absent de cette liste doit être considéré comme un mail falsifié et donc classé en spam ou directement dans la corbeille.
C’est le serveur du destinataire, lorsqu’il fait analyser le message entrant par son propre antispam, qui effectue un test en comparant l’IP de l’émetteur avec celles listées par le champ SPF du domaine annoncé, et détermine alors si celui ci est légitime ou non et donc ce qu’il doit faire du message.
Sur le plan technique, le champ SPF est un champ de type TXT (valeur texte) présent dans la zone DNS du domaine. Il commence systématiquement par la mention : « v=spf1 ». Suit alors une liste de serveurs autorisés (souvent indiqués par leurs adresses IP), puis en général un dernier paramètre excluant les autres serveurs.
Exemple 1 :
v=spf1 ip4:56.247.32.101 a -all
Dans l’exemple ci dessus, seule l’adresse IP 56.247.32.101 est autorisée, ainsi que l’IP du serveur qui héberge le site (indiquée simplement par « a »), et tout le reste est interdit (-all).
Exemple 2 :
v=spf1 ip4:14.27.130.8 ip4:14.27.130.9 ip4:14.27.130.10 -all
Dans l’exemple ci dessus, seules les adresses IP 14.27.130.8, 14.27.130.9 et 14.27.130.10 sont autorisées, et tout le reste est interdit (-all).
Exemple 3 :
v=spf1 ip4:90.121.17.55 include:spf.powermail.fr -all
Dans l’exemple ci dessus, seule l’adresse IP 90.121.17.55 est autorisée, ainsi que toute IP autorisée par le champ SPF de spf.powermail.fr, et tout le reste est interdit (-all).
Le mécanisme « include » est souvent utilisé car il permet de déléguer le contrôle de listes de serveurs à des prestataires tiers, qu’il s’agisse de prestataires de routage d’emailing, de son hébergeur mail, de son hébergeur web ou de tout autre intervenant technique susceptible de devoir émettre des mails en @societe.fr.
Le mécanisme « ip4 » peut être utilisé pour spécifier des plages d’IP si vous avez besoin d’autoriser un grand nombre de serveurs voisins. Exemple : ip4:72.22.18.0/24
Bon à savoir : une erreur très répandue, le non respect des standards
Le dernier paramètre à la fin du champ SPF permet de définir le comportement à adopter lorsqu’un message ne semble pas venir d’un serveur autorisé.
De nombreux hébergeurs utilisent le modulateur « ~all », celui ci est théoriquement à n’utiliser qu’en phase de test, lorsque l’on met en place le champ SPF et que l’on souhaite détecter si un message échouerait au test sans pour autant le bloquer si c’est le cas. C’est donc un mécanisme temporaire, destiné à n’être utilisé que quelques heures ou quelques jours.
Or lorsque ces hébergeurs utilisent ce modulateur sur le long terme, cela signifie qu’ils se trompent et ne respectent pas les règles officielles standardisées par la RFC.
Conséquence concrète pour les utilisateurs : des messages échouant au tests vont parfois être bloqués et parfois non. Des utilisateurs dont le domaine est mal configuré vont parfois voir leurs mails arriver à destination et parfois non, et croiront à tort que le problème se situe du côté du destinataire, alors qu’en réalité le problème vient de leur propre nom de domaine.
Et sur le principe, si l’on a bien établi sa liste de serveurs autorisés, on a tout intérêt à bloquer totalement les mails qui échoueraient au test puisque l’on peut être sûr que ce sont des spams !
Gare aux réglages par défaut !
Autre point important : pas de réglage vaut mieux qu’un mauvais réglage !
En effet, un nom de domaine qui ne possède pas de champ SPF fonctionne normalement, il est simplement vulnérable à l’usurpation d’identité.
A contrario, un nom de domaine dont le champ SPF est mal configuré et laissé par exemple à sa valeur par défaut provoquera des problèmes constants de délivrabilité des mails pour les utilisateurs, leurs messages arrivant fréquemment dans les spams de leurs interlocuteurs.
Tout bien considéré, ce deuxième cas de figure est bien plus problématique que le premier.
Exemple de problème fréquent
Nous sommes souvent interpellés par des clients qui cherchent à comprendre leurs soucis de délivrabilité au niveau de leur messagerie professionnelle.
Un cas de figure fréquent est une société hébergeant son site web chez OVH et utilisant un service tiers pour envoyer des emailings (www.mon-emailing.net, www.mailjet.com …), qui constate que les mails arrivent souvent en spam chez les destinataires.
En regardant leur champ SPF on constate qu’il a la valeur suivante :
v=spf1 include:mx.ovh.com ~all
Cela indique un double problème : d’une part ils n’ont pas intégré de paramétrage pour autoriser leur prestataire emailing à émettre des mails en leur nom, et d’autre part il s’agit du réglage par défaut d’OVH qui utilise le mauvais modulateur (~all) et donc les laisse exposés à l’usurpation d’identité.
Le champ peut alors être corrigé via le manager OVH de la manière suivante :
v=spf1 include:mx.ovh.com include:spf.mon-emailing.net -all
Cas concrets observés de mauvaise configuration du champ SPF
Ne pensez pas que seules les petites sociétés se font avoir par l’une ou l’autre des erreurs de configuration du champ SPF. Cela arrive même aux plus grosses ! Voici quelques exemples réels observés chez PowerMail sur des messages entrants pourtant légitimes.
- Hiscox : mail envoyé par mta-222-95.sparkpostmail.com qui n’est pas autorisé
- Spotify : mail envoyé par o8.em.spotify.com qui n’est pas autorisé
- American Airlines : mail envoyé par mta214a-ord.mtasv.net qui n’est pas autorisé
Conclusion
Le champ SPF n’est pas la panacée du filtrage antispam mais c’est un outil très utile puisqu’il permet facilement de se protéger, et de protéger les autres, contre l’usurpation d’identité dans les échanges mails.
