Conseils TechniquesSPF

Les défis de la gestion de SPF

By september 24, 2020maart 16th, 2021No Comments

Le monde du courrier électronique était bien différent en 1997, lorsque l’idée de SPF prenait forme. Il est passé pratiquement inaperçu lorsqu’il a été mentionné publiquement pour la première fois vers 2000, mais il a progressé rapidement pendant 20 ans, et il est maintenant l’une des formes d’authentification de courrier électronique les plus répandues en usage, avec DKIM et DMARC. Assurer l’exactitude de votre enregistrement en 2006 était 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é dans votre écosystème de courrier électronique. Pour de nombreuses organisations, cet écosystème consiste en une infrastructure gérée directement, qui est détenue ou se trouve sur place dans une jungle de services hébergés qui envoient des courriels au nom de vos domaines. Ces dernières années, cette jungle n’a fait que s’agrandir, repoussant rapidement, et parfois même dépassant, les limites de 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 des organisations. Dans cet article, notre équipe de déploiement parle principalement des défis communs liés au déploiement de SPF dans le monde moderne de l’authentification du courrier électronique.

Imaginons un instant que vous possédiez un seul domaine, ainsi qu’un environnement en ligne hybride, sur site / exchange, et une dizaine de services hébergés qui envoient des courriels 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’arrêter là. Après tout, ils utilisent votre domaine pour envoyer des courriers électroniques, le processus devrait donc être simple. En réalité, ce processus devrait inclure l’évaluation de la manière dont ces services envoient des courriels en votre nom, l’identification des problèmes de SPF que vous rencontrez et la compréhension des solutions à chacun d’entre eux pour former un plan de déploiement.

Le problème rencontré se situera généralement dans l’une des situations suivantes : vous dépassez la limite des 10 DNS ou votre enregistrement est trop volumineux pour tenir dans un seul enregistrement TXT ; le premier est de loin le plus courant. Que peut-on faire pour y remédier ? Il existe peu de solutions, et aucune n’est parfaite. Cependant, bien qu’il soit 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 courrier électronique. Cela vous permettra d’avoir une plus grande flexibilité dans la prise de décisions opérationnelles pour les pratiques de gestion du domaine de votre organisation.

Les solutions les plus souvent utilisées pour faire face aux limites de recherche de 10 DNS de SPF sont les suivantes :

  • aplatissement de l’enregistrement SPF
  • éviter les mécanismes DNS inutiles
  • sous-domaines dédiés des flux de messagerie
  • solutions SPF dynamiques

SPF Record Flattening (aplatissement de l’enregistrement SPF)

Probablement l’une des plus anciennes approches pour atténuer le problème de la consultation des 10 DNS, l’aplatissement d’un enregistrement SPF peut être efficace de plusieurs façons. Vous voulez savoir à quoi cela ressemble ? Rendez-vous sur notre populaire outil d’enquête SPF et introduisez votre domaine pour voir comment cela fonctionnerait pour vous.

L’aplatissement SPF peut permettre l’utilisation d’un domaine spécifique beaucoup plus que ce qui est normalement possible. Sa mise en œuvre est relativement simple, et il repose beaucoup moins sur le DNS que d’autres solutions puisque les principaux mécanismes utilisés ici seraient IPv4 ou IPv6. Le coût d’utilisation serait essentiellement une perte de temps, puisqu’il nécessite un examen périodique de chaque entrée, ainsi qu’un contrôle régulier et une bonne tenue de registres sur l’origine de l’aplatissement.

Éviter les mécanismes DNS inutiles

Bien que ce conseil puisse sembler évident, il y a beaucoup de mauvaises indications sur Internet quant au moment ou à l’opportunité pour une organisation d’ajouter un vendeur 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 électronique Mail From de RFC 5321, soit de l’identité HELO/EHLO émise par le client lors d’une conversation SMTP si (l’adresse) Mail From est non valable. Cette adresse électronique (également appelée « return path » (chemin de retour), « envelope from », « bounceback address » (adresse de rebond)) n’est pas la même que l’adresse électronique de RFC 5322 From: dans l’en-tête. Vous l’entendrez peut-être souvent appeler le Friendly From. Il s’agit de l’adresse électronique généralement affichée dans un client de messagerie. Ces deux adresses ne correspondent pas toujours, et ce n’est pas nécessaire.

Lors de l’intégration d’un nouveau service ou vendeur, il est important de comprendre comment ils enverront des courriels au nom de vos domaines. Plus précisément, quel domaine utiliseront-ils comme voie de retour ? 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 courriels, et c’est là que DMARC peut aider, car les rapports de rétroaction contiennent des métadonnées sur l’identité du domaine qui a été vérifiée dans le cadre du contrôle SPF du destinataire. Gardez vos dossiers propres !

Sous-domaines dédiés des flux de messagerie

Il s’agit ici 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 lorsque vous déployez DMARC et que vous avez un fournisseur qui ne soutient pas 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 du Mail From de RFC 5321. Cela signifie que si un courriel est envoyé en utilisant info@sales.example.org comme adresse d’émetteur, le destinataire cherchera strictement dans le DNS un enregistrement SPF sur sales.example.org, et jamais sur son parent. Cela vous donne un tout nouveau domaine pour créer un enregistrement SPF, une ardoise vierge. En isolant des flux de courriels de cette manière peut également aider à atténuer l’impact d’un abus potentiel de comptes de courriel existantes sur le sous-domaine uniquement. En retour, cela peut également aider à isoler l’impact de la réputation du domaine de l’abus du sous-domaine, plutôt que d’avoir un impact sur tous les services utilisant l’identité de votre domaine d’entreprise principal.

En fonction de la portée de ce sous-domaine, le déploiement peut entraîner des coûts supplémentaires, par exemple pour déterminer si des licences supplémentaires, des ressources web, etc. sont nécessaires. L’évaluation des besoins déterminera les ressources requises pour le déploiement et les coûts associés. En outre, cela alourdit la charge d’administration actuelle de votre équipe de gestion du domaine.

Dynamic SPF Solutions (Solutions SPF dynamiques)

L’idée d’un enregistrement SPF dynamique peut être plusieurs choses, comme l’aplatissement dynamique d’un enregistrement, puis la publication du résultat en fonction d’une source de données. Cela pourrait également signifier une gestion plus complexe grâce à l’utilisation de macros. Ces solutions peuvent être mises en œuvre de différentes manières, mais elles présentent toutes les mêmes avantages. En premier lieu, elles permettent un certain type d’automatisation et offrent une plus grande flexibilité et une plus grande évolutivité. L’objectif est de gagner du temps d’administration sans avoir à se soucier du nombre d’expéditeurs qui envoient au nom de votre domaine.

Ces solutions peuvent être très solides, mais elles ne sont pas une panacée. Elles nécessiteraient 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 celui-ci peut être coûteux. Cela fait également évoluer la mentalité vers un déploiement en priorité de SPF, en utilisant peu de domaines, voire un seul domaine. Comme de nombreux fournisseurs de services ne prennent pas en charge une voie de retour personnalisé, c’est-à-dire un chemin de retour 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 plus forte du DNS avec un point d’échec unique pour tous les flux de courrier électronique.

En conclusion

En fin de compte, rien ne remplace une recherche approfondie pour déterminer quelle est la meilleure solution à votre problème. Quelle que soit celle que vous choisissez, un solide processus de gestion de SPF est la meilleure pratique pour garantir le succès à long terme du déploiement de l’authentification de la messagerie.

Si vous avez des questions, visitez notre site web et discutez avec l’un de nos conseillers DMARC. Si vous ne l’avez pas encore fait, vous pouvez vous inscrire pour un essai gratuit ici et laissez-nous vous aider à sécuriser vos domaines de messagerie.