Sélectionner une page

Nous allons voir dans cet article qu’il est intéressant d’utiliser SPF pour permettre à vos correspondants de valider que vous êtes « légitimement » l’expéditeur d’un email.

Nous aborderons donc ce qu’est SPF, à quoi ça sert, comment marchent les règles SPF et comment les appliquer dans le DNS.

Au fil de l’article, nous parlerons d’enregistrements DNS, qui font généralement le lien entre noms de domaine et adresses réseaux sur Internet, mais peuvent aussi contenir d’autres informations.

Pour le moment, un seul prérequis technique est nécessaire.

Savoir ce qu’est un « serveur d’envoi de mail ». Un serveur d’envoi de mail (ou SMTP) est celui que vous désignez dans votre logiciel de messagerie (Thunderbird, Outlook) quand vous remplissez les champs « serveur d’envoi » ou « serveur sortant ». Des serveurs d’envoi courants sont smtp.mail.me.com, smtp.free.fr ou alice.octopuce.fr.

Expérience brève mais instructive.

Avez-vous déjà essayé d’envoyer des emails à la place d’une autre personne ? Sinon, peut-être vous est-il arrivé de recevoir des emails émis avec votre propre adresse mail ?

Ce genre de « pratique malicieuse » est en réalité assez simple à réaliser : il suffit de configurer un nouveau compte dans votre logiciel de messagerie avec un serveur d’envoi valide et l’adresse email de votre choix.

Et c’est à cela que SPF est utile : sans SPF, tout mail d’un domaine donné -i.e. mail@domaine- peut être facilement abusé pour l’envoi.

Prenons un exemple : le domaine ILEDEFRANCE.FR -conseil général d’Ile de France- n’a pas de SPF au 01/01/2017 : envoyer un mail en prétendant être « valerie.pecresse@iledefrance.fr » fonctionnera à merveille : votre message arrivera dans la boîte mail de votre destinataire !

En revanche, si vous prétendez être « presidence@elysee.fr » ça fonctionnera moins bien : le domaine ELYSEE.FR a du SPF, il est protégé. Votre mail sera vu par le serveur du destinataire comme étant potentiellement frauduleux.

Voilà donc en résumé à quoi SPF est utile. S’assurer qu’un email a bien été expédié par un serveur qui en a le droit.

Le SPF protège donc de l’usurpation d’identité tous les utilisateurs de boîtes mail pour un domaine donné : les serveurs destinataires vont rejeter les messages non conformes au SPF, c’est-à-dire ne provenant pas d’un serveur de messagerie autorisé.

Il a un autre avantage, non des moindres.

Les prestataires de mail favorisent les mails provenant de domaines utilisant SPF, qui leur permettent de s’assurer que les expéditeurs sont légitimes dans la chasse au SPAM. Une chance de plus pour vous de ne pas risquer de vous retrouver dans la boîte Indésirables de vos destinataires.

Si le SPF est aussi pratique, pourquoi n’est-il pas toujours actif par défaut ?

Tout simplement parce que pour qu’une règle SPF fonctionne, il faut que tous les utilisateurs qui ont des mails sur un domaine respectent la règle SPF pour ce domaine.

Un exemple : un salarié en télétravail veut envoyer un mail pro depuis son smartphone configuré pour utiliser le serveur d’envoi de son fournisseur mobile (ex: smtp.bouygtel.fr).

Si l’enregistrement SPF de son entreprise n’a pas explicitement autorisé les serveurs d’envoi de BOUYGTEL, cela ne marchera pas.

Les serveurs SMTP destinataires vont considérer que c’est un affreux spammeur et mettre son email à la poubelle.

Il faut donc qu’il configure son smartphone pour utiliser le serveur d’envoi de sa société (ex: SMTP.MABOITE.FR ).

Pour que SPF fonctionne, il faut définir une politique appliquée par des humains, au contraire de tant de choses qui sont automatisées par des serveurs dans le « mail » en général.

Votre prestataire de mail ne peut généralement pas déclarer arbitrairement un SPF pour votre domaine sans votre validation, au risque de perturber vos envois de messages.

Je veux du SPF pour mon domaine. Quel est le mode d’emploi ?

Il va falloir déterminer les « sources » que vous souhaitez annoncer dans le DNS.

Qu’est-ce qu’une « source » pour SPF ? Il s’agit d’une ou plusieurs adresses IP. La plupart des prestataires de mail fournissent à leurs clients une source facile à utiliser, contenant toutes les adresses IP émettrices de mail.

Dans les faits, la procédure se fait en 4 temps :

  1. Définir les serveurs et/ou adresses IP qui émettent du mail pour votre domaine
  2. S’assurer que toutes les personnes utilisant des mails sur votre domaine utilisent bien un des serveurs de ces adresses IP
  3. Rédiger la règle SPF adaptée
  4. Ajouter votre règle au DNS

1. Définissez donc les serveurs et/ou adresses IP qui vont émettre du mail pour votre domaine.

Cette partie détermine quelle politique d’envoi de mail sera appliquée : elle dépend à la fois de vos pratiques actuelles et des objectifs.

Quelles sont les sources actuelles des mails pour votre domaine ?

  • Source unique : votre serveur

    Configuration la plus simple, dans laquelle vous expédiez déjà tous vos emails depuis un -et un seul- serveur.
    Par exemple, vous avez un compte mutualisé chez Octopuce (Félicitations ! ;) sur le serveur ALICE.OCTOPUCE.FR.
    Ce serveur expédie aussi bien les mails de tous vos utilisateurs que ceux de votre site en PHP (page contact).
    Il s’agit d’une source unique, votre prestataire -ici Octopuce- vous la fournit ou bien vous assignerez directement les adresses IPv4 ou IPv6 de votre serveur.
  • Source unique : Prestataire expéditeur
    Vous n’envoyez pas de mails depuis votre site et vous utilisez par exemple les services de gmail ou office365.
    Ou bien vous n’envoyez pas de mails mais uniquement des newsletters et vous passez par mailjet ou mailchimp.
    Vous ne savez pas exactement lequel des nombreux serveurs de votre prestataire sera utilisé au final, mais ça n’a aucune importance.
    Ce cas n’est pas très différent du précédent, votre prestataire vous fournit la source à utiliser.
  • Sources multiples
    Ça se complique un peu : par exemple, vos mails partent par votre serveur chez Octopuce, votre smartphone chez SFR, Gmail et Mailchimp ?
    Renseignez-vous auprès des différents prestataires qui doivent publier des informations concernant SPF, leurs « sources ». Voir plus bas les informations sur les « include » pour plus de détails.
    Pour continuer à envoyer du mail comme aujourd’hui, collectez ces sources auprès de vos prestataires.

Quels sont vos objectifs ?

Deux facteurs essentiels :

  • Nombre de sources
    Si vous avez des sources multiples, c’est potentiellement le moment de réduire leur nombre pour simplifier la règle SPF.
  • Rigueur
    Vous allez pouvoir indiquer une souplesse d’usage -un laxisme- à votre règle SPF: indiquer s’il est normal, possible ou anormal qu’un mail émis pour votre domaine ne respecte pas la règle. Plus vous serez rigoureux en respectant une règle peu laxiste, plus efficace elle sera.

2. Assurez-vous que vos utilisateurs utilisent les bons serveurs d’envoi

Informez les personnes ayant un mail sur le domaine concerné du changement à venir. Une explication de l’intérêt de ce changement peut les intéresser : n’hésitez pas à utiliser si besoin notre infographie.

Indiquez le serveur d’envoi standard ainsi que les moyens de vérifier ou modifier son serveur d’envoi dans son client de messagerie.

Quand tout le monde est prêt, passez à l’acte !

Le coin du chercheur

Ça fait quoi, include:spf.octopuce.fr ?

Creusons un peu. SPF autorise dans sa syntaxe la notion d’include. Mais à quoi correspond cette notion ?

Pour le savoir, utilisons un terminal et l’outil dig qui permet de faire des requêtes DNS.

Prenons l’exemple du site ELYSEE.FR dont on parlait précédemment.

Faisons la requête suivante sur son enregistrement TXT, quasi toujours utilisé pour SPF.

# Cherche les enregistrement TXT pour le site elysee.fr (dig TXT elysee.fr) et n'affiche que les résultats (+short)
$ dig +short TXT elysee.fr 
"v=spf1 mx ip4:84.233.174.57 ip4:78.40.125.24 ip4:78.40.125.69 -all"    

Ah, pas de include, seulement 3 adresses.

Recherche d’un domaine valide pendant 10 minutes… à la fois simple et fonctionnel. Avec des trucs cassés comme education.gouv.fr ou gouv.fr tout court…

Bon. Essayons donc avec le domaine octopuce.fr

$ dig +short  TXT octopuce.fr

"mailconf=https://autodiscover.octopuce.fr/mail/mailautoconfig.xml"

"v=spf1 a mx include:spf.octopuce.fr ?all"

On voit que les champs TXT peuvent contenir autre chose que du SPF. Mais on a un include. Creusons donc.

$ dig +short  TXT spf.octopuce.fr

"v=spf1 ip4:91.194.60.0/23 ip4:193.56.58.0/24 ip4:185.34.32.0/22 ip6:2001:67c:288::/48 ip6:2a00:99a0::/32 ?all"

Et voilà. Derrière le include peuvent se cacher des IPs, voir d’autres include ! essayez de voir spf.protection.outlook.com ou _spf.google.com :)

Notez que vous pouvez faire les mêmes requêtes sur des outils DNS en ligne gratuits comme ici ou .

3. Le moment est venu de rédiger la règle SPF pour votre domaine.

(Pour une information exhaustive sur la notation SPF, voir http://www.openspf.org/SPFRecordSyntax )

C’est la partie « syntaxique » du processus. Une règle SPF est une « phrase » qui doit respecter une grammaire et un lexique particulier.

Pour simplifier la vie des utilisateurs, il existe des générateurs de règles SPF en ligne.

Ceci étant, la syntaxe n’est pas extrêmement compliquée. Voici quelques exemples.

  • La règle la plus simple« v=spf1 mx all »
    - "v=spf1" : version de SPF 
    - "mx" : autorise l'envoi depuis les adresses DNS des champs MX du domaine, qui déterminent les serveurs de réception de vos mails.
    - "+all" : appliquer le traitement le plus souple : cette règle est purement indicative
    
  • Serveur unique« v=spf1 mx ip4:91.194.60.254 ?all »
    - "v=spf1" : version de SPF 
    - "ip4:91.194.60.254" : autorise l'envoi depuis l'adresse IP v4 du serveur ( utiliser "ip6:" pour les adresses v6)
    - "?all" : appliquer le traitement le plus souple : des serveurs supplémentaires, non inclus dans la règle, peuvent faire des envois
    
  • Fournisseur unique « v=spf1 a mx include:spf.octopuce.fr ~all »
     - "v=spf1" : version de SPF 
    - "mx a " : autorise l'envoi depuis les adresses DNS des champs A, et MX du domaine
    - "include:spf.octopuce.fr" : autorise les adresses définies par Octopuce 
    - "~all" : appliquer le traitement moyen : tout mail ne respectant pas la règle ne doit pas être bloqué mais considéré comme suspicieux 
    
  • Sources multiples« v=spf1 include:spf.octopuce.fr include:_spf.google.com include:spf.mailjet.com -all »
     - "v=spf1" : version de SPF 
    - "include:spf.octopuce.fr" : autorise les adresses définies par Octopuce 
    - "include:_spf.gmail.com" : autorise les adresses définies par Gmail 
    - "include:spf.mailjet.com" : autorise les adresses définies par Mailjet
    - "-all" : appliquer le traitement dur : tout mail ne respectant pas la règle peut être rejeté 
    

4. Finalement, vous devez ajouter cette règle aux enregistrements DNS de votre domaine

Où ajouter une règle SPF pour son domaine ?

Votre fournisseur de services DNS doit vous mettre à disposition une interface permettant d’éditer les entrées DNS de votre nom de domaine.

Si, par exemple, vous louez votre nom de domaine chez Gandi et que Gandi vous fournit le service DNS, c’est dans cette interface que vous devez ajouter la règle SPF.

En revanche si vous louez votre nom de domaine chez Gandi mais que vous gérez la zone DNS de votre domaine sur votre AlternC, c’est dans cet AlternC que vous devez ajouter la règle SPF.

Dans le doute, renseignez-vous auprès de votre prestataire ou de votre logiciel d’édition de champs DNS concernant l’insertion de champs SPF.

Dans quel enregistrement mettre la règle SPF ?

Pour chaque nom de domaine, il existe plusieurs enregistrements DNS possibles, comme les enregistrements A (adresse IP V4), MX (serveur de réception de mail), ou TXT (informations textes libres).

En l’occurence, c’est dans un enregistrement TXT qu’on stocke les règles SPF. Il existe un type d’enregistrement dédié SPF mais dont l’usage est abandonné.

Il suffit donc d’ajouter un enregistrement TXT à votre domaine, d’y ajouter la règle SPF élaborée à l’étape précédente, et voilà !

Votre nom de domaine a désormais une règle SPF active qui sera appliquée le temps de la propagation DNS.

Les évolutions de vos règles SPF et de vos autres enregistrements DNS mail

Changement de la règle SPF

Une fois votre règle SPF défini, vous devrez le faire évoluer à chaque fois que vous changerez la liste des prestataires émettant du mail pour votre domaine.

En revanche, c’est tout l’intérêt de la syntaxe « include:XXX » que de déléguer à votre prestataire la modification régulière des adresses autorisées à envoyer du mail pour leurs serveurs.

Vous pourrez également au fil du temps et des usages modifier la rigueur de la règle selon sa bonne application par les usagers.

Évolutions globales du SPF et des autres champs DNS pour le mail

Prenons finalement le temps pour quelques considérations sur l’avenir de SPF et des enregistrements liés au mail dans le DNS.

SPF v1 : Est-ce qu’il faut attendre la v2 pour s’y mettre ?

Absolument pas. Il n’est pas question pour le moment d’une v2. Pour une raison assez simple : Microsoft a essayé de pousser spf2.0 tout seul dans son coin, sans concertation. Voir http://www.openspf.org/SPFvsSender_ID pour plus de détails.

Pour le moment, c’est la version v1 qui est standard, ce qui est bien assez difficile dans le monde d’Internet, en particulier pour le mail

Est-ce que SPF est compatible avec DKIM & DMARC ?

Oui. Tous les trois sont des enregistrements DNS à associer à votre domaine, et ils sont complémentaires.

DKIM sert à rendre crédible vos mails grâce à des signatures cryptographiques. Les enregistrements DNS contiennent la clef publique qui permet de valider l’intégrité des informations du mail (titre, expéditeur, destinataire, date etc.) signées par la clef privée.

DMARC sert à rendre publique quels enregistrements DNS un domaine utilise pour ses mails et avec quelle rigueur, mais aussi par exemple quelles adresses utiliser pour les rejets.

Il est donc vivement conseillé d’utiliser ces différents enregistrements DNS pour sécuriser les emails de ses domaines.

Je n’ai pas confiance en SPF, car c’est basé sur du DNS, et le DNS c’est pas fiable. J’ai raison ?

Partiellement. Par défault, le DNS n’est pas sécurisé et des abus ont été pratiqués à de multiples reprises.

Mais il existe un moyen de mieux sécuriser ses enregistrement : DNSSEC, un protocole complexe qui signe  les enregistrements DNS.

Donc sur le principe, votre fournisseur de DNS doit utiliser DNSSEC. Cependant, la complexité de ces enregistrements est telle qu’on est loin de le voir appliqué partout (~15% de domaines signés dans le monde).