Échec « hard » et échec « soft » du SPF : quelle est la différence ?

Les résultats du SPF peuvent sembler simples jusqu'à ce qu'un choix de politique commence à avoir une incidence sur le filtrage, la résistance à l'usurpation d'identité et les résultats de distribution. Ce guide explique ce que signifient les termes « hard fail » et « soft fail » dans le cadre du SPF, en quoi ils diffèrent, dans quelles circonstances chacun d'entre eux est pertinent, et pourquoi le SPF est plus efficace lorsqu'il s'inscrit dans une stratégie plus large d'authentification des e-mails.

Qu'est-ce qu'un échec SPF ?

Le SPF vérifie si un serveur de messagerie est autorisé à envoyer des e-mails pour un domaine donné. Cette section explique comment se produit un échec du SPF et ce que signifient généralement les résultats d'authentification courants.

Comment se produit une défaillance du SPF ?

Le SPF ( Sender Policy Framework) fonctionne en comparant l'adresse IP de l'expéditeur à l'enregistrement SPF publié dans le DNS pour le domaine. Une erreur SPF survient lorsque le serveur destinataire ne parvient pas à vérifier que l'adresse IP de l'expéditeur est autorisée pour le domaine utilisé dans le champ « Mail From » de la norme RFC 5321, également appelé « return-path ».

Cette distinction est importante, car le SPF n'est pas toujours évalué par rapport à l'adresse « De » visible dans la boîte de réception. Un message peut paraître légitime aux yeux du destinataire tout en échouant à la validation SPF en raison du domaine du champ « return-path ».

Résultats courants de l'authentification SPF

Les résultats de l'authentification SPF peuvent varier. Le message suivant pourrait s'afficher :

• SPF validé : le serveur expéditeur est autorisé par l'enregistrement SPF du domaine ; l'authentification SPF est donc réussie.
• SPF absent : aucun enregistrement SPF n'est publié pour ce domaine ; le serveur destinataire ne dispose donc d'aucun élément à évaluer.
• neutre : Le domaine ne permet pas de déterminer clairement si l'expéditeur est autorisé ou non, le résultat n'est donc pas concluant.
• Échec temporaire SPF : l'expéditeur n'est probablement pas autorisé, mais le domaine ne demande pas aux destinataires de rejeter purement et simplement le message.
• Échec total SPF : l'expéditeur n'est pas autorisé selon l'enregistrement SPF, et le domaine applique une politique plus stricte à l'égard de ce message.
• Erreur SPF : il n'a pas été possible de vérifier entièrement le SPF en raison d'un problème temporaire, tel qu'un délai d'expiration DNS ou un échec de recherche.
• permerror : l'évaluation du SPF n'a pas pu être effectuée en raison d'un problème permanent dans l'enregistrement SPF, tel qu'une syntaxe incorrecte ou un nombre trop élevé de requêtes DNS.

Certains résultats indiquent un véritable problème d'autorisation, tandis que d'autres mettent en évidence l'absence de politique, une politique insuffisante, des problèmes de syntaxe SPF ou des problèmes liés au DNS.

C'est pourquoi il est utile de vérifier le résultat exact du test SPF avant de procéder au dépannage. Le résultat spécifique vous indique généralement s'il s'agit d'un expéditeur non autorisé, d'un enregistrement manquant, d'un échec SPF plus général ou d'un problème lié à un enregistrement ou à une requête.

Échec « hard » vs échec « soft » du SPF

Dans les deux cas, cela signifie que le SPF n'a pas pu confirmer que la source d'envoi était autorisée. La différence réside dans l'importance que le propriétaire du domaine accorde à la manière dont les systèmes destinataires doivent interpréter cette défaillance.

Différences de syntaxe

La différence technique réside dans l'enregistrement SPF lui-même :

• Un « soft fail » utilise « ~all »
• Échec cuisant avec l'option -all

Ce single caractère modifie le signal que le domaine transmet aux systèmes récepteurs.

Différences sémantiques

Une erreur « soft fail » signifie que le domaine indique que l'expéditeur n'est probablement pas autorisé. Cela témoigne d'une certaine préoccupation, mais ne constitue pas une prise de position politique suffisamment ferme pour être rejetée sur la seule base du SPF.

Une erreur « hard fail » signifie que le domaine indique que l'expéditeur n'est pas autorisé. Il s'agit là d'une position plus stricte, qui traduit une plus grande confiance dans le fait que les flux de courrier légitimes sont déjà pris en compte dans l'enregistrement SPF.

Situation actuelle et objectif de la politique

Le « soft fail » et le « hard fail » sont tous deux des résultats d'échec du SPF, mais les termes « spf softfail » et « spf hardfail » reflètent des intentions différentes en matière de politique. Le « soft fail » est souvent utilisé lorsqu'une organisation est encore en train de vérifier l'ensemble de ses sources d'envoi ou qu'elle souhaite éviter les rejets erronés tout en nettoyant son répertoire d'expéditeurs. 

Le « hard fail » est plus approprié lorsque le propriétaire du domaine a davantage confiance dans la couverture SPF et est prêt à adopter une position plus ferme face aux e-mails non autorisés.

Comment les systèmes de réception les traitent

Dans la pratique, les messages de « soft fail » sont souvent acceptés, mais filtrés, signalés ou acheminés avec davantage de prudence. Les messages présentant des erreurs graves sont plus susceptibles d'être rejetés, mis en quarantaine ou évalués plus sévèrement au sein de l'ensemble des solutions de sécurité des e-mails.

Ces différences sont importantes, car un mode de défaillance inapproprié peut entraîner soit des difficultés inutiles au niveau de la diffusion, soit une exposition inutile à l'usurpation d'identité.

Quel mode de défaillance SPF devriez-vous utiliser ?

Le mode de défaillance SPF approprié dépend du degré d'exhaustivité de votre inventaire d'expéditeurs et du niveau de risque de non-remise que votre organisation est prête à accepter. Les sections ci-dessous indiquent dans quels cas le « soft fail » constitue généralement le choix le plus sûr et dans quels cas le « hard fail » s'avère plus pratique.

Quand utiliser un « soft fail » ?

Si votre organisation n'est pas encore certaine que toutes les sources d'envoi légitimes soient incluses dans l'enregistrement SPF, la valeur « ~all » constitue généralement le point de départ le plus sûr. Cela réduit le risque de rejeter des e-mails légitimes pendant que vous procédez à l'inventaire des expéditeurs et au nettoyage des enregistrements SPF.

Cela s'avère particulièrement utile lors des transitions entre plateformes, lors de l'intégration d'outils SaaS tiers ou lorsque différentes entités opérationnelles gèrent des flux de messagerie distincts. Dans ces cas-là, une politique de « soft fail » laisse aux équipes la possibilité d'observer les résultats de l'authentification SPF sans passer immédiatement à une approche stricte de « hard fail ».

Quand utiliser « Hard Fail » ?

Le transfert vers le répertoire « -all » s'avère plus judicieux une fois que les sources d'envoi légitimes auront été entièrement documentées et validées. Cela inclut l'infrastructure de messagerie interne, les services de messagerie dans le cloud et les expéditeurs tiers.

Une fois que la couverture SPF est complète et stable, une politique de rejet strict peut offrir une meilleure résistance à l'usurpation d'identité tout en réduisant le risque de faux rejets. Pour la plupart des organisations, la solution la plus pratique consiste à commencer par un « soft fail » tant que la couverture SPF est encore en cours de vérification, puis à passer à un « hard fail » uniquement lorsque le niveau de confiance dans l'enregistrement est élevé.

Cas d'utilisation courants des « hard fail » et « soft fail » dans le cadre du SPF

Le cas d'utilisation approprié dépend souvent du degré d'exhaustivité et de stabilité de votre couverture SPF. Le « soft fail » s'avère généralement plus pratique lors des phases de nettoyage et de découverte, tandis que le « hard fail » est plus adapté lorsque les sources d'envoi sont strictement contrôlées.

Les cas où les « soft fails » sont fréquents

Les échecs mineurs sont fréquents pendant les périodes de transition. Les organisations utilisent souvent ~all pendant qu'elles sont encore en train d'identifier les expéditeurs tiers, de mettre à jour leurs anciens mécanismes SPF ou de regrouper leurs services de messagerie à la suite de changements de fournisseurs ou d'infrastructures.

Elle convient également aux domaines présentant des écosystèmes d'expéditeurs complexes. Si plusieurs plateformes SaaS, services ou systèmes régionaux envoient des e-mails au nom d'un même domaine, il peut s'avérer plus difficile de maintenir le fichier SPF parfaitement à jour en permanence. Dans ces environnements, le « soft fail » constitue un moyen moins perturbateur de surveiller et d'affiner la politique SPF.

Les cas où les échecs définitifs sont fréquents

Les échecs définitifs sont plus fréquents dans les environnements d'envoi strictement contrôlés. Si un domaine envoie des e-mails uniquement via Microsoft 365, uniquement via Google Workspace ou via une autre plateforme strictement réglementée dotée d'une infrastructure d'expédition bien documentée, la prise en charge est globalement plus facile et plus sûre.

Cela s'avère également pertinent pour les organisations soucieuses de la sécurité, dotées d'une gouvernance des expéditeurs bien établie et d'une faible tolérance au risque d'usurpation d'identité. Dans ces environnements, la politique SPF plus stricte permet aux systèmes destinataires de repérer plus facilement les e-mails non autorisés.

Stratégies visant à garantir la sécurité de la mise en œuvre du SPF

Le SPF fonctionne mieux lorsqu'il est considéré comme un mécanisme de contrôle géré, et non comme une tâche DNS ponctuelle. Les pratiques suivantes permettent de réduire les erreurs de configuration et de veiller à ce que la politique SPF reste en adéquation avec le flux réel de courriers électroniques.

Utilisez un outil de génération d'enregistrements SPF

Un outil de vérification ou de génération d'enregistrements SPF peut aider les équipes à créer des enregistrements plus clairs, à tester la syntaxe SPF et à détecter les problèmes avant la mise en production des modifications. Cela s'avère particulièrement utile lors du nettoyage du SPF, des migrations de plateforme ou de l'intégration des expéditeurs.

Utilisez des mécanismes SPF adaptés

Chaque mécanisme SPF doit correspondre à une source d'envoi réelle. Une utilisation excessive de la directive « include », le fait de laisser en place des entrées obsolètes ou l'autorisation de larges plages d'adresses IP peuvent affaiblir la politique et compliquer le dépannage.

Maintenir et optimiser l'enregistrement SPF

Les dossiers doivent rester concis. Supprimez les expéditeurs obsolètes, évitez les inclusions imbriquées inutiles et surveillez la limite de requêtes DNS. Si l'évaluation SPF nécessite un nombre trop important de requêtes DNS, elle peut renvoyer une erreur permanente (« permerror ») au lieu d'un résultat d'autorisation valide. 

Il est également important d'éviter les enregistrements SPF multiples, car la publication de plusieurs politiques SPF pour un même hôte peut entraîner des problèmes de validation au lieu d'un résultat correct.

Appliquez les politiques de gestion des défaillances avec prudence

Le choix entre un « soft fail » et un « hard fail » doit refléter la couverture réelle des expéditeurs. Une politique plus stricte n'est pas forcément meilleure si les données disponibles sont incomplètes. La politique SPF la plus efficace est celle qui correspond au flux réel de courriers électroniques.

Suivre les résultats de l'authentification SPF

L'analyse des résultats d'authentification SPF au fil du temps permet aux équipes de détecter les écarts, les expéditeurs manquants et les erreurs de configuration avant qu'ils ne se transforment en problèmes de délivrabilité plus généraux, en particulier lorsqu'elle s'appuie sur un outil de reporting DMARC. La vérification régulière des SPF permet également de repérer plus facilement les échecs répétés liés aux SPF avant qu'ils ne se transforment en problèmes plus graves d'autorisation des expéditeurs.

Associez SPF à DMARC

L'indice SPF à lui seul ne suffit pas. DMARC apporte une meilleure cohérence et assure le respect des règles, ce qui renforce l'intérêt du protocole SPF dans les environnements de production où la résistance à l'usurpation d'identité revêt une importance particulière. Ces bonnes pratiques aident les organisations à utiliser le SPF dans le cadre d'une stratégie d'authentification plus solide et plus complète.

Pourquoi un indice SPF peut ne pas suffire

Le protocole SPF est utile, mais il ne résout pas à lui seul tous les problèmes d'authentification des e-mails. Les principales limites énumérées ci-dessous expliquent pourquoi cette approche donne de meilleurs résultats lorsqu'elle s'inscrit dans le cadre d'une stratégie plus large.

Le transfert de messages peut toujours compromettre la validité du SPF

L'une des principales limites concerne le transfert. Un message transféré peut tout de même être légitime, mais la vérification SPF peut échouer car l'adresse IP du serveur de transfert n'est pas autorisée dans l'enregistrement SPF du domaine d'origine. Si l'enregistrement TXT DNS correspondant ne prend pas en compte ce chemin d'accès, le transfert peut tout de même compromettre la validité du SPF, même si la source initiale du message était légitime.

Le SPF ne vérifie pas l'adresse d'expéditeur visible

Le SPF vérifie l'adresse IP de l'expéditeur par rapport au domaine « envelope-from », et non pas toujours par rapport à l'adresse « De » visible par l'utilisateur. Cela signifie que le protocole SPF, à lui seul, ne permet pas de résoudre entièrement les problèmes liés à l'identité de l'expéditeur et à l'alignement.

Le SPF est plus efficace lorsqu'il est associé à DKIM et DMARC

C'est pourquoi le SPF doit être considéré comme un élément à part entière d'une stratégie plus large d'authentification et de conformité à la norme PCI DSS. DKIM ajoute une signature cryptographique, tandis que DMARC met en place des règles de conformité et assure l'application des politiques, ce qui contribue à réduire le risque de mauvaise configuration de DMARC. Ensemble, ces mesures offrent une protection plus efficace que celle que peut apporter le SPF à lui seul.

Choisir le mode de défaillance SPF approprié en toute confiance

La différence entre un « hard fail » et un « soft fail » du SPF tient à l'objectif de la politique, à la confiance accordée à l'expéditeur et à la tolérance au risque. Un « soft fail » indique probablement un e-mail non autorisé et s'avère souvent utile lors des opérations de nettoyage et de détection. Un échec « hard » indique sans aucun doute un e-mail non autorisé et s'applique davantage une fois que la mise en place du SPF est achevée et strictement contrôlée.

La meilleure approche consiste à renforcer la confiance dans la couverture SPF avant de passer à un rejet systématique, puis à étayer cette politique à l'aide de DKIM et de DMARC afin d'assurer une meilleure cohérence et une protection renforcée. Pour les organisations qui ont besoin d'une meilleure visibilité sur les protocoles SPF, DKIM et DMARC pour l'ensemble de leurs sources d'envoi, Mimecast peut vous aider à réduire les erreurs de configuration et à renforcer la protection dans l'ensemble de votre environnement de messagerie.