Meilleures pratiques SPF : Éviter l'aplatissement des enregistrements SPF
Mise à jour - 4 février 2025
Nous avons mis à jour notre vue d'ensemble des domaines afin d'afficher les comptes de consultation SPF, éliminant ainsi la nécessité de récupérer l'information à partir d'autres outils. Cette amélioration permet de gagner du temps, d'améliorer la visibilité du nombre de consultations SPF et de promouvoir les meilleures pratiques SPF, ce qui est essentiel pour accélérer l'adoption de DMARC et l'efficacité opérationnelle.
Pourquoi l'aplatissement SPF est-il pertinent ?
SPF a une limite de 10 consultations DNS ; tout mécanisme (entrée) nécessitant une consultation après la limite de consultation ne sera pas évalué et l'authentification échouera. Dans certains cas, les gens se tournent vers les outils d'aplatissement SPF pour contourner la limite de 10 consultations DNS.
Lorsque vous ajoutez un nouveau mécanisme dans votre enregistrement, vous devez effectuer une nouvelle recherche DNS. Plus il y a de services et de tiers qui envoient des messages en votre nom, plus votre enregistrement peut devenir compliqué et volumineux. L'aplatissement des enregistrements SPF peut être une solution facile, mais ce n'est pas la voie la plus sûre.
Comment fonctionne l'aplatissement SPF ?
Dans l'aplatissement SPF, les noms d'hôte sont convertis en adresses IP, qui ne sont pas comptabilisées dans le décompte des recherches DNS. Ensuite, vous créez vos enregistrements SPF en utilisant les adresses IP au lieu des noms d'hôte.
dmarcian a développé l'aplatissement SPF comme une expérience pour contourner la limite de requêtes DNS. Dans le RFC 7208 de l'IETF, la norme d'authentification e-mail SPF, les requêtes sont limitées pour « éviter une charge déraisonnable sur le DNS ». Vous pouvez consulter les détails de la norme ici.
L'aplatissement SPF devrait être découragé d'emblée ; la plupart des gens initient des enregistrements SPF qui autorisent une grande partie d'internet qui n'effectue pas réellement d'authentification dans le contexte de SPF. Le résultat est une surface de risque accrue où un acteur malveillant peut accéder aux parties d'internet qui sont mal autorisées et envoyer des e-mails depuis ce domaine. Au lieu de cela, il est préférable de collecter des données DMARC comme point de départ pour comprendre le contexte d'authentification global et décider quels mécanismes doivent être représentés dans les enregistrements SPF.
Tim Draegen, CTO de dmarcian et co-auteur de la spécification DMARC.
Comment résoudre le problème des « Trop de recherches DNS »
- Supprimez (et n'ajoutez pas) les entrées d'enregistrement SPF non essentielles. Voici quelques exemples :
- Supprimez les enregistrements pour les fournisseurs qui ne peuvent pas être configurés pour l'alignement SPF, où le domaine SPF correspond au MAIL FROM, également appelé return-path et utilise votre domaine. Si vous avez un compte dmarcian, supprimez les enregistrements SPF pour les sources apparaissant dans votre Detail Viewer qui sont « incapables de SPF » et affichent un taux de réussite SPF de 0 %. Si vous n'avez pas de compte dmarcian, vous pouvez consulter notre ressource gratuite dmarc.io pour vérifier les capacités SPF du fournisseur.
- Évitez les entrées « a » et « mx » : Ces mécanismes sont souvent inutiles et ne devraient probablement pas être inclus dans votre enregistrement SPF.
- Supprimez les enregistrements pour les fournisseurs qui ne peuvent pas être configurés pour l'alignement SPF.
- Supprimez les mécanismes SPF en double.
- Évitez les inclusions de domaines de premier niveau. De nombreux fournisseurs de services de messagerie utilisent des sous-domaines pour leur MAIL FROM, qui est évalué pour l'authentification SPF.
- Le fait d'avoir un domaine de premier niveau inutile autorise de fait des milliers d'adresses IP à envoyer au nom de ce domaine.
- Lorsque l'e-mail est incapable de passer DMARC avec SPF, configurez DKIM.
- Auditez régulièrement vos enregistrements SPF dans le cadre de la maintenance continue de votre domaine et supprimez les entrées SPF inutilisées (par exemple, un expéditeur qui n'est plus utilisé ou qui a mis en place une pratique de gestion SPF par sous-domaine depuis son intégration).
- Déplacez le trafic des fournisseurs vers des sous-domaines pour l'authentification SPF (voir plus de détails ci-dessous). La segmentation par sous-domaine crée un nouveau domaine dédié à un flux de courrier particulier avec ses propres 10 requêtes DNS.
Bonnes pratiques SPF
À mesure que les organisations se développent, les sources d'e-mails peuvent s'accumuler de manière sporadique et organique. De ce fait, des mécanismes sont souvent ajoutés aux enregistrements SPF tandis que les mécanismes inutilisés ne sont pas examinés pour voir s'ils peuvent être supprimés.
Du point de vue de la sécurité, de l'exploitation et de la délivrabilité, dmarcian préconise la stratégie de segmentation pour la gestion SPF. Nous recommandons de séparer les différents flux d'e-mails (types de trafic) lorsque cela est possible. L'idée est de séparer les flux par type, tels que le marketing de masse, les transactions, la facturation, les fournisseurs tiers spécifiques, les entités opérationnelles, etc.
Pour ce faire, il est également recommandé de séparer le trafic e-mail en sous-domaines dédiés à ces flux. Cela augmente la visibilité de chaque flux, isolant l'utilisation d'un système ou d'un fournisseur particulier. Lorsque l'authentification SPF est nécessaire, cela apporte également une sécurité accrue et une simplicité opérationnelle en allégeant le fardeau d'une approche à domaine unique et en évitant le gonflement des enregistrements SPF. Il est important de noter que chaque segment doit développer sa propre réputation, ce qui nécessite un volume de trafic constant. Une variation ou une interruption d'utilisation sur un sous-domaine peut avoir un impact sur la réputation et la délivrabilité.
Asher Morin, Directeur du déploiement chez dmarcian
En plus de réduire les requêtes DNS grâce à une stratégie de segmentation par sous-domaine, voici d'autres bonnes pratiques SPF :
- Évitez d'utiliser ptr. Le mécanisme ptr est obsolète et peut imposer une charge substantielle sur le DNS lors des requêtes, et certains récepteurs ignoreront entièrement le mécanisme (ou l'enregistrement SPF).
- Protégez tous les domaines non émetteurs avec un enregistrement SPF restrictif de type « deny all » : « v=spf1 -all ». Les acteurs malveillants rechercheront activement les domaines inutilisés à exploiter.
- Évitez « +all » ou « all », car cela autorise toute adresse IP non explicitement refusée dans votre enregistrement SPF à passer. De plus, n'utilisez pas « ?all », car il est neutre et ne fournit aucune indication de préférence d'application. Un verdict neutre peut augmenter le score de spam d'un e-mail, le poussant vers le seuil de verdict de spam d'un récepteur – cela peut faire la différence entre un e-mail finissant dans un dossier de courrier indésirable ou non.
- Utilisez « ~all » (softfail) ou « -all » (fail). Bien que la plupart des récepteurs traitent ces directives de manière similaire, certains sont plus susceptibles de rejeter les e-mails lorsque « -all » est utilisé, quelle que soit votre politique DMARC. Dans cette optique, nous recommandons de refléter la politique DMARC au fur et à mesure du déploiement de la technologie : utilisez « ~all » pour les politiques DMARC « none » et « quarantine », et déployez « -all » une fois que vous êtes passé à une politique de « reject ».
- Mettez en place des processus au sein de votre organisation pour le suivi et la gestion continue des SPF. Cet examen périodique devrait prendre en compte l'intégration et la désintégration des fournisseurs tiers, le cas échéant.
Si vous avez des questions sur la gestion de vos enregistrements SPF, contactez-nous. Vous pouvez également lire d'autres articles et guides SPF ici et consulter notre vidéo SPF.
Avec une équipe d'experts en sécurité du courrier électronique et pour mission de rendre le courrier électronique et l'internet plus fiables grâce à la sécurité des domaines, dmarcian est là pour aider à évaluer le catalogue de domaines d'une organisation, et à implémenter et gérer DMARC sur le long terme.
Vous souhaitez poursuivre la conversation ? Rendez-vous sur le Forum dmarcian.
