Défis de gestion du SPF
Le monde de l'e-mail était bien différent en 1997, lorsque l'idée du SPF prenait forme. Il est passé largement inaperçu lors de sa première mention publique vers 2000, mais 20 ans plus tard, il est désormais l'une des formes d'authentification des e-mails les plus répandues, aux côtés de DKIM et DMARC. Assurer l'exactitude de votre enregistrement à l'époque représentait un défi bien différent de celui d'aujourd'hui.
L'exactitude de votre enregistrement SPF repose sur votre compréhension et votre visibilité sur votre écosystème de messagerie. Pour de nombreuses organisations, cet écosystème se compose d'une infrastructure gérée directement, détenue ou sur site, au sein d'une jungle de services hébergés envoyant des e-mails au nom de vos domaines. Ces dernières années, cette jungle n'a fait que s'étendre, repoussant rapidement, et parfois brisant, les limites du SPF imposées par sa propre implémentation, ainsi que par le DNS lui-même. Gérer ces limites sont des réalités qui doivent être prises en compte et intégrées aux processus de gestion de domaine de toute organisation.
Dans cet article, notre équipe de déploiement aborde principalement les défis courants liés au déploiement du SPF dans le monde moderne de l'authentification des e-mails.
Imaginons un instant que vous possédez un seul domaine, ainsi qu'un environnement hybride sur site/Exchange Online, et une douzaine de services hébergés qui envoient des e-mails au nom de ce domaine. La première idée pourrait être de simplement ajouter toutes les entrées pertinentes à l'enregistrement SPF de votre domaine et d'en rester là. Après tout, ils utilisent votre domaine pour envoyer des e-mails, donc le processus devrait être simple. La réalité est que ce processus devrait inclure l'évaluation de la manière dont ces services envoient des e-mails en votre nom, l'identification du défi SPF que vous rencontrez et la compréhension des solutions à chacun pour élaborer un plan de déploiement.
Le problème rencontré relèvera généralement de l'un des cas suivants : vous dépassez la limite de 10 requêtes DNS, ou votre enregistrement est trop volumineux pour tenir dans un seul enregistrement TXT — le premier étant de loin le plus courant. Que faire à ce sujet ? Eh bien, il existe peu de solutions, et aucune n'est parfaite. Cependant, bien que trouver une solution soit nécessaire, l'importance de comprendre le problème grâce à une connaissance approfondie de votre écosystème de messagerie est primordiale. Cela vous offrira une plus grande flexibilité pour prendre des décisions opérationnelles concernant les pratiques de gestion de domaine de votre organisation.
Les solutions courantes les plus souvent utilisées pour résoudre les limites de 10 requêtes DNS du SPF sont les suivantes :
- Éviter les mécanismes DNS inutiles
- Éviter les entrées « a » et « mx »
- Sous-domaines dédiés aux sources d'e-mails
- Solutions SPF dynamiques
Examinons les avantages et les inconvénients de chacun.
Éviter les mécanismes DNS inutiles
Bien que cela puisse sembler un conseil évident, il existe de nombreux mauvais conseils sur Internet concernant le moment ou la nécessité pour une organisation d'ajouter un fournisseur ou un service spécifique à son enregistrement SPF. Rappelons qu'un vérificateur effectue une vérification d'enregistrement SPF par rapport au domaine extrait de l'adresse e-mail Mail From de la RFC 5321, ou de l'identité HELO/EHLO émise par le client lors d'une conversation SMTP si le Mail From est nul. Cette adresse e-mail (également connue sous le nom de return-path, envelope from, bounceback address) n'est pas la même que l'en-tête d'adresse e-mail From: de la RFC 5322. Vous l'entendrez souvent appelée le Friendly From. C'est l'adresse e-mail de l'expéditeur couramment affichée dans un client de messagerie. Ces deux adresses ne correspondent parfois pas, et elles n'ont pas à le faire.
Lors de l'intégration d'un nouveau service ou fournisseur, il est important de comprendre comment ils enverront des e-mails au nom de vos domaines. Plus précisément, quel domaine utiliseront-ils comme return-path ? Si la réponse est aucun de vos domaines, alors il n'y a aucune raison, du point de vue de l'authentification, de les ajouter à votre enregistrement SPF. Il peut être difficile de comprendre ou de voir comment les services existants envoient déjà des e-mails, et c'est là que DMARC peut aider, car les rapports de feedback contiennent des métadonnées sur l'identité de domaine qui a été vérifiée dans le cadre de la vérification SPF du récepteur. Gardez vos enregistrements propres !
Éviter les entrées « a » et « mx »
L'une des erreurs les plus courantes pour un enregistrement SPF est d'inclure les mécanismes « a » et « mx ». Bien que ces mécanismes soient tout à fait valides et parfois utiles lorsqu'ils sont correctement utilisés, ils sont le plus souvent inutiles et ne devraient pas apparaître. Le mécanisme « a » indique que l'adresse IP du domaine doit être autorisée à transmettre des messages pour le domaine dans l'en-tête « From » des messages ; c'est généralement incorrect car cette adresse IP est celle de l'hébergeur web du domaine. Bien que cela PUISSE être une utilisation légitime, ce n'est pas la norme. Vous devriez enquêter et supprimer l'entrée si possible.
Le mécanisme « mx » indique que les adresses IP des enregistrements MX du domaine doivent être autorisées à transmettre des messages pour le domaine dans l'en-tête « From » des messages ; cela peut être incorrect car les hôtes MX sont utilisés pour le trafic entrant, et le trafic sortant ne passe pas par le même environnement. Souvent, c'est tout à fait légitime, mais c'est incorrect pour la plupart des grands environnements hébergés tels que M365, Google, etc. Si votre enregistrement SPF autorise déjà le trafic de votre fournisseur (comme ceux-ci), l'ajout de « mx » est incorrect.
Sous-domaines dédiés aux flux d'e-mails
Ce dont nous parlons ici, c'est de créer un sous-domaine qui sera utilisé par un ou quelques fournisseurs de services. Pensez à sales.example.org pour tous les expéditeurs tiers liés aux ventes. Ce besoin est parfois inévitable lors du déploiement de DMARC, où vous pourriez avoir un fournisseur qui ne prend pas en charge DMARC, et vous l'isolez sur son propre sous-domaine avec sa propre politique DMARC.
Lorsqu'un vérificateur effectue une vérification d'enregistrement SPF, il ne regarde que le domaine tel qu'extrait du Mail From de la RFC 5321. Cela signifie que si un e-mail est envoyé en utilisant [email protected] comme adresse Mail From, le récepteur recherchera strictement dans le DNS un enregistrement SPF à sales.example.org, et jamais à son parent. Cela vous offre un tout nouveau domaine pour créer un enregistrement SPF, une table rase. Isoler les flux d'e-mails de cette manière peut également aider à atténuer l'impact d'un abus potentiel de comptes de messagerie existant uniquement sur le sous-domaine. En retour, cela peut également aider à isoler l'impact de la réputation du domaine dû à un abus sur le sous-domaine, plutôt que d'affecter tous les services utilisant l'identité de votre domaine d'entreprise principal.
Selon la portée de ce sous-domaine, des coûts supplémentaires peuvent être associés au déploiement, tels que l'identification de la nécessité de licences supplémentaires, de ressources web, etc. La définition de la portée du besoin déterminera les ressources requises pour le déploiement et tous les coûts associés. De plus, cela ajoute à la charge administrative actuelle de votre équipe de gestion de domaine.
Solutions SPF dynamiques
L'idée d'un enregistrement SPF dynamique peut recouvrir plusieurs aspects, comme l'aplatissement dynamique d'un enregistrement, puis la publication du résultat basée sur une source de données. Cela pourrait également signifier une gestion plus complexe grâce à l'utilisation de macros. Ces solutions peuvent varier dans leur implémentation, mais elles présentent généralement toutes les mêmes avantages. Principalement, elles permettent une forme d'automatisation et offrent une plus grande flexibilité et évolutivité. L'objectif est de gagner du temps d'administration tout en n'ayant pas à se soucier du nombre d'expéditeurs envoyant des e-mails au nom de votre domaine.
Ce sont des solutions très robustes, mais ce ne sont pas une panacée. Elles nécessiteraient un temps de développement interne considérable pour une solution personnalisée en interne. Plus réalistement, les organisations rechercheront un fournisseur de services pour cette fonctionnalité, et ceux-ci peuvent être coûteux. Cela déplace également la mentalité vers un déploiement SPF-first, utilisant peu, voire un seul domaine. De nombreux fournisseurs de services ne prenant pas en charge un return-path personnalisé, c'est-à-dire un return-path utilisant votre domaine au lieu du leur, de telles solutions ne seront pas utiles et s'appuieront spécifiquement sur DKIM pour l'authentification lors du déploiement de DMARC. Dans certaines implémentations, il peut également y avoir une dépendance DNS plus forte avec un point de défaillance unique pour tous les flux d'e-mails.
En fin de compte, rien ne vaut une recherche approfondie pour déterminer la meilleure solution à votre problème. Quelle que soit celle que vous utilisez, un processus de gestion SPF robuste est une bonne pratique pour assurer le succès à long terme du déploiement de l'authentification des e-mails.
Si vous avez des questions, visitez notre site web et discutez avec nous. Si ce n'est pas déjà fait, vous pouvez vous inscrire pour un essai gratuit ici et laissez-nous vous aider à sécuriser vos domaines de messagerie.
Vous souhaitez poursuivre la conversation ? Rendez-vous sur le Forum dmarcian.
