La différence entre SPF -all et ~all
par
Temps de lecture : 4 min
Le mécanisme SPF all est un mécanisme SPF qui existe dans le DNS de votre domaine en tant qu'enregistrement TXT ; il est situé à l'extrémité droite d'un enregistrement SPF, précédé par "-" ou "~". Examinons la différence entre les mécanismes SPF -all et ~all afin de déterminer quand vous devez les configurer.
Points clés à retenir
- Les mécanismes SPF -all et ~all indiquent tous deux "NOT PASS" pour l'authentification SPF mais peuvent être traités différemment par certains services de messagerie.
- Historiquement, le SPF Softfail (~all) permettait de délivrer les courriels même s'ils échouaient à l'authentification, tandis que le Hardfail (-all) rejetait les courriels qui ne passaient pas.
- Les services de courrier électronique modernes traitent souvent -all et ~all sans échec de livraison significatif, bien que des rejets occasionnels puissent se produire avec -all.
- Pour minimiser les risques, il est conseillé d'utiliser dans un premier temps le mécanisme Softfail (~all) tout en s'assurant que DMARC est configuré et en contrôlant les résultats.
- La mise en œuvre de DMARC et de configurations SPF appropriées renforce la sécurité du courrier électronique en définissant la manière dont les courriers électroniques non authentifiés doivent être traités.
SPF -all vs ~all
Les mécanismes SPF -all et SPF ~all signifient tous deux un "NOT PASS" pour l'authentification SPF. Récemment, pour la majorité des fournisseurs de services de courrier électronique, il n'y a pas de différence entre les mécanismes -all et ~all, et le même résultat est renvoyé. Toutefois, ce n'était pas le cas il y a quelques années.
Comment le mécanisme SPF all (Softfail vs Fail) fonctionnait-il avant DMARC ?
DMARC a été créé bien longtemps après que SPF ait été lancé sur le marché en tant que protocole standard d'authentification des e-mails. À cette époque, le mécanisme de softfail de SPF fonctionnait de la manière suivante :
Supposons que votre enregistrement SPF soit :
v=spf1 include:spf.domain.com ~all (où ~all signifie SPF Softfail)
Le serveur de messagerie de votre destinataire aurait effectué une recherche DNS pour interroger le DNS de l'expéditeur sur son enregistrement SPF. Si le domaine Return-path de l'e-mail n'était pas répertorié dans l'enregistrement de l'expéditeur, le serveur de réception aurait renvoyé un résultat SPF "NOT PASS" mais aurait livré l'e-mail dans la boîte de réception du destinataire.
Supposons maintenant que votre enregistrement SPF soit :
v=spf1 include:spf.domain.com -all (où -all signifie SPF Fail)
Le serveur de messagerie de votre destinataire aurait effectué une recherche DNS pour interroger le DNS de l'expéditeur sur son enregistrement SPF. Si le domaine Return-path de l'e-mail n'était pas répertorié dans l'enregistrement de l'expéditeur, le serveur de réception aurait renvoyé un résultat SPF "NOT PASS", mais dans ce cas, l'e-mail aurait été a été rejeté et non délivré dans la boîte de réception du destinataire.
En savoir plus sur l'histoire de Sender Policy Framework.
Simplifiez SPF avec PowerDMARC !
Comment les fournisseurs de services de messagerie gèrent-ils désormais le mécanisme SPF -all vs ~all ?
Bien que vous soyez libre d'utiliser SPF -all ou ~all pour la plupart des fournisseurs de boîtes aux lettres à l'heure actuelle sans avoir à vous soucier des échecs de livraison pour les e-mails légitimes, il peut arriver qu'un serveur rejette votre courriel en cas d'utilisation de l'attribut -all..
Pour être plus sûr, vous pouvez éviter d'utiliser le mécanisme SPF hard fail -all lors de la création de votre enregistrement SPF. Voici comment procéder :
- Ouvrez le générateur d'enregistrements SPF de PowerDMARC générateur d'enregistrements SPF pour commencer à créer un enregistrement gratuitement
- Après avoir indiqué les adresses IP et les domaines des expéditeurs de vos courriels, passez à la dernière section destinée à indiquer aux serveurs de courriels la rigueur avec laquelle ils doivent vérifier vos courriels.
- Choisissez l'option "Soft-fail" avant de cliquer sur le bouton "Generate SPF Record".
Que recommandons-nous ? SPF -all ou SPF ~all
Les problèmes de délivrabilité des e-mails liés au mécanisme SPF -all peuvent se produire en de très rares occasions. Il ne s'agit pas d'un problème récurrent que vous rencontrerez souvent. Pour vous assurer que vous ne rencontrerez jamais ce problème, vous pouvez prendre les mesures suivantes :
- Configurer DMARC pour vos courriels et activez le reporting DMARC
- Réglez votre politique DMARC sur la surveillance et examinez attentivement les résultats de l'authentification SPF pour repérer toute incohérence dans la délivrabilité des courriels.
- Si tout est bon, vous pouvez utiliser le mécanisme -all dans votre enregistrement SPF. Nous recommandons d'utiliser l'attribut hard fail car il affirme que vous êtes confiant quant à l'authenticité de vos emails, ce qui peut améliorer la réputation de votre domaine.
Si vous n'êtes pas certain d'utiliser le SPF -all, vous pouvez suivre les étapes suivantes :
- Configurer un enregistrement SPF en utilisant le mécanisme ~all
- Configurez DMARC pour vos courriels et activez les rapports DMARC.
- Définissez votre politique DMARC pour rejeter
Dépannage d'autres erreurs SPF
Lorsque vous utilisez des outils en ligne, vous rencontrez souvent le message "Aucun enregistrement SPF trouvé"Il s'agit d'un état d'erreur courant résultant d'un résultat nul renvoyé lorsqu'un serveur recherche l'enregistrement SPF de votre domaine. Nous avons couvert un article en détail parlant de ce problème et aidant les utilisateurs à le résoudre. Cliquez sur le texte lié pour en savoir plus !
Si vous avez mis en place DMARC pour votre domaine en plus de SPF, les serveurs de messagerie vérifieront la politique DMARC de votre domaine pour déterminer comment vous souhaitez que les courriels dont l'authentification échoue soient traités. Cette politique DMARC déterminera si vos e-mails seront livrés, mis en quarantaine ou rejetés.
Le rejet DMARC permet de protéger votre domaine contre diverses attaques par usurpation d'identité telles que l'usurpation d'identité, le phishing et les ransomwares.
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)
