Échec du SPF : ce que cela signifie et comment y remédier

Une défaillance du SPF peut sembler n'être qu'un simple problème de routage du courrier jusqu'à ce qu'elle commence à avoir des répercussions sur le placement dans la boîte de réception, la confiance accordée à l'expéditeur et la protection contre l'usurpation d'identité. Ce guide explique ce qu'est le SPF, ce que signifient les différents messages d'échec liés au SPF, pourquoi ils surviennent et comment y remédier sans créer de nouveaux problèmes d'authentification.

Qu'est-ce que le SPF dans l'authentification des e-mails ?

Le SPF (Sender Policy Framework) est une méthode d'authentification des e-mails qui permet de vérifier si un serveur de messagerie est autorisé à envoyer des e-mails au nom d'un domaine. Ce système fonctionne en publiant un enregistrement DNS qui répertorie les sources d'envoi autorisées, fournissant ainsi au destinataire une règle à appliquer pour vérifier l'adresse IP de l'expéditeur.

Cela revêt une importance particulière en matière de sécurité des e-mails, car le protocole SPF contribue à réduire l'usurpation de domaine. Lorsqu'un domaine publie des règles d'autorisation claires, il devient plus difficile pour les expéditeurs non autorisés de se faire passer pour ce domaine dans le cadre Phishing, de spam ou d'autres messages frauduleux.

Qu'est-ce qu'une défaillance du SPF ?

Un échec SPF signifie que le serveur destinataire n'a pas pu vérifier que la source de l'envoi était autorisée conformément à la politique SPF publiée par le domaine. Concrètement, le SPF vérifie si le serveur expéditeur est autorisé à envoyer des e-mails pour le domaine « envelope-from ». Un échec SPF se produit lorsque cette source ne correspond pas à la politique, tandis que d'autres types d'erreurs SPF peuvent survenir lorsque la vérification ne peut pas être évaluée correctement en raison de problèmes de syntaxe ou liés au DNS.

Cela va bien au-delà de la simple authentification. Les défaillances du SPF peuvent réduire le taux de livraison dans la boîte de réception, déclencher un filtrage ou entraîner un rejet pur et simple, en fonction des règles de sécurité du destinataire et de la manière dont les protocoles DKIM et DMARC sont configurés en parallèle du SPF. Des échecs répétés du SPF peuvent également éroder la confiance accordée à l'expéditeur et, à terme, compliquer les communications professionnelles légitimes.

Types de défaillances du SPF

Des résultats SPF différents indiquent différents types de problèmes. Certains indiquent un véritable échec d'autorisation, tandis que d'autres mettent en cause l'absence de politique, une politique insuffisante, des problèmes DNS temporaires ou des problèmes permanents au niveau des enregistrements.

Indice de protection solaire : Aucun

Un résultat « SPF none » signifie que le serveur destinataire n'a trouvé aucune politique d'autorisation publiée à laquelle se référer. Il n'existe aucun enregistrement SPF pour ce domaine ou ce nom d'hôte ; l'authentification SPF ne peut donc pas évaluer correctement les expéditeurs autorisés.

SPF neutre

Le terme « SPF neutre » signifie que le domaine dispose d'un enregistrement SPF, mais que la politique n'indique pas clairement si la source d'envoi doit être autorisée ou rejetée. Il s'agit davantage d'un signal timide que d'une décision d'autorisation ferme.

SPF Softfail

Un « softfail » SPF signifie que l'expéditeur n'est probablement pas autorisé, mais que la politique n'est pas suffisamment stricte pour imposer un rejet pur et simple. Dans la pratique, cela s'accompagne souvent de « ~all », ce qui indique aux destinataires de considérer le message comme suspect plutôt que comme définitivement invalide.

SPF Hardfail

Une erreur « hardfail » SPF signifie que la source émettrice n'est pas autorisée et que la politique SPF indique explicitement que le message doit être rejeté. Cette option est généralement associée à l'option -all, qui exprime une politique plus stricte que le « soft fail ».

SPF Temperror

Le code d'erreur « temperror » de SPF indique un problème temporaire survenu lors de l'évaluation, tel qu'un délai d'attente DNS ou un échec de résolution. L'expéditeur est peut-être légitime, mais le destinataire ne peut pas effectuer la vérification SPF de manière fiable à ce moment-là.

Erreur permanente SPF

Une erreur permanente SPF signifie qu'il existe un problème permanent au niveau de l'enregistrement SPF ou de son chemin d'évaluation. Parmi les causes courantes, on peut citer une syntaxe SPF incorrecte, la présence de plusieurs enregistrements SPF pour un même domaine ou un nombre trop élevé de requêtes DNS.

Ces résultats sont utiles car ils permettent de déterminer si le problème est lié à l'autorisation, à une politique insuffisante, ou à un problème de DNS ou de syntaxe. Cela permet de cerner plus facilement la partie concernée du problème.

Quelles sont les causes d'une défaillance du SPF ?

Les défaillances du SPF ne sont pas toutes dues au même type de problème. Les causes les plus courantes énumérées ci-dessous montrent à quel niveau le SPF a tendance à présenter des défaillances et expliquent pourquoi le problème ne se résume pas toujours à une simple question d'autorisation de l'expéditeur.

Sources d'envoi non autorisées

La cause la plus fréquente est un problème d'autorisation. Le message provient d'une adresse IP ou d'une plateforme d'envoi qui ne figure pas dans l'enregistrement SPF du domaine. Cela se produit souvent à la suite de modifications apportées à l'infrastructure, de migrations vers le cloud ou de l'ajout de nouvelles plateformes SaaS sans que l'enregistrement n'ait été mis à jour.

Enregistrements SPF défectueux ou obsolètes

L'hygiène des dossiers est un autre problème courant. Une syntaxe SPF incorrecte, des mécanismes obsolètes et la présence de plusieurs enregistrements SPF peuvent tous entraîner des problèmes d'évaluation. Étant donné qu'un domaine ne doit publier qu'un seul enregistrement TXT SPF par nom d'hôte, la présence d'enregistrements en double peut entraîner l'échec des vérifications SPF, même lorsque des expéditeurs légitimes sont présents.

Limites de recherche DNS et inclusions imbriquées

Les environnements d'entreprise sont souvent confrontés à des problèmes d'évaluation plus complexes. Les chaînes d'inclusion imbriquées, les expéditeurs SaaS tiers et le surcroît de données DNS hérité peuvent faire atteindre à l'enregistrement la limite de recherche DNS. Lorsque l'évaluation SPF nécessite plus de 10 requêtes DNS, elle peut renvoyer une erreur permanente (« permerror ») au lieu d'un résultat d'autorisation valide.

Transfert d'e-mails

Le transfert d'e-mails est une autre source fréquente de confusion. Un message transféré peut tout à fait être légitime, mais la validation SPF peut échouer car le serveur de transfert n'est généralement pas autorisé dans l'enregistrement SPF du domaine d'origine. Cela signifie que le destinataire voit une adresse IP source différente de celle prévue par la politique SPF.

Ces causes sont importantes car elles ont une incidence à la fois sur la rapidité du dépannage et sur la qualité de la solution apportée. Certains mettent en cause des expéditeurs non autorisés, tandis que d'autres évoquent la qualité des fichiers, les limites DNS ou le comportement du flux de messagerie, qui nécessitent une réponse différente.

Comment diagnostiquer une défaillance du SPF

Commencez par identifier la politique SPF actuellement en vigueur pour ce domaine. Dans la plupart des cas, l'enregistrement commence par « v=spf1 », ce qui permet de l'identifier comme la politique SPF du domaine. Vous pouvez le vérifier à l'aide d'outils de recherche DNS, de commandes en ligne de commande ou du portail de gestion DNS avant d'effectuer la moindre modification.

Passez ensuite au message lui-même. Vérifiez l'intégralité des en-têtes de l'e-mail et les résultats de l'authentification afin de confirmer le résultat exact du SPF, plutôt que de supposer que chaque problème correspond à un échec total. À partir de là, comparez côte à côte le domaine d'origine de l'enveloppe, l'adresse IP d'expédition et l'enregistrement DNS de type TXT publié.

Pour le dépannage, il est utile de répondre à quelques questions précises :

• Le domaine publie-t-il un enregistrement TXT SPF valide ?
• L'enregistrement indique-t-il le service ou l'adresse IP qui a effectivement envoyé le message ?
• Y a-t-il trop d'inclusions imbriquées ou de requêtes DNS ?
• Le message échoue-t-il en raison d'un transfert plutôt que d'un véritable problème lié à l'expéditeur ?

Un diagnostic plus précis rend la réparation plus fiable. Une fois que vous savez si le problème provient de l'autorisation de l'expéditeur, de la structure de l'enregistrement ou du comportement du flux de messagerie, il devient beaucoup plus facile de corriger l'élément concerné de la configuration.

Comment résoudre un problème lié au SPF

Pour résoudre un problème lié au SPF, il suffit généralement de s'assurer de l'authentification correcte de l'expéditeur et d'une gestion rigoureuse des enregistrements. Les étapes ci-dessous portent sur les modifications permettant de résoudre les problèmes courants liés au SPF et de réduire le risque d'échecs futurs.

Nettoyer l'enregistrement SPF

Commencez par regrouper les différents enregistrements SPF en un single si plusieurs enregistrements SPF existent. Supprimez ensuite les mécanismes obsolètes qui ne correspondent plus à des expéditeurs actifs, car les entrées superflues ou périmées peuvent entraîner des problèmes d'évaluation inutiles.

N'autorisez que les expéditeurs légitimes

N'ajoutez que les services d'envoi, les adresses IP et les plateformes légitimes qui envoient activement des messages au nom du domaine. Cela inclut les plateformes de messagerie dans le cloud telles que Google Workspace, l'infrastructure de messagerie interne et les fournisseurs SaaS agréés. Évitez d'accorder des autorisations trop larges ou de permettre l'accès à des services inconnus dans le seul but de mettre fin aux défaillances.

Valider les modifications après les mises à jour

Après toute modification, veuillez vérifier attentivement l'enregistrement. Vérifiez la syntaxe du fichier SPF, testez le nombre de requêtes et vérifiez les résultats une fois la propagation DNS effectuée. L'outil de vérification des enregistrements SPF de Mimecast est tout à fait adapté dans ce cas pour vous assurer que l'enregistrement mis à jour fonctionne comme prévu.

Sources d'envoi de documents au sein des différentes équipes

Cela permet également de répertorier les sources d'envoi au sein des différentes unités opérationnelles. Cela revêt une importance particulière lors de l'intégration de nouveaux fournisseurs, des changements de plateforme ou des mises à jour de l'infrastructure, situations dans lesquelles les dysfonctionnements du SPF commencent souvent par l'ajout, par une équipe, d'un expéditeur qui n'a jamais été intégré à l'enregistrement SPF central.

Un historique SPF plus propre ne constitue qu'une partie de la solution. La stabilité à long terme repose sur le maintien de l'exactitude des autorisations des expéditeurs, la validation minutieuse des modifications et la garantie que les mises à jour effectuées par les différentes équipes n'entraînent pas, à leur insu, une violation ultérieure de la politique.

Bonnes pratiques pour prévenir et éviter de futures défaillances du SPF

Il est plus facile de maintenir un historique SPF irréprochable qu'un historique réactif. Les meilleurs résultats à long terme découlent de mesures de contrôle opérationnelles qui permettent de réduire les erreurs récurrentes avant qu'elles n'atteignent le flux de courrier de production.

Voici quelques-unes des meilleures pratiques les plus utiles :

• Testez les modifications apportées à la politique avant leur déploiement afin d'éviter toute erreur de syntaxe, tout problème d'inclusion ou toute faille d'autorisation inattendue.
• Utilisez DMARC et DKIM en complément de SPF afin qu'une validation DKIM puisse contribuer à garantir une authentification cohérente, même lorsque SPF échoue dans des cas particuliers tels que le transfert de messages.
• Publiez le SPF sous forme d'enregistrement TXT, et non sous la forme obsolète de RR SPF, afin d'éviter tout problème de compatibilité et toute confusion liée à l'existence de politiques parallèles.
• Vérifiez les paramètres de redirection du courrier, car la redirection est souvent à l'origine d'échecs légitimes de la vérification SPF.
• Activez les rapports DMARC afin de pouvoir détecter plus tôt les expéditeurs non autorisés, les problèmes d'alignement et les écarts d'authentification récurrents.
• Vérifiez et testez régulièrement les enregistrements DNS afin de garantir que le répertoire des expéditeurs, le nombre de requêtes et les mécanismes SPF restent en adéquation avec l'infrastructure actuelle.

Ces pratiques permettent de réduire les problèmes récurrents liés au SPF avant qu'ils n'affectent le flux de courrier en production. Plus leur application est systématique, plus il devient facile de maintenir une politique SPF stable et de détecter les problèmes plus tôt.

Mettez en place une politique SPF plus rigoureuse avant que les défaillances ne se transforment en risques

L'échec du SPF n'est pas seulement un problème de délivrabilité. Il s'agit également d'un signal de sécurité pouvant indiquer une autorisation insuffisante de l'expéditeur, des enregistrements DNS obsolètes, des effets indésirables liés au transfert ou des lacunes plus générales dans la gouvernance de l'authentification.

La solution la plus efficace repose généralement sur un diagnostic précis, un historique SPF irréprochable et une utilisation coordonnée des protocoles SPF, DKIM et DMARC, plutôt que sur le traitement isolé de chaque mesure de contrôle. Pour les organisations qui ont besoin d'une stratégie d'authentification des e-mails et de lutte contre l'usurpation d'identité plus résiliente, Mimecast peut vous aider à améliorer la visibilité sur les problèmes liés au SPF et à mettre en place une gestion plus rigoureuse des politiques au fil du temps.