Authentification de messagerie électronique dans Microsoft 365

Conseil

Saviez-vous que vous pouvez essayer gratuitement les fonctionnalités de Microsoft Defender XDR pour Office 365 Plan 2 ? Utilisez la version d’évaluation Defender for Office 365 de 90 jours sur le hub d’essais du portail Microsoft Defender. Découvrez qui peut s’inscrire et les conditions d’essai ici.

En tant que organization Microsoft 365 avec des boîtes aux lettres dans Exchange Online, ou une Exchange Online Protection autonome (EOP) organization sans boîtes aux lettres Exchange Online, protégeant l’intégrité des messages électroniques des expéditeurs dans votre domaines est important. Les destinataires doivent être sûrs que les messages des expéditeurs de votre domaine proviennent réellement d’expéditeurs de votre domaine.

l’authentification Email (également appelée validation d’e-mail) est un groupe de normes pour identifier et empêcher la remise de messages électroniques provenant d’expéditeurs falsifiés (également appelée usurpation d’identité). Les expéditeurs usurpés sont couramment utilisés dans la compromission des e-mails professionnels (BEC), l’hameçonnage et d’autres attaques par e-mail. Ces normes sont les suivantes :

  • Sender Policy Framework (SPF) : spécifie les serveurs de messagerie sources autorisés à envoyer des messages pour le domaine.
  • DomainKeys Identified Mail (DKIM) : utilise un domaine pour signer numériquement des éléments importants du message afin de s’assurer que le message n’a pas été modifié en transit.
  • Authentification, rapports et conformité des messages basés sur le domaine (DMARC) : spécifie l’action pour les messages qui échouent aux vérifications SPF ou DKIM pour les expéditeurs dans le domaine, et spécifie où envoyer les résultats DMARC (rapports).
  • Chaîne de réception authentifiée (ARC) : conserve les informations d’authentification par e-mail d’origine par les services connus qui modifient les messages en transit. Le serveur de messagerie de destination peut utiliser ces informations pour authentifier les messages qui, autrement, échoueraient à DMARC.

Il est important de comprendre que ces normes sont des blocs de construction interdépendants qui fonctionnent ensemble pour fournir la meilleure protection possible contre l’usurpation et les attaques par hameçonnage. Tout ce qui est inférieur à toutes les méthodes d’authentification par e-mail entraîne une protection inférieure aux normes.

Pour configurer l’authentification par e-mail pour les messages envoyés à partir d’organisations Microsoft 365 avec des boîtes aux lettres dans des organisations Exchange Online ou autonomes Exchange Online Protection (EOP) sans boîtes aux lettres Exchange Online, consultez les articles suivants :

Pour éviter les échecs d’authentification par e-mail en raison de services qui modifient les messages entrants envoyés à votre organization Microsoft 365, consultez Configurer des scellants ARC approuvés.

Le reste de cet article explique :

Pourquoi la messagerie internet a besoin d’une authentification

Par conception, le courrier SMTP (Simple Mail Transfer Protocol) sur Internet ne fait aucun effort pour vérifier que l’expéditeur du message est bien celui qu’il prétend être.

Un message électronique SMTP standard se compose d’une enveloppe de message et d’un contenu de message :

  • L’enveloppe du message contient des informations pour la transmission et la réception du message entre les serveurs SMTP. L’enveloppe du message est décrite dans RFC 5321. Les destinataires ne voient jamais l’enveloppe du message, car elle est générée pendant le processus de transmission du message.
  • Le contenu du message comporte les champs d’en-tête de message (collectivement appelés l’en-tête de message) et le corps du message. L’en-tête de message est décrit dans RFC 5322.

En raison de cette conception, un message a plusieurs valeurs d’expéditeur :

  • L’adresse MAIL FROM (également appelée 5321.MailFrom adresse, expéditeur P1 ou expéditeur d’enveloppe) est l’adresse e-mail utilisée dans la transmission du message entre les serveurs de messagerie SMTP. Cette adresse est généralement enregistrée dans le champ d’en-tête Return-Path dans l’en-tête du message (bien que le serveur de messagerie source puisse désigner une adresse e-mail de retour différente). Cette adresse e-mail est utilisée dans les rapports de non-remise (également appelés NDR ou messages de rebond).
  • L’adresse de départ (également appelée 5322.From adresse ou expéditeur P2) est l’adresse e-mail dans le champ d’en-tête De et l’adresse e-mail de l’expéditeur affichée dans les clients de messagerie.

L’exemple suivant montre la transcription simplifiée d’une transmission de messages valide entre deux serveurs de messagerie SMTP :

S: HELO woodgrovebank.com
S: MAIL FROM: dubious@proseware.com
S: RCPT TO: astobes@tailspintoys.com
S: DATA
S: To: "Andrew Stobes" <astobes@tailspintoys.com>
S: From: "Woodgrove Bank Security" <security@woodgrovebank.com>
S: Subject: Woodgrove Bank - Action required
S:
S: Greetings,
S:
S: We need to verify your banking details.
S: Please click the following link to verify that we have the right information for your account.
S:
S: https://short.url/woodgrovebank/updateaccount/12-121.aspx
S:
S: Thank you,
S: Woodgrove Bank
S: .

Dans cet exemple :

  • Le serveur de messagerie source s’identifie comme woodgrovebank.com au serveur de messagerie de destination tailspintoys.com dans la commande HELO.
  • Le destinataire du message est astobes@tailspintoys.com.
  • L’adresse MAIL FROM dans l’enveloppe du message (utilisée pour transmettre le message entre les serveurs de messagerie SMTP) est dubious@proseware.com.
  • L’adresse De affichée dans le client de messagerie du destinataire est security@woodgrovebank.com.

Bien que ce message soit valide selon SMTP, le domaine de l’adresse MAIL FROM (proseware.com) ne correspond pas au domaine dans l’adresse de départ (woodgrovebank.com). Ce message est un exemple classique d’usurpation d’identité, où l’intention est susceptible de tromper le destinataire en masquant la véritable source du message à utiliser dans une attaque par hameçonnage.

De toute évidence, le courrier SMTP a besoin d’aide pour vérifier que les expéditeurs de messages sont bien ceux qu’ils prétendent être !

Comment SPF, DKIM et DMARC fonctionnent ensemble pour authentifier les expéditeurs de messages électroniques

Cette section explique pourquoi vous avez besoin de SPF, DKIM et DMARC pour les domaines sur Internet.

  • SPF : Comme expliqué dans Configurer SPF pour identifier les sources de courrier valides pour votre domaine Microsoft 365, SPF utilise un enregistrement TXT dans DNS pour identifier les sources de courrier valides du domaine MAIL FROM, et ce qu’il faut faire si le serveur de messagerie de destination reçoit des messages d’une source non définie (« échec dur » pour rejeter le message ; 'soft fail' pour accepter et marquer le message).

    Problèmes SPF :

    • SPF valide les sources pour les expéditeurs dans le domaine MAIL FROM uniquement. SPF ne prend pas en compte le domaine dans l’adresse De ou l’alignement entre les domaines MAIL FROM et From :

      • Un attaquant peut envoyer un e-mail qui passe l’authentification SPF (faux négatif) en procédant comme suit :
        • Inscrivez un domaine (par exemple, proseware.com) et configurez SPF pour le domaine.
        • Envoyez un e-mail à partir d’une source valide pour le domaine inscrit, avec les adresses e-mail De dans un autre domaine (par exemple, woodgrovebank.com).
      • Un service de messagerie légitime qui envoie des messages pour le compte d’autres domaines peut contrôler l’adresse MAIL FROM. Les autres domaines et le domaine MAIL FROM ne correspondent pas, de sorte que les messages ne peuvent pas passer l’authentification SPF (faux positif).

    • SPF s’arrête après que des messages rencontrent un transfert d’e-mail basé sur le serveur qui redirige ou relaie des messages.

      • Le transfert d’e-mail basé sur le serveur modifie la source du message du serveur d’origine vers le serveur de transfert.
      • Le serveur de transfert n’est pas autorisé à envoyer des messages à partir du domaine MAIL FROM d’origine. Le message ne peut donc pas passer l’authentification SPF (faux positif).

    • Chaque domaine et tous les sous-domaines nécessitent leurs propres enregistrements SPF individuels. Les sous-domaines n’héritent pas de l’enregistrement SPF du domaine parent. Ce comportement devient problématique si vous souhaitez autoriser les e-mails provenant de sous-domaines définis et utilisés, mais empêcher les e-mails de sous-domaines non définis et inutilisés.

  • DKIM : comme expliqué dans Configurer DKIM pour signer le courrier à partir de votre domaine Microsoft 365, DKIM utilise un domaine pour signer numériquement les éléments importants du message (y compris l’adresse de départ) et stocke la signature dans l’en-tête du message. Le serveur de destination vérifie que les éléments signés du message n’ont pas été modifiés.

    Comment DKIM aide SPF : DKIM peut valider les messages qui échouent à SPF. Par exemple :

    • Messages provenant d’un service d’hébergement de courrier où la même adresse MAIL FROM est utilisée pour le courrier provenant d’autres domaines.
    • Messages qui rencontrent un transfert d’e-mail basé sur le serveur.

    Étant donné que la signature DKIM dans l’en-tête de message n’est pas affectée ou modifiée dans ces scénarios, ces messages peuvent passer DKIM.

    Problèmes DKIM : le domaine utilisé par DKIM pour signer un message n’a pas besoin de correspondre au domaine dans l’adresse De affichée dans les clients de messagerie.

    Comme SPF, un attaquant peut envoyer un e-mail qui transmet l’authentification DKIM (un faux négatif) en procédant comme suit :

    • Inscrivez un domaine (par exemple, proseware.com) et configurez DKIM pour le domaine.
    • Envoyez un e-mail avec les adresses e-mail De dans un domaine différent (par exemple, woodgrovebank.com).

  • DMARC : comme expliqué dans Configurer DMARC pour valider le domaine d’adresse De pour les expéditeurs dans Microsoft 365, DMARC utilise SPF et DKIM pour case activée l’alignement entre les domaines dans les adresses MAIL FROM et From. DMARC spécifie également l’action que le système de messagerie de destination doit effectuer sur les messages qui échouent à DMARC et identifie où envoyer les résultats DMARC (réussite et échec).

    Comment DMARC aide SPF et DKIM : Comme décrit précédemment, SPF n’essaie pas de faire correspondre le domaine dans les adresses MAIL FROM domain et From. DKIM ne se soucie pas si le domaine qui a signé le message correspond au domaine dans l’adresse De.

    DMARC corrige ces lacunes en utilisant SPF et DKIM pour confirmer que les domaines dans les adresses MAIL FROM et From correspondent.

    Problèmes DMARC : services légitimes qui modifient les messages en transit avant l’arrêt de remise SPF, DKIM et, par conséquent, les vérifications DMARC.

  • ARC : Comme expliqué dans Configurer des scellants ARC approuvés, les services légitimes qui modifient les messages en transit peuvent utiliser ARC pour conserver les informations d’authentification par e-mail d’origine des messages modifiés.

    Comment ARC aide DMARC : le système de messagerie de destination peut identifier le service en tant que scellant ARC approuvé. ARC peut ensuite utiliser les informations d’authentification de messagerie conservées pour valider le message.

Authentification des e-mails entrants pour les messages envoyés à Microsoft 365

En raison de problèmes d’hameçonnage et de l’adoption peu complète de stratégies d’authentification de messagerie forte par les expéditeurs de courrier sur Internet, Microsoft 365 utilise l’authentification implicite par e-mail pour case activée le courrier entrant. L’authentification implicite par e-mail étend les vérifications SPF, DKIM et DMARC standard en utilisant des signaux provenant d’autres sources pour évaluer le courrier entrant. Ces sources sont les suivantes :

  • Réputation de l’expéditeur.
  • Historique de l’expéditeur.
  • Historique des destinataires.
  • Analyse comportementale.
  • Autres techniques avancées.

Pour voir l’annonce d’origine de Microsoft sur l’authentification implicite, voir A Sea of Phish Part 2 - Enhanced Anti-spoofing in Microsoft 365.

En utilisant ces autres signaux, les messages qui échoueraient autrement aux vérifications d’authentification par e-mail traditionnelles peuvent passer l’authentification implicite et être autorisés dans Microsoft 365.

Authentification composite

Les résultats des vérifications d’authentification implicites de Microsoft 365 sont combinés et stockés dans une valeur unique nommée authentification composite ou compauth abrégée. La valeur compauth est marquée dans l’en-tête Authentication-Results, à l’intérieur des en-têtes de message. L’en-tête Authentication-Results utilise la syntaxe suivante :

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Ces valeurs sont expliquées dans En-tête de message d’authentification-résultats.

Les administrateurs et les utilisateurs peuvent examiner les en-têtes de message pour découvrir comment Microsoft 365 a identifié l’expéditeur en tant qu’expéditeur usurpé suspect ou légitime.

Conseil

Il est important de comprendre qu’un échec d’authentification composite n’entraîne pas directement le blocage d’un message. Notre système utilise une stratégie d’évaluation holistique qui tient compte de la nature suspecte globale d’un message, ainsi que des résultats d’authentification composites. Cette méthode est conçue pour atténuer le risque de blocage incorrect des e-mails légitimes provenant de domaines qui peuvent ne pas respecter strictement les protocoles d’authentification de messagerie. Cette approche équilibrée permet de distinguer les e-mails réellement malveillants des expéditeurs de messages qui ne respectent tout simplement pas les pratiques d’authentification de messagerie standard.

Les exemples suivants se concentrent sur les résultats de l’authentification par e-mail uniquement (la valeur et la compauth raison). D’autres technologies de protection Microsoft 365 peuvent identifier les messages qui passent l’authentification par e-mail comme usurpés, ou identifier les messages qui échouent à l’authentification par e-mail comme légitimes.

  • Scénario : le domaine dans l’enregistrement SPF ou la signature DKIM ne correspond pas au domaine dans l’adresse De.

  • Résultat : le message peut échouer à l’authentification composite. Malgré l’échec de l’authentification composite, le message peut toujours être autorisé si d’autres évaluations n’indiquent pas une nature suspecte :

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

  • Scénario : le domaine fabrikam.com n’a pas d’enregistrements SPF, DKIM ou DMARC.

  • Résultat : Les messages provenant d’expéditeurs dans le domaine fabrikam.com peuvent échouer à l’authentification composite :

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

  • Scénario : le domaine fabrikam.com a un enregistrement SPF et aucun enregistrement DKIM. Les domaines dans les adresses MAIL FROM et From correspondent.

  • Résultat : le message peut passer l’authentification composite, car le domaine qui a passé SPF correspond au domaine dans l’adresse De :

    Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Scénario : le domaine fabrikam.com a un enregistrement DKIM sans enregistrement SPF. Le domaine auquel DKIM a signé le message correspond au domaine dans l’adresse De.

  • Résultat : le message peut passer l’authentification composite, car le domaine dans la signature DKIM correspond au domaine dans l’adresse De :

    Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

  • Scénario : le domaine dans l’enregistrement SPF ou la signature DKIM ne correspond pas au domaine dans l’adresse De.

  • Résultat : le message peut échouer à l’authentification composite :

    Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

Comment éviter les échecs d’authentification par e-mail lors de l’envoi de messages à Microsoft 365

Conseil

Les clients Microsoft 365 peuvent utiliser les méthodes suivantes pour autoriser les messages d’expéditeurs identifiés comme des échecs d’usurpation ou d’authentification :

  • Configurer les enregistrements SPF, DKIM et DMARC pour vos domaines : utilisez les informations de configuration fournies par votre bureau d’enregistrement de domaines ou votre service d’hébergement DNS. Il existe également des sociétés tierces dédiées à la configuration des enregistrements d’authentification par e-mail.

    De nombreuses entreprises ne publient pas d’enregistrements SPF, car elles ne connaissent pas toutes les sources d’e-mail pour les messages dans leur domaine.

    1. Commencez par publier un enregistrement SPF qui contient toutes les sources de courrier électronique que vous connaissez (en particulier l’emplacement du trafic de votre entreprise), puis utilisez la valeur de règle d’application « échec logiciel » (~all). Par exemple :

      fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ~all"

      Si vous créez cet enregistrement SPF, Microsoft 365 traite les e-mails entrants de votre infrastructure d’entreprise comme authentifiés, mais les e-mails provenant de sources non identifiées peuvent toujours être marqués comme usurpation en cas d’échec de l’authentification composite. Toutefois, ce comportement est toujours une amélioration par rapport à tous les e-mails provenant d’expéditeurs dans le domaine marqués comme usurpation par Microsoft 365. En règle générale, le système de messagerie de destination accepte les messages des expéditeurs du domaine provenant de sources non identifiées lorsque SPF est configuré avec une règle d’application de l’échec logiciel.

    2. Découvrez et incluez d’autres sources de courrier pour vos messages. Par exemple :

      • Serveurs de messagerie électronique locaux.
      • Courrier électronique envoyé à partir d’un fournisseur Software as-a-service (Logiciel en tant que service).
      • Courrier électronique envoyé à partir d’un service d’hébergement Cloud (Microsoft Azure, GoDaddy, Rackspace, services Web Amazon, etc.).

      Une fois que vous avez identifié toutes les sources de messagerie pour votre domaine, vous pouvez mettre à jour votre enregistrement SPF pour utiliser la valeur de règle d’application « échec dur » (-all).

    3. Configurez DKIM pour signer numériquement les messages.

    4. Configurez DMARC pour valider que les domaines dans les adresses MAIL FROM et From correspondent, pour spécifier ce qu’il faut faire avec les messages qui échouent aux vérifications DMARC (rejet ou mise en quarantaine) et pour identifier les services de création de rapports pour surveiller les résultats DMARC.

    5. Si vous utilisez des expéditeurs en bloc pour envoyer des e-mails en votre nom, vérifiez que le domaine dans l’adresse De correspond au domaine qui transmet SPF ou DMARC.

  • Vous hébergez l’e-mail d’un domaine ou fournissez une infrastructure d’hébergement qui peut envoyer des e-mails :

    • Vérifiez que vos clients disposent d’une documentation qui explique comment configurer SPF pour leurs domaines.
    • Envisagez la signature DKIM du courrier sortant DKIM, même si le client ne configure pas explicitement DKIM dans son domaine (signez avec un domaine par défaut). Vous pouvez même double-signer l’e-mail avec des signatures DKIM (avec votre domaine d’entreprise et le domaine du client si/quand il est disponible).

    La remise à Microsoft n’est pas garantie, même si vous authentifiez les e-mails provenant de votre plateforme. Toutefois, l’authentification par e-mail garantit que Microsoft ne met pas automatiquement en courrier indésirable les e-mails de vos domaines clients simplement parce qu’il n’est pas authentifié.