Meilleures pratiques SPF : Éviter l'aplatissement des enregistrements SPF
Pourquoi l'aplatissement du SPF est-il pertinent ?
SPF a une limite de 10 recherches DNS ; tout mécanisme (entrée) nécessitant une recherche après cette limite 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 recherches DNS. Lorsque vous ajoutez un nouveau mécanisme dans votre enregistrement, vous devez effectuer une nouvelle consultation du DNS. Plus il y a de services et de tiers qui envoient des messages en votre nom, plus votre enregistrement peut devenir compliqué et gonflé. L'aplatissement de l'enregistrement SPF peut être une réponse facile, mais ce n'est pas la voie la plus sûre.
Comment fonctionne l'aplatissement SPF ?
Dans SPF Flattening, les noms d'hôtes sont convertis en adresses IP, qui ne comptent pas dans le décompte des consultations DNS. Vous créez ensuite vos enregistrements SPF en utilisant les adresses IP au lieu des noms d'hôtes.
dmarcian a développé l'aplatissement SPF comme une expérience pour contourner la limite de consultation du DNS. Dans la RFC 7208 de l'IETF, la norme d'authentification des e-mails SPF, les consultations sont limitées pour "éviter une charge déraisonnable sur le DNS". Vous pouvez entrer dans les détails de la norme ici.
L'aplatissement du SPF doit être découragé d'emblée ; la plupart des gens initient des enregistrements SPF qui autorisent une grande partie de l'Internet qui ne fait pas réellement d'authentification dans le contexte du SPF. Le résultat est une surface de risque accrue où un mauvais acteur peut accéder aux parties de l'Internet qui sont indûment autorisées et envoyer des e-mails depuis ce domaine. Il est préférable de collecter les données DMARC comme point de départ pour comprendre le contexte global de l'authentification et décider quels mécanismes doivent être représentés dans les enregistrements SPF.
Tim Draegen, directeur technique de dmarcian et coauteur de la spécification DMARC.
Comment résoudre le problème "Trop de recherches DNS" ?
- Éliminez (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, aka return-path et utilise votre domaine. Si vous avez un compte dmarcian, supprimez les enregistrements SPF pour les sources apparaissant dans votre Visualiseur de détails qui sont "incapables de SPF" et présentent un taux de réussite SPF de 0%. Si vous n'avez pas de compte dmarcian, vous pouvez vous référer à 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 doivent 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.
- Supprimer les mécanismes SPF en double.
- Ne tenez pas compte des 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 effectivement des milliers d'adresses IP à envoyer des messages au nom de ce domaine.
- Lorsque le courrier électronique est incapable de passer DMARC avec SPF, configurez DKIM.
- Vérifiez 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 de sous-domaine depuis l'intégration).
- Déplacer le trafic des fournisseurs vers des sous-domaines pour l'authentification SPF (voir plus loin). La segmentation en sous-domaines crée un nouveau domaine dédié à un flux de courrier particulier avec ses propres 10 recherches DNS.
Meilleures pratiques SPF
À mesure que les organisations se développent, les sources de courrier électronique peuvent s'accumuler de manière sporadique et organique. Pour cette raison, des mécanismes sont souvent ajoutés aux enregistrements SPF alors que les mécanismes non utilisés ne sont pas examinés pour voir s'ils peuvent être supprimés.
Du point de vue de la sécurité, des opérations et de la délivrabilité, dmarcian préconise la stratégie de segmentation pour la gestion des SPF. Nous recommandons que les différents flux d'e-mails (types de trafic) soient séparés lorsque cela est possible. L'idée est de séparer les flux par type, comme le marketing de masse, le transactionnel, la facturation, les fournisseurs tiers spécifiques, les entités opérationnelles, etc.
Pour y parvenir, il est également préférable de séparer le trafic de messagerie dans des sous-domaines dédiés à ces flux. Cela permet d'accroître la visibilité de chaque flux et d'isoler l'utilisation d'un système ou d'un fournisseur particulier. Lorsque l'authentification SPF est nécessaire, elle apporte également une sécurité supplémentaire et une simplicité opérationnelle en déchargeant la charge d'une approche à domaine unique et en évitant le gonflement du 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 de l'utilisation d'un sous-domaine peut avoir un impact sur la réputation et la délivrabilité.
Asher Morin, Directeur du déploiement de dmarcian
Outre la réduction des consultations du DNS par une stratégie de segmentation des sous-domaines, voici quelques autres bonnes pratiques SPF :
- Évitez d'utiliser le mécanisme ptr. Le mécanisme ptr est déprécié et risque de faire peser une charge importante sur le DNS lors de l'interrogation, et certains destinataires ignoreront complètement ce mécanisme (ou l'enregistrement SPF).
- Protégez tous les domaines non expéditeurs avec un enregistrement SPF restrictif, "deny all" : "v=spf1 -all". Les mauvais acteurs rechercheront activement des domaines inutilisés à exploiter.
- Évitez "+all" ou "all" car ils autorisent le passage de toute IP non explicitement refusée dans votre enregistrement SPF. N'utilisez pas non plus "?all" car il est neutre et ne fournit aucune indication sur la 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 destinataire - cela peut faire la différence entre un e-mail qui finit dans un dossier de courrier indésirable et un autre qui ne finit pas.
- 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 vous recommandons de refléter la politique DMARC au fur et à mesure que la technologie est déployée : utilisez "~all" lorsque les politiques DMARC sont "none" et "quarantine", et déployez "-all" lorsque vous êtes passé à une politique de "reject".
- Créez des processus dans votre organisation pour le contrôle et la gestion continus des FPS. Cet examen périodique doit prendre en compte l'intégration et le retrait de fournisseurs tiers, le cas échéant.
Si vous avez des questions sur la façon de gérer vos enregistrements SPF, contactez-nous. Vous pouvez également lire d'autres articles et conseils sur le SPF ici et regarder notre vidéo sur le SPF.
Avec une équipe d'experts en sécurité du courrier électronique et une mission visant à 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 à mettre en œuvre et gérer DMARC à long terme.
Vous voulez continuer la conversation ? Rendez-vous sur le forum dmarcien.
