SOBOO : Comment envoyer des e-mails conformes à DMARC au nom d'autres entités

Fait partie de la série Envoyer au nom d'autres personnes (SOBOO)

L'envoi d'e-mails pour le compte d'autres personnes de manière conforme à DMARC peut être réalisé de différentes manières. Cet article s'adresse aux fournisseurs de services de messagerie (ESP) et à toute entreprise qui envoie des e-mails en utilisant les domaines de ses propres clients (exemples : CRM, sociétés de gestion des talents, systèmes de facturation, etc.).

dmarcian gère le Centre de ressources opérationnelles DMARC qui comprend un annuaire des sources d'e-mails détaillant comment configurer une source pour qu'elle soit conforme à DMARC.

Cet annuaire fait gagner beaucoup de temps à de nombreuses personnes :

• Les propriétaires de domaines peuvent découvrir si leur système CRM/de gestion des talents/de facturation est capable d'envoyer des e-mails conformes à DMARC et, le cas échéant, comment le faire. Plus besoin de passer des heures à fouiller les archives Internet, à contacter le support ou à essayer de reconstituer une solution à partir d'informations partielles.
• Les chefs de produit d'une source d'e-mails peuvent savoir exactement ce que les utilisateurs demandent lorsqu'ils sollicitent un support DMARC. Cela clarifie les exigences, accélère la mise en œuvre et aboutit à une fonctionnalité livrée qui satisfait les clients.

Cet article détaille comment obtenir l'autorisation d'envoyer au nom d'un domaine, les capacités requises pour l'envoi d'e-mails conformes à DMARC, les changements potentiels dans le processus d'intégration des clients, et les actions à entreprendre une fois DMARC implémenté.

Comment envoyer en utilisant le domaine d'un client

Un e-mail conforme à DMARC est facile à identifier et fonctionne en établissant un lien entre le domaine d'un client et un message électronique. Voici une courte vidéo expliquant le fonctionnement de DMARC.

Il existe plusieurs façons de s'associer au domaine d'un client afin de pouvoir envoyer des e-mails conformes à DMARC en son nom.

REMARQUE : DMARC vous permet d'envoyer des e-mails authentifiés en utilisant un sous-domaine (tel que email.company.com), tout en pouvant utiliser le domaine de premier niveau dans l'en-tête From: (par exemple, From: offers@company.com).

Les meilleures approches suivantes sont listées en premier, suivies des approches moins efficaces :

Délégation de domaine

Lorsqu'un client vous délègue un sous-domaine à gérer (tel que email.company.com), vous pourrez envoyer des e-mails qui s'authentifient auprès du sous-domaine et, dans la plupart des cas, être autorisé à envoyer des e-mails en utilisant le domaine de premier niveau dans l'en-tête From: (par exemple, From: Best Offers <[email protected]>). Tout ce qui est impliqué dans l'envoi d'e-mails conformes à DMARC est désormais géré au nom du client, puisque vous contrôlez et exploitez l'intégralité du sous-domaine. Il existe deux façons de mettre en œuvre la délégation de sous-domaine :

Délégation complète

Le client vous délègue un sous-domaine entier à gérer. Ce faisant, vous devenez responsable du sous-domaine et de tout ce qui en dépend (y compris les sous-domaines du sous-domaine). La délégation du sous-domaine est la seule action requise de votre client, ce qui en fait une approche privilégiée.

CNAMEs

Le client crée plusieurs CNAMEs qui pointent vers votre propre domaine. Il s'agit effectivement d'une forme de délégation, à l'exception que les services individuels sont délégués par chaque CNAME. C'est similaire à la délégation complète, sauf que le client doit initialement créer plus d'entrées DNS, ce qui en fait une alternative proche de l'approche privilégiée de délégation complète.

Les CNAMEs sont couramment créés pour :

• Gestion du SPF et des rebonds. Par exemple, un client crée un CNAME qui pointe de marketing.customer-domain.org vers bounces.email-service-provider.com. L'e-mail envoyé au nom du client utilise une adresse de rebond de @marketing.customer-domain.org. Non seulement l'enregistrement SPF correspondant est géré par vous (puisqu'il s'agit en réalité de l'enregistrement SPF pour bounces.email-service-provider.com),Nous avons publié une courte vidéo de présentation du SPF ici.)
• DKIM. Le client peut créer plusieurs enregistrements CNAME qui pointent vers vos propres clés publiques publiées, et vous pouvez utiliser ces enregistrements CNAME pour ajouter des signatures DKIM aux e-mails que vous envoyez au nom du client. La présence de plusieurs CNAMEs vous permet de faire pivoter les clés DKIM sans que le client n'ait à intervenir. (Nous avons publié une courte vidéo de présentation de DKIM ici.)
• Mappage des liens d'e-mail vers le domaine du client. Au lieu d'intégrer des liens qui pointent vers votre propre domaine, vous pouvez ajouter des liens dans les e-mails de votre client qui utilisent le domaine de ce dernier. Lorsqu'un utilisateur clique sur un lien dans l'e-mail, le CNAME est résolu vers vos propres services pour le suivi, etc.

Relais

Le relais est parfois une option si seule une petite quantité d'e-mails est envoyée au nom du client. Permettre à un client de configurer l'envoi de ses e-mails via un autre serveur de messagerie est un moyen d'assurer la conformité DMARC si le relais lui-même est capable d'envoyer des e-mails conformes à DMARC.

Il existe deux façons de permettre cela :

Relais SMTP

Permettez aux clients de configurer un relais SMTP pour tous les e-mails que vous envoyez en leur nom. (Nous avons une courte vidéo de présentation sur le SMTP, mais elle ne couvre pas le relais.) Celui qui gère le relais devient alors responsable de la conformité DMARC.

Voici les inconvénients :

• La gestion des rebonds disparaît à moins que le relais ne soit capable de vous les retransmettre pour traitement.
• La livraison des e-mails devient la responsabilité de l'opérateur du relais, ce qui signifie que votre service d'e-mail dépend désormais de quelque chose opéré par votre client.

Configurer les identifiants utilisateur

Permettez aux clients de configurer les identifiants utilisateur. Cela exige que le client provisionne un compte pour votre service, puis configure votre service pour utiliser les identifiants du nouvel utilisateur. Vous enverriez alors tout e-mail comme si vous étiez l'utilisateur.

Voici les inconvénients :

• Vous devez gérer l'accès au niveau utilisateur à une multitude de plateformes de messagerie, car votre propre client pourrait utiliser Gmail, Yahoo, Microsoft, Exchange, etc.
• Vous utilisez les ressources de vos clients pour envoyer des e-mails en leur nom.

Configuration manuelle

Au lieu d'opérer un sous-domaine délégué (ou d'utiliser des CNAMEs), vous pouvez demander aux clients de configurer leur domaine afin que vous puissiez envoyer des e-mails conformes à DMARC :

SPF

Vous pouvez demander à votre client d'ajouter vos propres blocs réseau dans l'enregistrement SPF du client. C'est une demande courante, mais elle est souvent faite pour de mauvaises raisons. Cela vous permettra d'envoyer des e-mails autorisés au nom du client mais uniquement si le domaine du client est utilisé dans l'adresse de rebond des e-mails que vous envoyez.

Inconvénients :

• Les messages rebondis seront acheminés à votre client au lieu de vous être retournés. Vous n'aurez aucune visibilité sur les problèmes qui affectent vos performances en tant qu'expéditeur d'e-mails, et votre client aura une mauvaise expérience utilisateur.
• Votre client doit penser à vous lorsqu'il maintient son enregistrement SPF. C'est ennuyeux pour vos clients qui doivent gérer un tas d'autres expéditeurs ayant demandé à être inclus dans leur enregistrement SPF pour de mauvaises raisons.

DKIM

Vous pouvez demander aux clients d'ajouter des clés liées à DKIM dans leur domaine.

Inconvénients :

• Votre client doit copier-coller de longues chaînes de caractères dans son logiciel de gestion de domaine. Des erreurs se produisent souvent, ce qui est agaçant pour les utilisateurs et pour vous-même.
• Vous ne pouvez pas faire pivoter les clés DKIM sans demander à votre client d'effectuer une tâche. C'est fastidieux au mieux. Au pire, une clé DKIM doit être pivotée en raison d'une urgence (pendant des vacances !), et c'est probablement la pire interaction client possible : « Votre clé est utilisée pour envoyer des e-mails frauduleux. Pouvez-vous tout laisser tomber maintenant pour nous aider à résoudre ce problème ? »

N'hésitez pas à nous faire savoir si vous avez découvert une nouvelle méthode qui mérite d'être partagée.

Capacités requises

Comme décrit ci-dessus, l'envoi d'e-mails conformes à DMARC pour le compte de vos propres clients peut être réalisé de diverses manières. Chaque approche représente un compromis en termes de capacité entre « la facilité pour moi » et « la facilité pour mon client ». Étant donné qu'il y a une quantité fixe de travail de configuration et opérationnel à effectuer, vous pouvez :

• Effectuer ce travail pour le compte de votre client,
• répartir le travail entre vous et votre client, ou
• laisser votre client effectuer le travail.

Quelle que soit l'approche, un certain travail est toujours nécessaire pour vous permettre d'envoyer pour le compte de votre client :

Délégation de sous-domaine

Client

Configuration unique du domaine pour implémenter les sous-domaines/CNAMEs.

Vous

• Opération du système de domaine pour gérer/vérifier/surveiller la délégation de sous-domaine/les CNAMEs.
• Fonctionnalités du serveur de messagerie pour utiliser le sous-domaine du client dans l'adresse de rebond et dans les signatures DKIM.
• Maintenance de l'enregistrement SPF.

Relais

Client

• Le client doit fournir sa propre ressource de relais.
• Configuration unique pour ajouter les informations de relais à votre système.

Vous

• Fonctionnalités du serveur de messagerie pour utiliser le relais du client et—si vous êtes sérieux quant à l'envoi d'e-mails—pour gérer le traitement des rebonds. Étant donné que pratiquement tous les serveurs de messagerie prennent en charge la capacité de relayer les e-mails, le travail ici consiste à exposer cette fonctionnalité aux clients pour qu'ils en profitent.

Configuration manuelle

Client

• Configuration unique du domaine pour ajouter les enregistrements SPF et les clés de signature DKIM.
• Configuration additionnelle si les enregistrements SPF doivent être mis à jour ou si les clés de signature DKIM doivent être remplacées.

Vous

• Fonctionnalités du serveur de messagerie pour utiliser le domaine du client dans l'adresse de rebond et dans les signatures DKIM.
• Maintenance de l'enregistrement SPF, et s'assurer que les clients mettent à jour leur enregistrement SPF lorsque vous modifiez votre infrastructure. C'est soit facile si vos clients include: votre infrastructure via SPF, ou difficile si vous demandez à vos clients d'ajouter des éléments tels que ip4: dans leurs enregistrements SPF.

Le lecteur averti notera que certains changements doivent être effectués quelle que soit l'approche adoptée. Les fonctionnalités du serveur de messagerie sont requises dans tous les cas.

Il existe une grande quantité de « capacités requises » communes entre les approches sans relais, les principales différences concernant les différentes manières dont le client peut configurer son domaine pour vous permettre d'envoyer en son nom. Sur la base de cette observation, il est tout à fait judicieux de faciliter les choses pour vos clients si vous êtes déjà engagé à envoyer des e-mails en leur nom.

Intégration des clients

La première approche (délégation de sous-domaine) est efficace du point de vue de la minimisation de ce qu'un client doit implémenter avant que vous ne puissiez envoyer des e-mails conformes à DMARC en son nom.

La deuxième approche (le relais) délègue essentiellement l'envoi d'e-mails conformes à DMARC à votre client. Cette approche pourrait être préférée si vous envoyez très peu d'e-mails au nom de vos clients et que l'investissement requis pour envoyer des e-mails conformes à DMARC ne se justifie pas.

La troisième approche (configuration manuelle) exige le même niveau d'implémentation client que l'approche de délégation de sous-domaine, à la différence que des modifications plus spécifiques sont nécessaires pour commencer.

De plus, la troisième approche peut être considérée comme peu robuste : des modifications de votre propre infrastructure pourraient exiger de votre client qu'il apporte des changements correspondants à la configuration de son domaine. Coordonner ce type de changement peut être fastidieux, coûteux et sujet aux erreurs.

Envoi d'e-mails au nom des clients

L'envoi d'e-mails conformes à DMARC offre de nombreux avantages pour vous-même et votre client et contribue grandement à faciliter l'identification de vos e-mails. Si vous souhaitez envoyer des e-mails de premier ordre (ou même simplement des e-mails qui sont livrés !), envisagez de faire un effort supplémentaire et d'utiliser le domaine de votre client pour tout ce qui concerne un e-mail :

• Les liens d'e-mails peuvent sembler provenir du domaine de votre client, mais lorsqu'une personne clique sur un lien, il peut être géré par votre propre infrastructure.
• Il en va de même pour les images et autres objets : ils semblent provenir du domaine de votre client, mais sont servis par votre propre infrastructure.
• Les noms de serveurs liés à la livraison d'e-mails peuvent être modifiés pour refléter le domaine de votre client.

Les changements ci-dessus sont possibles si l'approche par sous-domaine est utilisée. Cela rend les e-mails que vous envoyez au nom de vos clients incroyablement faciles à identifier et à livrer.

Si vous souhaitez être répertorié dans l'annuaire des sources d'e-mails, contactez-nous à [email protected].

Des questions/commentaires ? Contactez-nous à [email protected].

Nous sommes là pour vous aider
Avec une équipe d'experts en sécurité e-mail et une mission visant à rendre l'e-mail et 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.