Les défis de la gestion du SPF
Le monde du courrier électronique était bien différent en 1997 lorsque l'idée du SPF a pris forme. Il est passé presque inaperçu lorsqu'il a été mentionné publiquement pour la première fois vers 2000, mais en 20 ans, il est devenu l'une des formes les plus répandues d'authentification des e-mails, avec DKIM et DMARC. Garantir l'exactitude de votre enregistrement était alors un défi bien différent de celui que vous devez relever aujourd'hui.
L'exactitude de votre enregistrement SPF dépend de votre compréhension et de votre visibilité de votre écosystème de messagerie. Pour de nombreuses organisations, cet écosystème est constitué d'une infrastructure gérée directement par l'entreprise ou sur place, dans une jungle de services hébergés qui envoient 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 mise en œuvre, ainsi que par le DNS lui-même. Jongler avec ces limites est une réalité qui doit être prise en compte et intégrée dans les processus de gestion des domaines de toute organisation.
Dans cet article, notre équipe de déploiement aborde principalement les défis courants liés au déploiement de SPF dans le monde moderne de l'authentification des e-mails.
Imaginons un instant que vous possédiez un seul domaine, ainsi qu'un environnement en ligne hybride sur site/exchange, 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. En réalité, ce processus devrait inclure l'évaluation de la façon dont ces services envoient des e-mails en votre nom, l'identification du problème SPF que vous rencontrez et la compréhension des solutions pour chacun d'entre eux afin d'élaborer un plan de déploiement.
Le problème rencontré relève généralement de l'un des cas suivants : Vous dépassez la limite de 10 consultations DNS, ou votre enregistrement est trop gros pour tenir dans un seul enregistrement TXT - le premier cas est de loin le plus fréquent. Que peut-on faire à ce sujet ? Eh bien, il existe peu de solutions, et aucune n'est parfaite. Cependant, s'il est nécessaire de trouver une solution, il est primordial de comprendre le problème grâce à la connaissance de la gestion de votre écosystème de messagerie. Cela vous permettra d'avoir une plus grande flexibilité dans la prise de décisions opérationnelles pour les pratiques de gestion des domaines de votre organisation.
Les solutions les plus souvent utilisées pour résoudre les limites de consultation du DNS de SPF 10 sont les suivantes :
- Éviter les mécanismes DNS inutiles
- Éviter les entrées "a" et "mx".
- Sources de courrier électronique dédiées aux sous-domaines
- Solutions SPF dynamiques
Examinons les avantages et les inconvénients de chacun.
Éviter les mécanismes DNS inutiles
Bien que cela puisse sembler être un conseil évident, il y a beaucoup de mauvaises indications sur Internet quant à savoir quand ou si une organisation doit ajouter un fournisseur ou un service spécifique à son enregistrement SPF. Rappelons qu'un vérificateur effectue une vérification de l'enregistrement SPF par rapport au domaine extrait soit de l'adresse e-mail RFC 5321 Mail From, soit de l'identité HELO/EHLO émise par le client au cours d'une conversation SMTP si l'adresse Mail From est nulle. Cette adresse électronique (également connue sous le nom de "return-path", "envelope from", "bounceback") est différente de l'en-tête d'adresse électronique RFC 5322 From :. Vous l'entendrez souvent appelée "Friendly From". Il s'agit de l'adresse électronique "From" généralement affichée dans un client de messagerie. Il arrive que ces deux adresses ne correspondent pas, mais ce n'est pas une obligation.
Lors de l'intégration d'un nouveau service ou d'un nouveau fournisseur, il est important de comprendre comment il enverra des e-mails au nom de vos domaines. Plus précisément, quel domaine utilisera-t-il comme voie de retour ? Si la réponse est aucun de vos domaines, 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 retour contiennent des métadonnées sur l'identité du 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 dans un enregistrement SPF est la présence de "a" et "mx". Bien que ceux-ci soient tout à fait valables et parfois utiles de manière correcte, 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 une erreur car cette adresse IP est celle de l'hôte web du domaine. Bien que cette utilisation puisse être légitime, elle n'est pas normale. Vous devez 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 les messages sortants ne passent pas par ce même environnement. Souvent, cette situation est tout à fait légitime, mais elle est incorrecte pour la plupart des grands environnements hébergés tels que M365, Google, etc. Si votre enregistrement SPF est déjà autorisé pour le trafic de votre fournisseur, l'ajout de "mx" est incorrect.
Sous-domaines dédiés au flux d'e-mails
Il s'agit ici de créer un sous-domaine qui sera utilisé par un ou quelques prestataires 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, lorsque vous avez un fournisseur qui ne prend pas en charge DMARC, et que vous l'isolez dans 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'il est extrait de la RFC 5321 Mail From. Cela signifie que si un courriel est envoyé en utilisant info@sales.example.org comme adresse de départ, le récepteur cherchera strictement dans le DNS un enregistrement SPF à sales.example.org, et non à son parent, jamais. Vous disposez ainsi d'un tout nouveau domaine pour créer un enregistrement SPF, d'une table rase. Isoler les flux d'e-mails de cette manière peut également contribuer à atténuer l'impact des abus potentiels des comptes de messagerie existant sur le sous-domaine uniquement. En retour, cela peut également contribuer à isoler l'impact de l'abus sur la réputation du domaine dans le sous-domaine, plutôt que d'avoir un impact sur tous les services utilisant l'identité du domaine principal de l'entreprise.
En fonction de l'étendue de ce sous-domaine, il peut y avoir des coûts supplémentaires associés au déploiement, tels que l'identification des besoins en licences supplémentaires, en ressources web, etc. L'évaluation des besoins déterminera les ressources nécessaires au déploiement et les coûts associés. L'évaluation des besoins permettra de déterminer les ressources nécessaires au déploiement et les coûts associés. En outre, cela ajoute à la charge administrative actuelle de votre équipe de gestion du domaine.
Solutions SPF dynamiques
L'idée d'un enregistrement SPF dynamique peut représenter plusieurs choses, comme l'aplatissement dynamique d'un enregistrement, puis la publication du résultat en fonction d'une source de données. Cela peut également signifier une gestion plus complexe grâce à l'utilisation de macros. Ces solutions peuvent être variées dans leur mise en œuvre, mais elles présentent généralement toutes les mêmes avantages. Principalement, elles permettent un certain type d'automatisation et offrent une plus grande flexibilité et évolutivité. L'objectif est de faire gagner du temps à l'administration sans avoir à se soucier du nombre d'expéditeurs qui envoient des messages au nom de votre domaine.
Ces solutions peuvent être très solides, mais elles ne sont pas une panacée. Elles nécessitent un temps de développement interne important pour une solution personnalisée en interne. De manière plus réaliste, les organisations chercheront un fournisseur de services pour cette fonctionnalité, et ils peuvent être coûteux. Cela fait également évoluer la mentalité vers un déploiement SPF d'abord, en utilisant peu de domaines, voire un seul. Étant donné que de nombreux fournisseurs de services ne prennent pas en charge un chemin de retour personnalisé, c'est-à-dire un chemin de retour utilisant votre domaine au lieu du leur, ces solutions ne seront d'aucune utilité et reposeront spécifiquement sur DKIM pour l'authentification lors du déploiement de DMARC. Dans certaines implémentations, il peut également y avoir une plus forte dépendance au DNS avec un seul point de défaillance pour tous les flux de courrier électronique.
En fin de compte, rien ne vaut une recherche approfondie pour déterminer quelle est la meilleure solution pour résoudre votre problème. Quelle que soit la solution que vous utilisez, un processus solide de gestion des SPF est la meilleure pratique pour garantir le succès du déploiement de l'authentification des e-mails à long terme.
Si vous avez des questions, visitez notre site Web et discutez avec nous. Si vous ne l'avez pas encore fait, vous pouvez vous inscrire pour un essai gratuit ici et nous laisser vous aider à sécuriser vos domaines de messagerie.
Vous voulez poursuivre la conversation ? Rendez-vous sur le forum dmarcien.
