SPF Softfail et SPF fail : Quelle est la différence ?

Découvrez la différence entre SPF et Hardfail, les meilleures pratiques et comment sécuriser vos e-mails professionnels avec PowerDMARC. Guide complet pour les responsables informatiques et les administrateurs de messagerie.

Avec SPF (Sender Policy Framework), vous avez la possibilité de configurer votre système pour qu'il réponde aux échecs d'authentification de deux manières : Hardfail ou Softfail. Dans cet article, nos experts chez PowerDMARC vous expliquent les différences entre SPF et softfail, comment les configurer et vous présentent des cas d'utilisation concrets pour les équipes informatiques et de sécurité. Alors, plongeons-nous dans le vif du sujet !

Qu'est-ce qu'un SPF ?

Avant d'aborder les différences entre les échecs durs et les échecs mous, il est essentiel de comprendre ce qui constitue un SPF et comment fonctionne SPF .

SPF Sender Policy Framework) est un protocole d'authentification des e-mails qui permet aux propriétaires de domaines de spécifier quelles adresses IP sont autorisées à envoyer des e-mails au nom de leur domaine. Lorsqu'un e-mail est reçu, le serveur destinataire vérifie l'adresse IP de l'expéditeur par rapport à SPF du domaine afin de déterminer si l'expéditeur est autorisé.

SPF est effectuée par rapport au domaine du chemin de retour, qui représente l'identité donnée en cours d'authentification. Il est essentiel que SPF soit publié correctement afin de garantir SPF adéquate et d'éviter les problèmes de délivrabilité des e-mails.

Résultats de SPF

• Pass : l'adresse IP de l'expéditeur est autorisée dans SPF
• Échec (échec total) : l'adresse IP de l'expéditeur n'est explicitement pas autorisée (-all).
• Échec soft : l'adresse IP de l'expéditeur n'est probablement pas autorisée (~tous)
• Neutre : aucune déclaration de politique concernant l'expéditeur (?all)
• Aucun : aucun SPF n'existe pour le domaine.
• TempError : Échec temporaire de la recherche DNS
• PermError : erreur permanente dans la syntaxeSPF

Chaque SPF est une déclaration explicite concernant le statut d'autorisation de l'expéditeur. Un « échec » est une déclaration explicite forte indiquant que l'expéditeur n'est pas autorisé, tandis qu'un « échec léger » est une déclaration faible indiquant un manque d'autorisation probable mais non définitif.

SPF se produit lorsque le contrôle d'authentification renvoie un résultat « Échec » ou « Échec léger », indiquant que le serveur d'envoi n'est peut-être pas autorisé à envoyer des e-mails pour ce domaine.

Échec SPF vs échec souple : explication des principales différences

Le tableau ci-dessous explique la différence fondamentale entre l'échec dur et l'échec mou du SPF .

Remarque : Le mécanisme hardfail (« -all ») est conçu pour offrir une protection maximale contre le phishing et les e-mails frauduleux en rejetant les messages provenant d'expéditeurs non autorisés. Cependant, une configuration incorrecte peut entraîner l'impossibilité de livrer les e-mails et un taux de rebond de 100 % pour les sources non autorisées.

Dans la syntaxe SPF , seules les adresses IP spécifiées dans SPF sont autorisées à envoyer des e-mails au nom du domaine. Toutes les autres sources sont considérées comme des expéditeurs non autorisés et peuvent être bloquées ou marquées comme suspectes, selon le type d'échec.

SPF Vs Softfail : tel que défini dans la RFC 

Selon le RFC 7208:

• Un résultat "Fail" pour SPF indique directement que l'expéditeur du courriel n'est pas autorisé par le domaine d'envoi. "Fail" est synonyme de Hardfail (-all), qui indique clairement l'utilisation d'un domaine non autorisé. 
• Cependant, une approche beaucoup plus souple consiste à configurer SPF Softfail, qui indique une utilisation « probable » non autorisée du domaine.

Simplifiez SPF avec PowerDMARC !

Traitement de l'échec du destinataire pour Hardfail Vs Softfail 

Dans la section 8.4, la RFC définit les scénarios suivants pour le traitement des résultats SPF et SPF : 

1. SPF Hardfail / Fail 

Pour le résultat "Fail" ou "hardfail", le serveur du destinataire peut choisir de rejeter l'e-mail non autorisé. S'il s'agit d'une transaction SMTP, un code d'erreur 550 5.7.1 doit être renvoyé avec une description d'erreur appropriée. 

Si le serveur du destinataire ne rejette pas le courrier électronique au cours de la transaction SMTP, le RFC recommande aux destinataires d'enregistrer les résultats SPF dans l'en-tête SPF ou Authentication-Results. 

2. SPF Softfail

Dans le cadre d'une politique plus souple, Softfail indique que le domaine de gestion administrative soupçonne que le courriel n'est pas autorisé, mais ne souhaite pas le rejeter d'emblée. Dans ce cas, le message est délivré, mais avec un avertissement demandant un examen plus approfondi.  

Quel mode SPF devez-vous utiliser ?

La plupart des domaines, y compris ceux des grandes organisations et des entreprises technologiques, utilisent une combinaison de SPF en fonction de leurs besoins spécifiques et de leurs pratiques en matière de messagerie électronique. Le choix entre SPF fail et soft fail dépend de l'infrastructure de messagerie électronique de votre organisation, de ses exigences en matière de sécurité et de sa tolérance au risque. Voici un cadre décisionnel pour vous aider à faire votre choix :

Choisissez SPF Fail (-all) lorsque :

• Vous avez un contrôle total sur toutes les sources d'envoi d'e-mails.
• Votre infrastructure de messagerie électronique est mature et bien documentée.
• La sécurité est la priorité absolue par rapport à la délivrabilité.
• Vous utilisez rarement des services de messagerie tiers.
• Vous disposez d'un système complet de surveillance DMARC.

Choisissez SPF Fail (~all) Quand :

• Vous implémentez SPF la première fois
• Vous utilisez plusieurs services de messagerie tiers.
• La délivrabilité des e-mails est essentielle pour les opérations commerciales.
• Vous avez des configurations complexes de transfert ou de relais d'e-mails.
• Vous identifiez toujours toutes les sources d'e-mails légitimes.

Cas d'utilisation courants pour les échecs SPF Fail et Soft Fail

Cas d'utilisation SPF Fail :

• Institutions financières : Banques et coopératives de crédit exigeant une authentification stricte des e-mails
• Organismes gouvernementaux : Organisations soumises à des exigences élevées en matière de sécurité
• Domaines de protection de marque : Domaines utilisés uniquement pour la protection des marques
• Domaines d'e-mails transactionnels : Domaines dédiés aux e-mails automatisés

Cas d'utilisation SPF Fail :

• Domaines marketing : Domaines utilisant plusieurs plateformes de marketing par e-mail
• Entreprises SaaS : Organisations disposant d'infrastructures de messagerie complexes
• Établissements d'enseignement : Universités disposant de plusieurs départements et systèmes de messagerie électronique
• Environnements de test : Domaines en phase SPF

Scénario réel : si vous êtes responsable informatique et que vous supervisez la sécurité des e-mails pour une entreprise SaaS de taille moyenne utilisant Google Workspace, Salesforce et Mailchimp, vous pouvez commencer par une défaillance logicielle afin de vous assurer que tous les e-mails légitimes sont bien livrés pendant que vous surveillez et affinez votre SPF .

Quand faut-il utiliser SPF Fail ou Soft Fail ?

Dans le cas d'un relais de courrier électronique SMTP, vous pouvez considérer que l'échec partiel de SPF est un pari plus sûr que l'échec total. Voyons comment : 

Le relais SMTP est le transfert automatique de messages d'un serveur à un autre. Cela signifie que le courrier électronique est transmis à un serveur dont l'adresse IP ne figure pas dans l'enregistrement SPF de votre domaine. Il s'agit donc d'un expéditeur non autorisé pour votre courrier électronique, bien qu'en pratique, il soit légitime. 

Avez-vous un contrôle sur cette activité ? La réponse est non, car l'e-mail est relayé automatiquement du côté de votre destinataire. Dans ces circonstances, SPF échouera pour les courriels relayés. 

C'est ici qu'une politique de SPF hardfail peut vous causer des ennuis ! Comme nous le savons déjà, les mécanismes d'échec peuvent conduire au rejet des messages qui ont échoué. Par conséquent, ces emails relayés peuvent ne pas être délivrés si votre domaine est configuré avec une politique de hardfail. 

Le pire dans tout ça ? La décision prise par la politique en cas deSPF remplacera les mesures prises par les politiques DMARC et DKIM. les résultats d'authentification DMARC et DKIM . En substance, même si DKIM et DMARC sont validés, l'e-mail peut toujours ne pas être délivré.   

Comme spécifié dans RFC 7489 Section-10.1 si les vérifications SPF sont effectuées avant les opérations DMARC, la présence d'un préfixe "-" dans le mécanisme SPF de l'expéditeur, comme "-all", pourrait entraîner le rejet immédiat des courriels. Ce rejet intervient tôt dans le processus de traitement des courriels, avant même que le traitement DMARC n'ait lieu.

Par conséquent, si SPF d'un expéditeur d'e-mails inclut un mécanisme « -all », indiquant une politique stricte de rejet des e-mails qui échouent SPF , cela peut entraîner le rejet du message avant même que les politiques DMARC ou le traitement ne soient appliqués. Ce rejet précoce peut se produire, que l'e-mail passe ou non l'authentification DMARC.

Par conséquent, dans ces circonstances, le mécanisme SPF fail l'emporte sur le mécanisme Hard fail. Il s'agit d'une approche à faible risque qui laisse une marge de manœuvre pour la vérification en signalant simplement les e-mails autorisés au lieu de les rejeter. 

Vulnérabilités liées SPF et au relais

Il est essentiel de comprendre les vulnérabilités potentielles de SPF pour garantir une sécurité optimale des e-mails :

Scénarios courants SPF :

• Transfert d'e-mails : les e-mails légitimes transférés via des services tiers peuvent échouer SPF
• Serveurs de listes de diffusion : les messages envoyés via des listes de diffusion modifient souvent l'adresse IP de l'expéditeur.
• Services de messagerie électronique dans le cloud : les plages d'adresses IP dynamiques dans les services cloud peuvent entraîner SPF .
• Clients de messagerie mobile : e-mails envoyés depuis des appareils mobiles via différents réseaux

Meilleures pratiques en matière d'atténuation :

• Mettre en œuvre DKIM parallèlement à SPF une authentification supplémentaire
• Utilisez DMARC pour gérer SPF avec élégance
• Vérifier et mettre à jour régulièrement SPF
• Surveiller les rapports d'authentification des e-mails afin de détecter toute anomalie.

Comment fonctionnent les enregistrements SPF ?

Pour implémenter SPF pour vos emails, vous devez créer et publier un enregistrement SPF sur le DNS de votre domaine. Un exemple typique d'enregistrement SPF est le suivant :

v=spf1 include:_spf.google.com ~all

Dans cet enregistrement SPF , vous autorisez tous les courriers électroniques provenant des adresses IP figurant dans l'enregistrement SPF de Google. Le mécanisme d'échec est défini à la toute fin de l'enregistrement (~all), c'est-à-dire Softfail. 

Ainsi, un enregistrement SPF définit la version du protocole utilisé, les sources d'envoi que vous autorisez et le mécanisme d'échec. Lorsque vous publiez cet enregistrement sur votre DNS, vous vous assurez que seuls les expéditeurs autorisés peuvent envoyer des courriels au nom de votre domaine. Si une source non autorisée tente de se faire passer pour vous, SPF échoue avec le type de mécanisme d'échec défini dans votre enregistrement. 

Stratégies de mise en œuvre sécurisée du SPF

SPF optimale SPF est essentielle pour protéger les communications par e-mail contre l'usurpation d'identité usurpation d'identité et hameçonnage . En suivant les meilleures pratiques, les organisations peuvent renforcer leur sécurité de messagerie et protéger la réputation de leur marque. Voici quelques stratégies et directives pour mettre en œuvre SPF :

1. Utiliser un outil de génération d'enregistrements SPF

Le processus de mise en œuvre du SPF commence par la création d'un enregistrement. Vous pouvez créer votre enregistrement manuellement en ayant une bonne compréhension des balises SPF . Cette méthode est cependant sujette à des erreurs humaines. Idéalement, vous pouvez utiliser notre générateurSPF automatisé. Celui-ci vous aide à créer un enregistrement SPF précis et sans erreur, adapté aux besoins de votre organisation.

2. Utiliser des mécanismes SPF appropriés

Utilisez les mécanismes SPF tels que "include", "a" et "IP4" pour spécifier les sources d'envoi autorisées. Choisissez judicieusement les mécanismes en fonction de votre infrastructure de messagerie et veillez à ce qu'ils reflètent fidèlement vos pratiques en matière d'envoi de courrier électronique.

3. Maintenir et optimiser votre enregistrement SPF

Votre enregistrement SPF (Sender Policy Framework) doit être maintenu et optimisé pour éviter tout dysfonctionnement. SPF à ne plus fonctionner lorsque vos expéditeurs autorisés dépassent la limite de 10 recherches DNS côté destinataire. Pour maintenir une limite de recherche optimale, notre solution SPF hébergée est la meilleure solution ! Nous aidons les propriétaires de domaines à optimiser SPF un seul clic, afin de rester en dessous des limites de recherche et d'annulation et de maintenir SPF sans erreur. 

4. Combiner SPF et DMARC

Déploiement de DMARC (Domain-based Message Authentication, Reporting, and Conformance) en plus de SPF fournit une couche de sécurité supplémentaire (mais essentielle). DMARC permet aux propriétaires de domaines de spécifier des politiques de traitement du courrier électronique, y compris les mesures à prendre pour les courriers électroniques qui échouent au test SPF.

DMARC a prouvé qu'il permettait de réduire la fraude, la compromission et les attaques d'usurpation d'identité par courrier électronique. 

5. Mise en œuvre de politiques strictes de gestion des échecs SPF

Configurez votre enregistrement pour qu'il traite les échecs d'authentification échecs d'authentificationSPF avec des politiques strictes, telles que le rejet ou le marquage des courriels provenant de domaines avec des échecs. Pour ce faire, vous pouvez mettre en place des règles SPF hardfail ou SPF softfail au lieu d'une politique neutre.

6. Surveiller les résultats de l'authentification SPF

Mise en œuvre Rapports DMARC pour surveiller les résultats de l'authentification SPF , tels que les réussites et les échecs, ainsi que les erreurs d'alignement. A analyseur DMARC peut vous aider à analyser les données d'authentification SPF de manière organisée et lisible.

En conclusion

Il n'y a pas de réponse directe à la question "Qu'est-ce qui est le mieux ? SPF hardfail ou softfail". Si la balise hardfail peut vous offrir une meilleure sécurité, le choix de la bonne solution pour contrôler vos sources d'envoi devient crucial. 

Authentification de domaine avancée de PowerDMARC d'authentification de domaine et de reporting de PowerDMARC fournit des fonctionnalités complètes solutionsSPF DMARC pour les entreprises de toutes tailles. 

Essayez la plateforme certifiée SOC2 à laquelle font confiance des milliers d'organisations à travers le monde. Commencez votre essai gratuit dès aujourd'hui !

Foire aux questions

1. Quelle est la raison de l'échec SPF ?

Une défaillance SPF fail se produit lorsqu'un e-mail est envoyé à partir d'une adresse IP qui n'est pas explicitement autorisée dans SPF du domaine, mais que le propriétaire du domaine a configuré un mécanisme « ~all » au lieu de « -all ». Cela indique que l'expéditeur n'est « probablement pas autorisé », mais permet à l'e-mail d'être livré avec un drapeau d'avertissement plutôt que d'être rejeté purement et simplement.

2. Qu'est-ce SPF échec SPF 550 5.7.0 ?

L'erreur « 550 5.7.0 SPF » se produit lorsqu'un serveur de messagerie rejette un message parce que l'adresse IP de l'expéditeur n'est pas autorisée dans SPF du domaine qui se termine par « -all ». Il s'agit d'un échec permanent qui empêche la livraison du courrier électronique et indique que le serveur de réception SPF strictes.

3. Quand obtiendriez-vous un échec SPF ?

Vous obtenez un SPF lorsque : 1) L'adresse IP d'envoi ne figure pas dans SPF du domaine, 2) SPF se termine par « -all » (politique d'échec strict), 3) L'e-mail est envoyé à partir d'un serveur ou d'un service non autorisé, 4) Il y a des erreurs de configuration dans SPF , ou 5) Le domaine a mis en place des politiques d'authentification des e-mails strictes.

4. Que signifie le symbole « hard fail » dans SPF?

Le symbole d'échec total dans SPF le signe moins « - » suivi de « all » (écrit « -all »). Ce mécanisme indique aux serveurs de messagerie destinataires de rejeter tous les e-mails qui ne correspondent pas aux adresses IP ou aux domaines autorisés répertoriés dans SPF . Il s'agit de la SPF la plus stricte, qui offre le plus haut niveau de sécurité en matière d'authentification des e-mails.

5. Dois-je utiliser SPF fail ou soft fail pour mon entreprise ?

Pour la plupart des entreprises, commencez par utiliser SPF fail (~all) pendant les phases de mise en œuvre et de test afin d'éviter de bloquer les e-mails légitimes. Une fois que vous avez identifié toutes les sources d'envoi autorisées et effectué des tests approfondis, envisagez de passer au mode hard fail (-all) pour une sécurité maximale. Les organisations disposant d'infrastructures de messagerie complexes ou de services tiers doivent évaluer avec soin le risque de blocage des e-mails légitimes avant de mettre en œuvre le mode hard fail.

• À propos de
• Derniers messages

Yunes Tarada

Expert en sécurité des domaines et des courriels chez PowerDMARC

Yunes est chef d'équipe des opérations chez PowerDMARC et possède des connaissances approfondies en matière d'authentification et de sécurité des courriels. Yunes est certifié Microsoft Azure Administrator Associate et possède des certifications CompTIA A+ et bien d'autres encore.

Derniers messages de Yunes Tarada (voir tous)

• Certificat de marque vérifiée ou certificat de marque commune : choisir la bonne option - 10 mars 2026
• Contournement du niveau de confiance anti-spam (SCL) -1 : ce que cela signifie et comment y remédier - 4 mars 2026
• « Ne passe pas la vérification DMARC et a une politique DMARC de rejet » : ce que cela signifie et comment y remédier - 26 février 2026