Qu’est-ce que le Sender Policy Framework (SPF) ? Le SPF appliqué aux e-mails expliqué

La méthode d’authentification Sender Policy Framework (SPF) identifie les serveurs de messagerie autorisés à envoyer des e-mails au nom d’un domaine donné. La norme SPF contribue à résoudre le problème de l’identification des sources officielles des e-mails d’une organisation. Lorsqu’une organisation configure SPF, cela aide les fournisseurs d’accès à Internet (FAI), les fournisseurs de solutions de sécurité des e-mails et les autres fournisseurs de messagerie à valider les communications électroniques d’une organisation et à distinguer les communications autorisées des e-mails usurpés ou des attaques d’hameçonnage qui tentent d’usurper l’identité de ce domaine.

Cet article explique notamment :

• Comment fonctionne le Sender Policy Framework ?
• Comment configurer SPF
• Avantages du Sender Policy Framework
• Limites du Sender Policy Framework
• FAQ sur le Sender Policy Framework
• En résumé : le SPF, une première étape essentielle pour éliminer l’hameçonnage

Comment fonctionne le Sender Policy Framework (SPF) ?

SPF permet une forme d’authentification des e-mails qui définit les domaines et les adresses IP (Internet Protocol) autorisés par une organisation à envoyer des e-mails. SPF est déployé dans les enregistrements du système de noms de domaine (DNS) auprès du fournisseur d’hébergement du domaine de l’organisation.

Les serveurs qui reçoivent les e-mails vérifient dans l’en-tête le domaine d’expédition, puis effectuent une recherche DNS pour voir s’il existe un fichier SPF correspondant à ce domaine. Lorsque le domaine d’expédition de l’enregistrement SPF correspond à celui indiqué dans l’en-tête de l’e-mail, celui-ci passe le contrôle SPF et peut être remis au destinataire. Lorsqu’aucun enregistrement SPF n’existe ou que le domaine d’expédition de l’e-mail ne correspond pas aux enregistrements DNS publiés, l’e-mail peut être rejeté ou envoyé dans un dossier de courrier indésirable.

Les fondamentaux de SPF

Pour comprendre le fonctionnement de SPF, il est important de comprendre la structure du fichier SPF et ses différentes options.

Structure de base d’un fichier SPF

L’Internet Engineering Task Force (IETF) publie toutes les informations relatives à SPF et à ses normes, qui ont été mises à jour pour la dernière fois en 2014. À la base, le fichier SPF est un simple fichier .txt téléversé dans l’enregistrement DNS du fournisseur d’hébergement du domaine de l’organisation. Il est également important de noter que les enregistrements SPF ne peuvent pas dépasser 10 balises ou 255 caractères, ce qui peut fortement limiter les grandes organisations.

Options d’un fichier SPF

La structure de base du fichier utilise la syntaxe suivante :

<version> <IP4 and/or IP6 address> <include: domain> <all tag>

• Version sera toujours « v=spf1 », car toutes les autres versions de SPF ont été abandonnées
• Adresse IP
• • Il peut s’agir de l’adresse IP4 ou IP6 correspondant aux adresses IP autorisées à envoyer des e-mails au nom du domaine
  • Elle sera au format ip4:<ip4-address>, ip4:<ip4-network>/<prefix-length>, ip6:<ip6-address>, ip6:<ip6-network>/<prefix-length>
  • La longueur de préfixe est supposée être /32 pour IP4 et /128 pour IP6 ; les longueurs de préfixe IP4 inférieures à /16 ne doivent pas être utilisées afin d’éviter tout impact sur les petits destinataires
• Include utilise la syntaxe « include:senderdomain.net », où senderdomain.net est le domaine d’un tiers autorisé à envoyer des e-mails au nom de l’organisation ; faire précéder la commande d’un « ? » indique que les e-mails doivent être considérés comme neutres plutôt que valides s’ils correspondent au domaine d’expédition
• Tous les tags fournissent aux autres serveurs des recommandations sur la manière de traiter les e-mails qui échouent au contrôle SPF :
• • -all = rejeter les e-mails qui échouent au contrôle SPF
  • ~all = marquer comme suspects les e-mails qui échouent au contrôle SPF
  • ?all = le serveur destinataire peut déterminer quoi faire des e-mails qui échouent au contrôle SPF
  • +all = autoriser n’importe quel domaine à envoyer des e-mails au nom de l’organisation (déconseillé)

Le Sender Policy Framework propose de nombreuses autres options, mais leur utilisation peut être dangereuse. Les organisations qui souhaitent les utiliser doivent travailler étroitement avec leurs fournisseurs et leur personnel informatique afin de garantir une syntaxe et une utilisation correctes. Voici quelques exemples d’options avancées :

• Le mécanisme « a » fournit un domaine ou une adresse réseau dans lequel tous les enregistrements sont vérifiés pour rechercher des correspondances
• Le mécanisme « mx » fournit une liste d’adresses IP de serveurs d’échange de messagerie
• « ptr » est utilisé par une organisation qui autorise tous ses serveurs à envoyer des e-mails ; il est rarement utilisé
• « exists » effectue une requête sur le domaine afin de rechercher une correspondance avec l’enregistrement SPF

Normes de messagerie associées

SPF fournit une authentification à portée limitée. Une solution plus robuste mettra également en œuvre les mécanismes d’autorisation DKIM et DMARC.

DKIM : DomainKeys Identified Mail (DKIM) permet à une organisation de signer numériquement les e-mails provenant de son domaine à l’aide de la cryptographie à clé publique.

DMARC : Domain-based Message Authentication Reporting and Conformance (DMARC) permet de contrôler plus directement les e-mails qui échouent aux contrôles SPF et DKIM et d’établir des rapports sur les e-mails légitimes et les e-mails usurpés.

Comment configurer SPF

Le Sender Policy Framework (SPF) peut être simple à configurer et à mettre en place. Dans sa forme la plus basique, SPF nécessite seulement la modification d’une ligne dans un enregistrement de domaine pour fonctionner. Par exemple, avec de nombreuses sociétés d’hébergement, il suffit de suivre les étapes suivantes :

1. Connectez-vous au bureau d’enregistrement du domaine et cliquez sur l’option permettant de gérer ou de configurer les paramètres DNS
2. Recherchez et cliquez sur l’option « Ajouter un nouvel enregistrement », puis choisissez un enregistrement « TXT »
3. Dans la boîte de dialogue du nom d’hôte, saisissez @ ou le nom de votre domaine.
4. Copiez-collez les informations SPF dans « valeur », ce qui définit les options SPF

Bien que simple en théorie, de nombreuses organisations ont des exigences spécifiques qui nécessitent des options ou des modifications supplémentaires. Par exemple, Google et Microsoft publient des instructions spécifiques pour inclure les serveurs de messagerie Gmail et Microsoft 365 dans les fichiers SPF. Après avoir rédigé un premier enregistrement SPF, l’organisation doit également consulter son fournisseur d’hébergement de domaine et ses différents services de messagerie (ex. : HubSpot, Mailchimp) afin de s’assurer que le SPF a été correctement rédigé et configuré.

Pour les organisations qui ont besoin d’une assistance supplémentaire, de nombreux services peuvent rédiger et activer SPF pour leur compte. Ces services sont disponibles soit de manière autonome, soit dans le cadre d’une offre incluant le déploiement de DMARC.

Vérification et dépannage de SPF

Après la mise en œuvre de SPF, l’enregistrement DNS peut mettre plusieurs jours à se propager sur Internet. Une fois cette propagation effectuée, l’entreprise peut envoyer des e-mails et inspecter leur en-tête à la recherche de « spf=pass ».

Bien entendu, il est facile de déployer SPF de manière incorrecte. En cas de problème, l’organisation doit donc vérifier les points suivants :

• Syntaxe incorrecte notamment les espaces superflus, les fautes de frappe, etc.
• Plus de 10 expéditeurs d’e-mails, car cela entraînera des erreurs. Si une organisation compte plus de 10 domaines d’expédition autorisés, elle devra peut-être établir plusieurs enregistrements SPF à l’aide de sous-domaines.
• Plus de 255 caractères entre les domaines d’expédition et les indicateurs facultatifs — ces enregistrements seront invalides, et le SPF devra être raccourci, corrigé et soumis à nouveau.
• Informations incorrectes sur le fournisseur, ce qui peut entraîner des échecs SPF. Travaillez avec le fournisseur pour vous assurer que les informations du SPF reflètent l’adresse IP ou le domaine précis utilisés pour envoyer les e-mails, plutôt que des domaines de retour, des URL de sites web, etc.
• Entrées « a » et « mx » inutiles, car elles peuvent créer de la confusion et entraîner des erreurs : au lieu de refléter l’adresse IP du serveur de messagerie sortant, l’adresse « a » correspond généralement à l’adresse IP de l’hébergeur web du domaine, tandis que les hôtes « mx » sont généralement utilisés pour les e-mails entrants.

Les fournisseurs d’authentification des e-mails tels que dmarcian proposent des outils gratuits permettant d’analyser rapidement l’enregistrement SPF et d’aider une organisation à résoudre les problèmes.

Avantages de SPF

Un SPF correctement configuré offre deux avantages tangibles majeurs : la réduction des usurpations d’identité et l’amélioration de la réputation du domaine. Pour la plupart des organisations, ces avantages devraient l’emporter sur les inconvénients, plus nombreux mais mineurs.

Réduction des usurpations d’identité

Les attaques d’hameçonnage par e-mail, dont l’usurpation d’adresse fait partie, tentent d’imiter des organisations légitimes afin d’accroître les chances de tromper le lecteur. Lorsqu’un SPF correctement configuré est déployé, il devient plus difficile d’usurper l’identité de l’organisation.

Lorsqu’un serveur de messagerie reçoit un e-mail usurpé, il compare l’adresse IP d’expédition au fichier SPF et rejette l’e-mail usurpé qui ne provient pas du serveur de messagerie de l’organisation. Cela contribue à protéger la réputation de l’entreprise en bloquant les e-mails indésirables qui tentent d’utiliser sa marque. Cela peut également bloquer les attaques d’hameçonnage qui tentent d’usurper l’identité des propres employés de l’organisation, par exemple lorsqu’une attaque tente de se faire passer pour le PDG.

Amélioration de la réputation du domaine

Lorsqu’une organisation ne met pas en place SPF, les serveurs de messagerie qui reçoivent ses e-mails peuvent les signaler ou les rejeter, car l’authenticité du domaine de l’organisation ne peut pas être vérifiée. La mise en place de SPF améliore la réputation du domaine de l’organisation et le taux de distribution des e-mails légitimes.

Limites du Sender Policy Framework

SPF protège contre le spam, l’usurpation d’identité et l’hameçonnage par e-mail, et renforce la sécurité des e-mails dans le monde entier. Cependant, il présente également de nombreuses limites, quoique plus mineures.

Une maintenance difficile

Les organisations doivent constamment tenir leurs enregistrements SPF à jour, même lorsque leurs fournisseurs changent de serveurs de messagerie, que l’organisation change de fournisseur d’accès à Internet ou que le service marketing ajoute de nouveaux services de newsletters. Les modifications peuvent être longues et fastidieuses à vérifier avec toutes les parties concernées, ce qui rend les mises à jour DNS difficiles à effectuer régulièrement.

Vulnérable en cas de transfert incorrect des e-mails

Les e-mails transférés changent souvent d’adresse IP d’expédition, ce qui entraîne l’échec du contrôle SPF. Les organisations doivent corriger les paramètres de leurs serveurs afin que les e-mails transférés conservent les informations correctes, mais beaucoup ne le font pas.

Une solution incomplète

SPF vérifie uniquement le domaine d’expédition indiqué dans l’en-tête de l’e-mail et ne le compare pas à l’adresse e-mail « from » présentée à l’utilisateur. Si un attaquant pratiquant l’hameçonnage applique son propre fichier SPF avec son propre domaine d’expédition, le contrôle SPF sera considéré comme valide. Pour une protection plus robuste, SPF, DKIM et DMARC doivent être utilisés conjointement afin de protéger la réputation d’une organisation et de valider les e-mails.

Problèmes propres aux grandes organisations

Plus une organisation est grande, plus elle est susceptible de disposer d’un grand nombre de serveurs et de services envoyant des e-mails pour son compte. Avec une limite de 255 caractères et une limite de 10 recherches DNS, les grandes organisations ne peuvent pas publier toutes leurs adresses IP d’expédition dans un seul enregistrement SPF. Elles doivent donc utiliser des sous-domaines pour contourner les limites de SPF.

Des mesures de ROI peu concluantes

Bien que l’organisation puisse constater une amélioration de sa réputation et une distribution plus fiable de ses e-mails, ces avantages seront difficiles à quantifier dans le cadre de la mesure du retour sur investissement. De plus, le principal avantage profite généralement à d’autres acteurs : les serveurs de messagerie et les outils de sécurité des e-mails qui reçoivent les e-mails et vérifient l’enregistrement SPF afin de bloquer le spam et l’hameçonnage. Si l’investissement nécessaire à la mise en œuvre de SPF est faible, le ROI et les avantages intangibles expliquent pourquoi son adoption n’est pas supérieure à 50%.

Potentiellement usurpable

SPF peut être adopté par n’importe quelle organisation, y compris les acteurs malveillants et les spammeurs. Comme un contrôle SPF n’inclut pas les informations « From » du corps de l’e-mail, les acteurs malveillants peuvent publier leur propre fichier SPF afin d’authentifier leurs e-mails usurpés ou leurs spams avec les informations de leur propre domaine, puis présenter au destinataire des informations complètement différentes dans le champ « From » visible dans le logiciel de messagerie.

Nécessite des paramètres de serveur de messagerie appropriés

SPF ne fonctionne que sur les serveurs de messagerie configurés pour vérifier SPF ou qui utilisent des outils de sécurité des e-mails effectuant la même tâche. Les serveurs peuvent facilement ignorer les contrôles SPF et laisser proliférer les e-mails indésirables et usurpés.

FAQ sur SPF :

En résumé : le SPF, une première étape essentielle pour éliminer l’hameçonnage

L’hameçonnage reste le principal vecteur des attaques visant la cybersécurité et des attaques réseau car trop d’e-mails usurpés ne sont toujours pas signalés. SPF constitue la première étape du processus d’authentification des e-mails SPF-DKIM-DMARC, qui pourrait bloquer la grande majorité des e-mails d’hameçonnage si suffisamment d’organisations adoptaient SPF ainsi que DKIM et DMARC. Bien que sa maintenance soit fastidieuse, le faible coût de déploiement de SPF devrait inciter toutes les organisations à adopter SPF comme première étape pour lutter contre l’hameçonnage par e-mail dans le monde entier — ou, à tout le moins, pour se protéger contre l’hameçonnage usurpant leur propre domaine.