SPF Softfail et SPF fail : Quelle est la différence ?
par
Temps de lecture : 5 min
Avec SPF (Sender Policy Framework), vous avez la possibilité de configurer votre système pour qu'il réponde aux échecs d'authentification de l'une des deux manières suivantes : Hardfail ou Échec progressifDans ce blog, nous allons discuter des différences entre SPF hardfail et softfail, de la syntaxe pour configurer les deux, et de leurs cas d'utilisation. Alors, plongeons dans le vif du sujet !
Points clés à retenir
- Le SPF hardfail indique que l'expéditeur d'un courriel n'est pas autorisé, ce qui entraîne souvent le rejet du courriel.
- Le SPF softfail suggère que le courriel peut toujours provenir d'un expéditeur non autorisé, mais ne le rejette pas d'emblée, ce qui permet un examen plus approfondi.
- La mise en œuvre de politiques SPF strictes est essentielle pour éviter l'usurpation d'identité par courriel non autorisé et protéger la réputation de la marque.
- La combinaison de SPF et de DMARC ajoute une couche de sécurité essentielle, permettant de mieux gérer les échecs d'authentification du courrier électronique.
- Le contrôle régulier des résultats de l'authentification SPF peut contribuer à maintenir une posture optimale de sécurité du courrier électronique et à prévenir les vulnérabilités potentielles.
La différence entre le SPF Softfail et Hardfail
Le tableau ci-dessous explique la différence fondamentale entre l'échec dur et l'échec mou du SPF .
| Syntaxe SPF | Type d'échec | Statut | Action correspondante entreprise par le destinataire |
|---|---|---|---|
| v=spf1 include:domain1.com -all | Échec cuisant | Expéditeur non autorisé | Le courrier électronique peut être rejeté |
| v=spf1 include:domain1.com ~all | Défaillance logicielle | L'expéditeur peut être non autorisé | L'e-mail est délivré mais marqué comme suspect ou potentiellement frauduleux. |
SPF Hardfail 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é.
- Toutefois, une approche beaucoup plus souple consiste à configurer SPF Softfail, qui indique un indice "probable" d'utilisation non autorisée d'un domaine.
Simplifiez SPF avec PowerDMARC !
Traitement de l'échec du destinataire pour Hardfail Vs Softfail
Dans la section 8.4le RFC définit les scénarios de traitement des résultats suivants pour les résultats SPF hardfail et SPF softfail :
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.
SPF Softfail Vs Hardfail : Que recommandons-nous ?
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 ? L'action entreprise par la politique de traitement des échecsSPF annule les résultats des authentifications DMARC et DKIM. En fait, même si l'authentification DKIM et, par la suite, l'authentification DMARC sont réussies, le courrier électronique risque de ne pas être distribué.
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 la politique SPF d'un expéditeur de courrier électronique comprend un mécanisme "-all", indiquant une politique stricte de rejet des courriers électroniques qui échouent aux vérifications SPF , cela pourrait entraîner le rejet du message avant toute politique ou traitement DMARC. Ce rejet précoce peut se produire indépendamment du fait que le courriel puisse finalement passer l'authentification DMARC.
Par conséquent, dans ces circonstances, le mécanisme SPF Softfail triomphe du mécanisme Hardfail. Il s'agit d'une approche très peu risquée qui laisse une place à l'examen en signalant simplement les courriels autorisés au lieu de les rejeter.
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
La mise en œuvre optimale de SPF est essentielle pour protéger les communications par courrier électronique contre les attaques non autorisées par usurpation d'identité et par hameçonnage. En suivant les meilleures pratiques, les organisations peuvent améliorer leur position en matière de sécurité du courrier électronique et protéger la réputation de leur marque. Voici quelques stratégies et lignes directrices pour mettre en œuvre SPF en toute sécurité :
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 Sender Policy Framework doit être entretenu et optimisé pour éviter tout dysfonctionnement. SPF a tendance à s'interrompre lorsque les expéditeurs autorisés dépassent la limite de 10 consultations DNS du côté du destinataire. Pour maintenir une limite de consultation optimale, notre service solution SPF hébergée hébergée est la meilleure solution ! Nous aidons les propriétaires de domaines à optimiser le SPF en un seul clic, à rester en dessous des limites de consultation et d'annulation et à maintenir un 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.
La plateforme avancée d'authentification de domaine et de reporting PowerDMARC fournit des solutions SPF et DMARC complètes pour les entreprises de toutes tailles. Inscrivez-vous aujourd'hui pour un essai gratuit !
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)
- Explication de la nouvelle balise lps= dans BIMI - 11 novembre 2025
- Un guide étape par étape pour configurer SPF, DKIM et DMARC pour Moosend - 7 novembre 2025
- Règles d'envoi d'e-mails en masse pour Google, Yahoo, Microsoft et Apple iCloud Mail - 6 novembre 2025
