Partager via

Bonnes pratiques pour la prise en charge de l’authentification de l’expéditeur dans Azure Communication Services Email

  • Article

Cet article fournit les meilleures pratiques d’envoi de courrier électronique sur les enregistrements DNS et explique comment utiliser les méthodes d’authentification de l’expéditeur qui empêchent les attaquants d’envoyer des messages qui ressemblent à ceux qui proviennent de votre domaine.

Authentification par e-mail et configuration DNS

L’envoi d’un e-mail nécessite plusieurs étapes : vérifier si l’expéditeur de l’e-mail est bien propriétaire du domaine, vérifier la réputation du domaine, rechercher s’il y a des virus, filtrer pour exclure le courrier indésirable, les tentatives d’hameçonnage et les programmes malveillants, etc. La configuration appropriée de l’authentification des e-mails est un principe fondamental pour établir la confiance dans la messagerie et protéger la réputation de votre domaine. Si un e-mail satisfait aux vérifications d’authentification, le domaine de réception peut appliquer une stratégie à cet e-mail en respectant la réputation déjà établie pour les identités associées à ces vérifications d’authentification, et le destinataire peut être assuré que ces identités sont valides.

Enregistrement MX (Mail Exchange)

L’enregistrement MX (Mail Exchange) est utilisé pour router les e-mails vers le serveur approprié. Il spécifie le serveur de messagerie responsable de l’acceptation des messages électroniques pour le compte de votre domaine. DNS doit être mis à jour avec les dernières informations des enregistrements MX de votre domaine de messagerie, sinon il entraîne des échecs de remise.

SPF (Sender Policy Framework)

SPF RFC 7208 est un mécanisme qui permet aux propriétaires de domaine de publier et de gérer, via un enregistrement DNS TXT standard, une liste de systèmes autorisés à envoyer des e-mails en leur nom. Cet enregistrement est utilisé pour spécifier les serveurs de messagerie autorisés à envoyer un e-mail pour le compte de votre domaine. Il permet d’empêcher l’usurpation d’e-mail et d’augmenter la remise des e-mails.

DKIM (Domain Keys Identified Mail)

DKIM RFC 6376 permet à une organisation de revendiquer la responsabilité de transmettre un message d’une manière qui peut être validée par le destinataire. Cet enregistrement est également utilisé pour authentifier le domaine à partir duquel l’e-mail est envoyé et permet d’empêcher l’usurpation et d’augmenter la remise des e-mails.

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC RFC 7489 est un mécanisme évolutif par lequel une organisation à l’origine d’e-mails peut exprimer des stratégies et des préférences au niveau du domaine pour la validation, la destruction et la création de rapports de messages qu’une organisation recevant des e-mails peut utiliser pour améliorer la gestion des messages. Il est également utilisé pour spécifier comment les récepteurs de courrier doivent gérer les messages qui échouent SPF et DKIM case activée s. Cela améliore la remise des e-mails et permet d’empêcher l’usurpation des e-mails.

ARC (Authenticated Received Chain)

Le protocole ARC RFC 8617 fournit une chaîne de garde authentifiée pour un message, ce qui permet à chaque entité qui traite le message d’identifier les entités qui l’ont traité précédemment ainsi que d’évaluer l’authentification du message à chaque tronçon. ARC n’est pas encore une norme Internet, mais son adoption est en hausse.

Fonctionnement de l’authentification des e-mails

L’authentification des e-mails vérifie que les e-mails provenant d’un expéditeur (par exemple notification@contoso.com) sont légitimes et proviennent de sources attendues pour ce domaine de messagerie (par exemple contoso.com). Un e-mail peut contenir plusieurs adresses d’origine ou d’expéditeur. Ces adresses sont utilisées à des fins différentes. Par exemple, prenez les adresses suivantes :

  • L’adresse « Courrier reçu de » identifie l’expéditeur et spécifie où envoyer des notifications de retour si des problèmes se produisent lors de la remise du message, comme des notifications de non-remise. Ceci apparaît dans la partie « enveloppe » d’un e-mail et n’est pas affiché par votre application de messagerie. Ceci est parfois appelé « adresse 5321.MailFrom » ou « adresse de chemin inverse ».

  • L’adresse De est l’adresse affichée en tant qu’adresse De par votre application de messagerie. Cette adresse indique l’auteur de l’e-mail. Autrement dit, c’est la boîte aux lettres de la personne ou du système responsable de l’écriture du message. Ceci est parfois appelé « adresse 5322.From ».

  • SPF (Sender Policy Framework) permet de valider les e-mails sortants envoyés de votre messagerie depuis votre domaine (il provient bien de la personne qui prétend être cette personne).

  • DKIM (DomainKeys Identified Mail) permet de garantir que les systèmes de messagerie de destination approuvent les messages sortants envoyés de votre messagerie depuis votre domaine.

  • DMARC (Domain-based Message Authentication, Reporting, and Conformance) fonctionne avec SPF (Sender Policy Framework) et DKIM (DomainKeys Identified Mail) pour authentifier les expéditeurs d’e-mail et garantir que les systèmes de messagerie de destination approuvent les messages envoyés depuis votre domaine.

Implémentation de DMARC

L’implémentation de DMARC avec SPF et DKIM offre une protection puissante contre l’usurpation d’identité et l’hameçonnage. SPF utilise un enregistrement TXT DNS pour fournir la liste des adresses IP d'envoi autorisées pour un domaine donné. En règle générale, les vérifications SPF sont uniquement effectuées pour l'adresse 5321.MailFrom. Cela signifie que l’adresse 5322.From n’est pas authentifiée quand vous utilisez SPF par lui-même. Ceci permet un scénario où un utilisateur peut recevoir un message, qui satisfait à la vérification de SPF, mais qui a une adresse d’expéditeur 5322.From usurpée.

À l'instar des enregistrements DNS pour SPF, l'enregistrement pour DMARC est un enregistrement DNS au format texte (TXT) qui empêche l'usurpation d'identité et le hameçonnage. Vous publiez les enregistrements TXT DMARC dans le système DNS. Les enregistrements DMARC TXT valident l’origine des messages électroniques en vérifiant l’adresse IP de l’auteur d’un e-mail par rapport au propriétaire présumé du domaine expéditeur. L'enregistrement TXT DMARC identifie les serveurs de messagerie sortants autorisés. Les systèmes de messagerie électronique de destination peuvent alors vérifier si les messages reçus proviennent de serveurs de messagerie sortants autorisés. Ceci force une incompatibilité entre les adresses 5321.MailFrom et 5322.From dans tous les e-mails envoyés depuis votre domaine, et DMARC va échouer pour cet e-mail. Pour éviter cela, vous devez configurer DKIM pour votre domaine.

Un enregistrement de stratégie DMARC permet à un domaine d’annoncer que son e-mail utilise l’authentification. Il fournit une adresse e-mail pour recueillir un feedback sur l’utilisation de son domaine, et il spécifie une stratégie demandée pour la gestion des messages qui échouent aux vérifications d’authentification. Nous vous recommandons ceci :

  • Les domaines des déclarations de stratégie qui publient des enregistrements DMARC doivent être « p=reject » là où c’est possible ; sinon « p=quarantine ».
  • Les déclarations de stratégie de « p=none », « sp=none », et pct<100 ne doivent être vues que comme des états transitionnels, avec l’objectif de les supprimer aussi rapidement que possible.
  • Tout enregistrement de stratégie DMARC publié doit inclure au minimum une balise « rua » qui pointe vers une boîte aux lettres pour recevoir des rapports agrégés DMARC et ne doit renvoyer aucune réponse lors de la réception de rapports pour des raisons de confidentialité.

Étapes suivantes

Les documents suivants peuvent vous intéresser :