Configurer DMARC pour valider le domaine de l’adresse de l’expéditeur pour les expéditeurs cloud

Conseil

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

L’authentification, la création de rapports et la conformité des messages basés sur le domaine (DMARC) est une méthode d’authentification par e-mail pour valider les messages envoyés à partir de votre organization Microsoft 365. Cette validation permet d’empêcher les expéditeurs usurpés qui sont utilisés dans la compromission de la messagerie professionnelle (BEC), les rançongiciels et d’autres attaques par hameçonnage.

Vous activez DMARC pour un domaine en créant un enregistrement TXT dans DNS. La validation DMARC d’un e-mail implique les éléments suivants :

• Vérifiez que les domaines dans les adresses MAIL FROM et FROM s’alignent : SPF et DKIM n’ont pas besoin des domaines dans les adresses e-mail suivantes pour « aligner » (correspondance) :

  • L’adresse MAIL FROM : L’adresse e-mail utilisée lors de la transmission du message entre les serveurs de courrier SMTP. Cette adresse est également appelée 5321.MailFrom adresse, expéditeur P1 ou expéditeur d’enveloppe.
  • Adresse de départ : adresse e-mail dans le champ d’en-tête De affiché en tant qu’expéditeur du message dans les clients de messagerie. Cette adresse est également appelée 5322.From adresse ou expéditeur P2.

  Pour plus d’informations sur la façon dont ces adresses e-mail peuvent être dans différents domaines et utilisées pour l’usurpation d’identité, consultez Pourquoi la messagerie Internet a besoin d’une authentification.

  • DMARC utilise le résultat de SPF pour vérifier les deux conditions suivantes :

    • Le message provient d’une source autorisée pour le domaine utilisé dans l’adresse MAIL FROM (exigence de base de SPF).
    • Les domaines des adresses MAIL FROM et From dans le message sont alignés. Ce résultat implique effectivement que les sources valides du message doivent se trouver dans le domaine de l’adresse From.

  • DMARC utilise le résultat de DKIM pour vérifier que le domaine qui a signé le message (la valeur d= dans un champ d’en-tête DKIM-Signature validé par la valeur du sélecteur s= ) s’aligne sur le domaine dans l’adresse De.

  Un message passe le contrôle DMARC si l’une ou les deux des vérifications SPF ou DKIM décrites réussissent. Un message ne satisfait pas à la validation DMARC si les vérifications SPF et DKIM décrites échouent toutes deux.

• Stratégie DMARC : spécifie ce qu’il faut faire avec les messages qui échouent à DMARC (rejet, mise en quarantaine ou aucune instruction).

• Rapports DMARC : spécifie où envoyer les rapports :

  • Rapports agrégés (résumé périodique des résultats positifs et négatifs du DMARC).
  • Rapports d’investigation (également appelés rapports d’échec ; résultats d’échec DMARC presque immédiats similaires à un rapport de non-remise ou à un message de rebond).

Avant de commencer, voici ce que vous devez savoir sur DMARC dans Microsoft 365 en fonction de votre domaine de messagerie :

• Si vous utilisez uniquement le domaine MOERA (Microsoft Online Email Routing Address) pour la messagerie (par exemple, contoso.onmicrosoft.com) : bien que SPF et DKIM soient déjà configurés pour votre domaine *.onmicrosoft.com, vous devez créer l’enregistrement TXT DMARC pour le domaine *.onmicrosoft.com dans le Centre d’administration Microsoft 365. Pour obtenir des instructions, consultez Utiliser le Microsoft 365 admin center pour ajouter des enregistrements TXT DMARC pour les domaines *.onmicrosoft.com dans Microsoft 365. Pour plus d’informations sur les domaines *.onmicrosoft.com, consultez Pourquoi ai-je un domaine « onmicrosoft.com » ?.

• Si vous utilisez un ou plusieurs domaines personnalisés pour la messagerie (par exemple, contoso.com) : si ce n’est déjà fait, vous devez configurer SPF pour tous les domaines et sous-domaines personnalisés que vous utilisez pour la messagerie. Vous devez également configurer la signature DKIM à l’aide du domaine personnalisé ou d’un sous-domaine afin que le domaine utilisé pour signer le message corresponde au domaine de l’adresse d’expéditeur. Pour obtenir des instructions, consultez les articles suivants :

  • Configurer SPF pour identifier les sources de courrier valides pour vos domaines cloud personnalisés
  • Configurer DKIM pour signer le courrier à partir de votre domaine cloud

  Après cela, vous devez également configurer les enregistrements TXT DMARC pour vos domaines personnalisés, comme décrit dans cet article. Vous avez également les considérations suivantes :

  • Sous-domaines :

    • Pour les services de messagerie qui ne sont pas sous votre contrôle direct (par exemple, les services de messagerie en bloc), utilisez un sous-domaine (par exemple, marketing.contoso.com) au lieu de votre domaine de messagerie principal (par exemple, contoso.com). Vous ne souhaitez pas que les problèmes liés au courrier envoyé à partir de ces services de messagerie affectent la réputation des messages envoyés par les utilisateurs de votre domaine de messagerie principal. Pour plus d’informations sur l’ajout de sous-domaines, consultez Puis-je ajouter des sous-domaines personnalisés ou plusieurs domaines à Microsoft 365 ?.
    • Contrairement à SPF et DKIM, l’enregistrement TXT DMARC pour un domaine couvre automatiquement tous les sous-domaines (y compris les sous-domaines inexistants) qui n’ont pas leur propre enregistrement TXT DMARC. En d’autres termes, vous pouvez interrompre l’héritage de DMARC sur un sous-domaine en créant un enregistrement TXT DMARC dans ce sous-domaine. Toutefois, chaque sous-domaine nécessite un enregistrement SPF et DKIM pour DMARC.

  • Si vous possédez des domaines inscrits mais inutilisés : si vous possédez des domaines inscrits qui ne sont pas utilisés pour la messagerie ou quoi que ce soit (également appelés domaines parqués), configurez les enregistrements TXT DMARC dans ces domaines pour spécifier qu’aucun e-mail ne doit jamais provenir de ces domaines. Cette directive inclut le domaine *.onmicrosoft.com si vous ne l’utilisez pas pour la messagerie.

• Les vérifications DMARC pour les messages entrants peuvent nécessiter de l’aide : si vous utilisez un service de messagerie qui modifie les messages en transit avant leur remise dans Microsoft 365, vous pourrez peut-être identifier le service en tant que scellant ARC approuvé. Les scelleurs ARC approuvés empêchent les messages modifiés d’échouer automatiquement aux vérifications DMARC. Pour plus d’informations, consultez Étapes suivantes.

Le reste de cet article traite de la création d’enregistrements TXT DMARC, du déploiement progressif pour les domaines personnalisés et de la gestion DMARC entrante dans Microsoft 365.

Conseil

Pour créer l’enregistrement TXT DMARC pour votre domaine *.onmicrosoft.com dans le Microsoft 365 admin center, consultez Utiliser le Microsoft 365 admin center pour ajouter des enregistrements TXT DMARC pour les domaines *.onmicrosoft.com dans Microsoft 365.

Il n’existe aucun portail d’administration ou applet de commande PowerShell dans Microsoft 365 pour vous permettre de gérer les enregistrements TXT DMARC dans vos domaines personnalisés . Au lieu de cela, vous créez l’enregistrement TXT DMARC auprès de votre bureau d’enregistrement de domaines ou du service d’hébergement DNS (souvent la même société).

Des instructions sont fournies pour créer l’enregistrement TXT de preuve de propriété de domaine pour Microsoft 365 dans de nombreux bureaux d’enregistrement de domaines. Vous pouvez utiliser ces instructions comme point de départ pour créer des enregistrements TXT DMARC. Pour plus d’informations, consultez Ajouter des enregistrements DNS pour connecter votre domaine.

Si vous n’êtes pas familiarisé avec la configuration DNS, contactez votre bureau d’enregistrement de domaines et demandez de l’aide.

Syntaxe des enregistrements TXT DMARC

Les enregistrements TXT DMARC sont décrits de manière exhaustive dans RFC 7489.

La syntaxe de base de l’enregistrement TXT DMARC pour un domaine dans Microsoft 365 est la suivante :

Nom d’hôte : _dmarc
Valeur TXT : v=DMARC1; <DMARC policy>; <Percentage of DMARC failed mail subject to DMARC policy>; <DMARC reports>

ou

Nom d’hôte : _dmarc
Valeur TXT : v=DMARC1; p=<reject | quarantine | none>; pct=<0-100>; rua=mailto:<DMARCAggregateReportURI>; ruf=mailto:<DMARCForensicReportURI>

Par exemple :

Nom d’hôte : _dmarc
Valeur TXT : v=DMARC1; p=reject; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com

• La valeur _dmarc du nom d’hôte est obligatoire.

• v=DMARC1; identifie l’enregistrement TXT en tant qu’enregistrement TXT DMARC.

• Stratégie DMARC : indique au système de messagerie de destination ce qu’il faut faire avec les messages qui échouent DMARC (rejeter, mettre en quarantaine ou aucune action) :

  • p=reject: les messages doivent être rejetés. Ce qui arrive réellement au message dépend du système de messagerie de destination, mais les messages sont généralement ignorés.
  • p=quarantine: les messages doivent être acceptés, mais marqués. Ce qui arrive réellement au message dépend du système de messagerie de destination. Par exemple, le message peut être mis en quarantaine en tant que courrier indésirable, remis au dossier Email indésirable ou remis à la boîte de réception avec un identificateur ajouté à l’objet ou au corps du message.
  • p=none: aucune action suggérée pour les messages qui échouent à DMARC. Ce qui arrive au message dépend des fonctionnalités de protection des e-mails dans le système de messagerie de destination. Vous utilisez cette valeur pour tester et paramétrer la stratégie DMARC.

  Conseil

  Les messages sortants provenant de domaines dans Microsoft 365 qui échouent aux vérifications DMARC par le service de messagerie de destination sont acheminés via le pool de remise à haut risque pour les messages sortants si la stratégie DMARC pour le domaine est p=reject ou p=quarantine. Il n’existe aucune substitution pour ce comportement.

• Pourcentage de messages DMARC ayant échoué soumis à la stratégie DMARC : indique au système de messagerie de destination le nombre de messages qui échouent (pourcentage) auxquels la stratégie DMARC est appliquée. Par exemple, pct=100 signifie que la stratégie DMARC est appliquée à tous les messages qui échouent aux vérifications DMARC. Vous utilisez des valeurs inférieures à 100 pour le test et le réglage de la stratégie DMARC. Si vous n’utilisez pct=pas , la valeur par défaut est pct=100.

• Rapports DMARC :

  • URI du rapport d’agrégation DMARC : la rua=mailto: valeur identifie où envoyer le rapport d’agrégation DMARC. Le rapport d’agrégation a les propriétés suivantes :

    • Les messages électroniques qui contiennent le rapport d’agrégation sont généralement envoyés une fois par jour (le rapport contient les résultats DMARC du jour précédent). La ligne Objet contient le domaine de destination qui a envoyé le rapport (Submitter) et le domaine source pour les résultats DMARC (Domaine de rapport).
    • Les données DMARC se trouve dans une pièce jointe d’e-mail XML qui est probablement compressée par GZIP. Le schéma XML est défini à l’annexe C de la RFC 7489. Le rapport contient les informations suivantes :
      • Adresses IP des serveurs ou services qui envoient des messages à l’aide de votre domaine.
      • Indique si les serveurs ou les services réussissent ou échouent à l’authentification DMARC.
      • Actions effectuées par DMARC sur les messages qui échouent à l’authentification DMARC (en fonction de la stratégie DMARC).

    Conseil

    Les informations contenues dans le rapport d’agrégation peuvent être vastes et difficiles à analyser. Pour mieux comprendre les données, vous pouvez utiliser les options suivantes pour la création de rapports DMARC :

    • Créez une automatisation à l’aide de PowerShell ou Microsoft Power BI.
    • Utilisez un service externe. Pour obtenir la liste des services, recherchez DMARC dans le catalogue MISA (Association de sécurité intelligente de Microsoft) à l’adresse https://www.microsoft.com/misapartnercatalog. Les services de création de rapports DMARC décrivent toutes les valeurs personnalisées requises dans l’enregistrement TXT DMARC.

  • URI du rapport d’investigation DMARC : la ruf=mailto: valeur identifie où envoyer le rapport DMARC Forensic (également appelé rapport d’échec DMARC). Le rapport est généré et envoyé immédiatement après une défaillance DMARC, comme un rapport de non-remise (également appelé notification d’échec de remise ou message de rebond).

  Conseil

  Vous devez régulièrement examiner les rapports agrégés DMARC pour surveiller la provenance des e-mails envoyés depuis vos domaines et vérifier l’absence d’échecs DMARC non intentionnels (faux positifs).

  Les systèmes de messagerie de destination individuels sont chargés de vous renvoyer les rapports DMARC. La quantité et la variété des rapports DMARC varient de la même façon que le volume et la variété du courrier envoyé à partir de votre organization varient. Par exemple, attendez-vous à un volume de courrier inférieur pendant les jours fériés et à un volume de courrier plus élevé pendant les événements de l’organisation. Il est préférable de désigner des personnes spécifiques pour surveiller les rapports DMARC et d’utiliser une boîte aux lettres ou un groupe Microsoft 365 spécifique pour recevoir les rapports DMARC (ne pas remettre les rapports à la boîte aux lettres d’un utilisateur).

Pour plus d’informations sur DMARC, utilisez les ressources suivantes :

• La série de formations DMARC de M³AAWG (Messaging, Malware, Mobile Anti-Abuse Working Group).
• Informations sur DMARC.org.

Utilisez la Centre d’administration Microsoft 365 pour ajouter des enregistrements TXT DMARC pour les domaines *.onmicrosoft.com dans Microsoft 365

Procédez comme suit pour ajouter un enregistrement TXT DMARC pour votre domaine *.onmicrosoft.com dans le Microsoft 365 admin center.

1. Dans le Centre d’administration Microsoft 365 dans https://admin.microsoft.com, sélectionnez Afficher tout>, puis Paramètres>Domaines. Ou, pour accéder directement à la page Domaines , utilisez https://admin.microsoft.com/Adminportal/Home#/Domains.

2. Dans la page Domaines, sélectionnez le domaine *.onmicrosoft.com dans la liste en cliquant n’importe où dans la ligne autre que la zone case activée en regard du nom de domaine.

3. Dans la page des détails du domaine qui s’ouvre, sélectionnez l’onglet Enregistrements DNS .

4. Sous l’onglet Enregistrements DNS , sélectionnez Ajouter un enregistrement.

5. Dans le menu volant Ajouter un enregistrement DNS personnalisé qui s’ouvre, configurez les paramètres suivants :

   • Type : vérifiez que TXT (Texte) est sélectionné.

   • Nom TXT : entrez _dmarc.

   • Valeur TXT : entrez v=DMARC1; p=reject.

     Conseil

     Pour spécifier des destinations pour les rapports DMARC Aggregate et DMARC Forensic, utilisez la syntaxe v=DMARC1; p=reject; rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>. Par exemple : v=DMARC1; p=reject; rua=mailto:rua@contoso.onmicrosoft.com; ruf=mailto:ruf@contoso.onmicrosoft.com.

     Les fournisseurs de solutions de reporting DMARC dans le catalogue MISA à l’adresse https://www.microsoft.com/misapartnercatalog permettent de visualiser et d’interpréter plus facilement les résultats DMARC.

   • TTL : vérifiez que 1 heure est sélectionnée.

   Lorsque vous avez terminé le menu volant Ajouter un enregistrement DNS personnalisé , sélectionnez Enregistrer.

Configurer DMARC pour les domaines personnalisés actifs dans Microsoft 365

Conseil

Avant de configurer DMARC pour les domaines personnalisés ou les sous-domaines, vous devez créer des enregistrements TXT SPF et configurer la signature DKIM pour tous les domaines et sous-domaines personnalisés que vous utilisez pour envoyer des e-mails dans Microsoft 365.

Une approche progressive de la configuration de DMARC pour vos domaines Microsoft 365 est recommandée. L’objectif est d’accéder à une p=reject stratégie DMARC pour tous vos domaines et sous-domaines personnalisés, mais vous devez tester et vérifier en cours de route pour empêcher les systèmes de messagerie de destination de rejeter les messages de qualité en raison de défaillances DMARC involontaires.

Votre plan de déploiement DMARC doit suivre les étapes suivantes. Commencez par un domaine ou un sous-domaine avec un faible volume de courrier et/ou moins de sources de courrier potentielles (moins de chances que les messages légitimes provenant de sources inconnues soient bloqués) :

1. Commencez par une stratégie DMARC de p=none et surveillez les résultats pour le domaine. Par exemple :

   Enregistrement TXT DMARC pour marketing.contoso.com :

   Nom d’hôte : _dmarc
   Valeur TXT : v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   Les rapports DMARC Aggregate et DMARC Forensic fournissent les numéros et les sources des messages qui réussissent et échouent aux vérifications DMARC. Vous pouvez voir quelle partie de votre trafic de courrier légitime est ou n’est pas couverte par DMARC, et résoudre les problèmes. Vous pouvez également voir le nombre de messages frauduleux envoyés et d’où ils sont envoyés.

2. Augmentez la stratégie DMARC à p=quarantine et surveillez les résultats pour le domaine.

   Après avoir passé suffisamment de temps à surveiller les effets de p=none, vous pouvez augmenter la stratégie DMARC sur p=quarantine pour le domaine. Par exemple :

   Enregistrement TXT DMARC pour marketing.contoso.com :

   Nom d’hôte : _dmarc
   Valeur TXT : v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   Vous pouvez également utiliser la pct= valeur pour affecter progressivement davantage de messages et vérifier les résultats. Par exemple, vous pouvez vous déplacer selon les incréments suivants :

   • pct=10
   • pct=25
   • pct=50
   • pct=75
   • pct=100

3. Augmentez la stratégie DMARC à p=reject et surveillez les résultats pour le domaine.

   Après avoir passé suffisamment de temps à surveiller les effets de p=quarantine, vous pouvez augmenter la stratégie DMARC sur p=reject pour le domaine. Par exemple :

   Enregistrement TXT DMARC pour marketing.contoso.com :

   Nom d’hôte : _dmarc
   Valeur TXT : v=DMARC1; p=reject; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   Vous pouvez également utiliser la pct= valeur pour affecter progressivement davantage de messages et vérifier les résultats.

4. Répétez les trois étapes précédentes pour les autres sous-domaines, par ordre croissant de volume et/ou de complexité, en gardant le domaine parent pour la fin.

   Conseil

   Bloquer les e-mails légitimes dans un volume important est inacceptable pour les utilisateurs, mais il est presque inévitable que vous obteniez des faux positifs. Traitez lentement et méthodiquement les problèmes qui sont révélés dans les rapports DMARC. Les fournisseurs d’outils de création de rapports DMARC dans le catalogue MISA à l’adresse https://www.microsoft.com/misapartnercatalog facilitent la consultation et l’interprétation des résultats DMARC.

5. Les sous-domaines héritent des paramètres d’enregistrement TXT DMARC du domaine parent, que vous pouvez remplacer par un enregistrement TXT DMARC distinct dans le sous-domaine. Lorsque vous avez terminé de configurer DMARC dans un domaine et tous les sous-domaines, et que les paramètres DMARC sont identiques pour le domaine parent et tous les sous-domaines, vous pouvez éliminer les enregistrements TXT DMARC dans les sous-domaines et vous appuyer sur l’enregistrement TXT DMARC unique dans le domaine parent.

Enregistrements TXT DMARC pour les domaines parqués dans Microsoft 365

Conseil

L’enregistrement TXT SPF recommandé pour les domaines parqués qui n’envoient pas de courrier est décrit dans Enregistrements TXT SPF pour les domaines cloud personnalisés. Comme décrit dans Configurer DKIM pour signer le courrier à partir de votre domaine cloud, les enregistrements CNAME DKIM ne sont pas recommandés pour les domaines parqués.

1. Si vous avez inscrit des domaines dont personne sur Internet ne doit s’attendre à recevoir des messages, créez l’enregistrement TXT DMARC suivant auprès du bureau d’enregistrement de domaines pour le domaine :

   Nom d’hôte : _dmarc
   Valeur TXT : v=DMARC1; p=reject;

   • La pct= valeur n’est pas incluse, car la valeur par défaut est pct=100.
   • Les rua=mailto: valeurs et ruf=mailto: ne sont sans doute pas nécessaires dans ce scénario, car aucun courrier valide ne doit jamais provenir d’expéditeurs dans le domaine.

2. Si vous n’utilisez pas le domaine *.onmicrosoft.com pour envoyer des messages, vous devez également ajouter l’enregistrement TXT DMARC pour votre domaine *.onmicrosoft.com.

DMARC pour le courrier entrant dans Microsoft 365

Les fonctionnalités et comportements suivants influencent la façon dont Microsoft 365 évalue DMARC pour les messages entrants et indique si les rapports DMARC sont envoyés.

• Les fonctionnalités de sécurité intégrées suivantes pour toutes les boîtes aux lettres cloud affectent les vérifications DMARC sur les messages entrants :

  • Indique si la fonctionnalité de détection de l’usurpation est activée ou désactivée dans la stratégie anti-hameçonnage qui a vérifié le message. La désactivation de la détection de l’usurpation désactive la protection implicite contre l’usurpation uniquement lors des contrôles d’authentification composite.
  • Indique si le paramètre Respecter l’enregistrement DMARC lorsque le message est détecté comme usurpation d’identité est activé ou désactivé dans la stratégie anti-hameçonnage qui a vérifié le message, et les actions spécifiées basées sur la stratégie DMARC du domaine source (p=quarantineou p=reject dans l’enregistrement TXT DMARC).

  Pour plus d'informations, consultez Protection contre l'usurpation d'identité et politiques DMARC de l'expéditeur.

  Pour voir les valeurs par défaut de ces paramètres dans les stratégies anti-hameçonnage, consultez les valeurs des paramètres dans le tableau à Paramètres de stratégie anti-hameçonnage pour toutes les boîtes aux lettres cloud.

• Microsoft 365 n’envoie pas de rapports d’investigation DMARC (également appelés rapports d’échec DMARC), même s’il existe une adresse valide ruf=mailto: dans l’enregistrement TXT DMARC du domaine source.

• Microsoft 365 envoie des rapports d’agrégation DMARC à tous les domaines avec une adresse valide rua=mailto: dans les enregistrements TXT DMARC, à condition que l’enregistrement MX du domaine Microsoft 365 pointe directement vers Microsoft 365.

  Si vous acheminez le courrier Internet via un service ou un appareil non-Microsoft avant la remise à Microsoft 365 (l’enregistrement MX pointe ailleurs que Microsoft 365), les rapports agrégés DMARC ne sont pas envoyés. Cette limitation inclut les scénarios hybrides où le courrier est remis à l’environnement local avant d’être routé vers Microsoft 365 à l’aide d’un connecteur.

  Conseil

  Lorsqu’un service ou un appareil non-Microsoft se trouve devant le courrier entrant dans Microsoft 365, le filtrage amélioré pour les connecteurs (également appelé skip listing) identifie correctement la source des messages Internet pour SPF, DKIM (si le service modifie les messages) et la validation DMARC.

Résolution des problèmes DMARC

Pour obtenir un tableau de référence rapide des erreurs, causes et correctifs DMARC, consultez Résoudre les problèmes d’authentification par e-mail dans Microsoft 365.

Cette section vous aide à diagnostiquer et à résoudre les défaillances DMARC courantes, à comprendre comment Microsoft 365 agit sur différentes stratégies DMARC et à interpréter les rapports d’agrégation et d’investigation DMARC.

Diagnostic de l’échec d’alignement

Comme décrit dans Configurer DMARC pour valider le domaine d’adresse De pour les expéditeurs cloud, un message transmet DMARC si au moins une vérification d’alignement réussit (SPF ou DKIM). Un message échoue au format DMARC uniquement si les deux vérifications d’alignement échouent.

Modes d’alignement

Les aspf balises (SPF) et adkim (DKIM) dans l’enregistrement TXT DMARC contrôlent dans quelle mesure le domaine From doit correspondre au domaine authentifié. Les deux sont facultatifs et sont par défaut r (assouplis), mais s (strict) est également disponible. L’exemple suivant montre un enregistrement TXT DMARC qui utilise un alignement SPF strict (aspf=s) et un alignement DKIM détendu (adkim=r) :

Hostname: _dmarc
TXT value: v=DMARC1; p=reject; aspf=s; adkim=r; pct=100; rua=mailto:dmarc@contoso.com

• Relaxed (r, valeur par défaut) : les domaines organisationnels (domaines racines) doivent correspondre. Les sous-domaines sont autorisés.
• Strict (s) : les FQDN doivent correspondre exactement. Aucune correspondance de sous-domaine.

Remarque

Les aspf balises et adkim sont indépendantes. Vous pouvez utiliser différents modes pour chacun, comme indiqué dans l’exemple. Un message réussit la validation DMARC si soit l’une des vérifications d’alignement réussit, de sorte qu’un échec en mode strict pour l’une des vérifications n’a pas d’importance si l’autre vérification réussit avec un alignement en mode relâché.

Exemples :

Adresse de l’émetteur	adresse MAIL FROM / DKIM-Signature d=	Détendu (r)	Strict (s)
user@contoso.com	contoso.com	✅ Réussi	✅ Réussi
user@contoso.com	bounces.contoso.com	✅ Réussi	❌ Échouer
user@marketing.contoso.com	contoso.com	✅ Réussi	❌ Échouer
user@contoso.com	contoso.onmicrosoft.com	❌ Échouer	❌ Échouer
user@contoso.com	adatum.net	❌ Échouer	❌ Échouer

Scénarios courants d’échec d’alignement

Le tableau suivant répertorie les scénarios courants d’échec d’alignement DMARC, leurs symptômes, leurs causes racines et les correctifs recommandés.

Scénario	Symptôme	Cause racine	Résolution
Envois de service non-Microsoft en votre nom	SPF passe pour adatum.com mais DMARC échoue	MAIL FROM utilise le domaine du service (par exemple, bounce.adatum.com) et aucune signature DKIM avec votre domaine	Configurez la signature DKIM avec votre domaine au niveau du service , ou remplacez MAIL FROM par votre domaine/sous-domaine
Transfert automatique dans Microsoft 365	DMARC échoue à la destination	Le transfert modifie l’expéditeur de l’enveloppe ; la signature DKIM risque d’être invalidée	Utilisez des scelleurs ARC de confiance au niveau de la destination, ou utilisez DKIM (résiste au transfert si le corps du message n’est pas modifié)
Le sous-domaine envoie avec un alignement strict	aspf=s provoque des échecs pour les expéditeurs de sous-domaine	MAIL FROM est sub.contoso.com , mais From est contoso.com	Passez à aspf=r (assoupli), ou assurez-vous que l’adresse d’expéditeur correspond au sous-domaine
Incompatibilité de domaine de signature DKIM	DKIM réussit, mais DMARC échoue toujours	La valeur DKIM d= (par exemple, adatum.com) ne s’aligne pas sur le domaine From (contoso.com)	Configurer la signature DKIM personnalisée au niveau du service à l’aide de votre domaine
Boîte aux lettres ou groupe de distribution partagé	DMARC échoue par intermittence	Répondre ou rediriger les adresses d’enveloppe des modifications	Vérifiez que DKIM est intact ; envisager ARC pour les services intermédiaires

Diagnostiquer les échecs d’alignement à partir des en-têtes de message

Étape 1 : ouvrez les en-têtes de message et recherchez l’en-tête Authentication-Results à partir de Microsoft 365. L’exemple suivant montre un en-tête Authentication-Results dans lequel SPF et DKIM réussissent chacune individuellement, mais DMARC échoue, car aucun des domaines ne correspond au domaine de l’adresse From :

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

Étape 2 : Identifier l’échec d’alignement :

Vérifier	Champ d’en-tête	Valeur dans l’exemple	S’aligne sur From (contoso.com) ?
Alignement du SPF	smtp.mailfrom=	bounces.adatum.com	❌ Non (domaine d’organisation différent)
Alignement DKIM	header.d=	adatum.com	❌ Non (domaine d’organisation différent)
Résultat DMARC	dmarc=	fail	Les deux vérifications ont échoué

Étape 3 : Déterminez le correctif en répondant aux questions suivantes :

1. Pouvez-vous remplacer l’adresse MAIL FROM par votre domaine (par exemple, bounces.contoso.com au lieu de bounces.adatum.com) ?
   • Oui : configurez la modification MAIL FROM au niveau du service pour corriger l’alignement SPF.
   • Non : utilisez l’alignement DKIM à la place (passez à l’étape 2).
2. Le service peut-il se connecter avec votre domaine (d=contoso.com) ?
   • Oui : configurez la signature DKIM personnalisée au niveau du service.
   • Non : envisagez une stratégie de sous-domaine :
     • Envoyer à partir d’un sous-domaine (par exemple, sub.contoso.com).
     • Publiez un enregistrement DMARC distinct pour ce sous-domaine.
     • Faites signer le service DKIM avec d=sub.contoso.com.

Vérifier l’alignement des messages récents dans PowerShell

Connectez-vous à Exchange Online PowerShell et exécutez les commandes suivantes :

# Get recent messages and check authentication results
$messages = Get-MessageTrace -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -PageSize 100

foreach ($msg in $messages) {
    $details = Get-MessageTraceDetail -MessageTraceId $msg.MessageTraceId -RecipientAddress $msg.RecipientAddress
    $authEvent = $details | Where-Object { $_.Event -eq "Receive" }
    if ($authEvent.Detail -match "dmarc=fail") {
        Write-Output "DMARC FAIL: From=$($msg.SenderAddress), Subject=$($msg.Subject)"
    }
}

Effet de stratégie DMARC sur le comportement de Microsoft 365

Comme décrit dans DMARC pour le courrier entrant, le comportement de Microsoft 365 dépend du paramètre de stratégie Respecter l’enregistrement DMARC . Pour plus de détails, consultez Protection contre l'usurpation d'identité et politiques DMARC de l'expéditeur.

Le résumé suivant montre le comportement général des messages entrants qui échouent à DMARC lorsque la stratégie d’enregistrement Honor DMARC est Activée (recommandé) :

Stratégie DMARC de l’expéditeur	Disposition des messages	Authentication-Results	CompAuth
p=none	Aucune action DMARC spécifique. D’autres filtrages s’appliquent toujours.	dmarc=fail action=none	Basé sur l’authentification composite (SPF, DKIM, intelligence contre l’usurpation d’identité)
p=quarantine	Dossier de Email indésirables (configurable pour mettre en quarantaine)	dmarc=fail action=quarantine	compauth=fail reason=100
p=reject	Rejeté pendant SMTP (550 5.7.1)	dmarc=fail action=oreject	compauth=fail reason=100

Prudence

Faites attention lorsque vous remplacez p=reject pour des expéditeurs légitimes. Si votre organization reçoit légitimement des messages d’un expéditeur dont le DMARC échoue (par exemple, courrier transféré, listes de diffusion), utilisez l’une des approches suivantes :

• Configurez l’expéditeur en tant que scelleur ARC de confiance (de préférence).
• Créez une règle de flux de courrier avec des conditions spécifiques (adresse IP de l’expéditeur + domaine de l’expéditeur) pour ignorer le filtrage du courrier indésirable.
• Ajoutez une entrée d’autorisation dans la liste Autoriser/Bloquer du locataire (temporaire, expire au bout de 30 jours).

Valeurs d’action DMARC dans Authentication-Results

Dans l’en-tête Authentication-Results, vous pouvez voir les valeurs d’action DMARC suivantes :

Valeur de l’action	Signification
action=none	L’expéditeur a publié p=none; aucune action n’a été effectuée
action=quarantine	Expéditeur publié p=quarantine; message mis en quarantaine ou indésirable
action=oreject	Expéditeur publié p=reject; message rejeté (« o » = origine)
action=pct.quarantine	L’expéditeur a publié p=quarantine avec pct= inférieur à 100 ; ce message faisait partie du pourcentage échantillonné
action=pct.reject	L’expéditeur a publié p=reject avec pct= inférieur à 100 ; ce message faisait partie du pourcentage échantillonné

Interprétation du rapport DMARC

Cette section vous aide à interpréter les rapports agrégés et forensiques DMARC que les destinataires envoient à vos adresses rua et ruf. Pour en savoir plus sur la configuration des valeurs rua et ruf dans l’enregistrement TXT DMARC, consultez Syntaxe des enregistrements TXT DMARC.

Rapports d’agrégation

L’exemple suivant montre la structure XML d’un rapport d’agrégation :

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>microsoft.com</org_name>           <!-- Reporting organization -->
    <email>dmarceng@microsoft.com</email>
    <report_id>unique-report-id</report_id>
    <date_range>
      <begin>1700000000</begin>                   <!-- Unix timestamp: start -->
      <end>1700086400</end>                       <!-- Unix timestamp: end -->
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>contoso.com</domain>                  <!-- Your domain -->
    <adkim>r</adkim>                              <!-- DKIM alignment mode -->
    <aspf>r</aspf>                                <!-- SPF alignment mode -->
    <p>reject</p>                                 <!-- Domain policy -->
    <sp>quarantine</sp>                           <!-- Subdomain policy -->
    <pct>100</pct>                                <!-- Percentage -->
  </policy_published>

  <record>
    <row>
      <source_ip>198.51.100.10</source_ip>        <!-- Sending IP -->
      <count>1523</count>                         <!-- Number of messages -->
      <policy_evaluated>
        <disposition>none</disposition>           <!-- What receiver did -->
        <dkim>pass</dkim>                         <!-- DKIM alignment result -->
        <spf>fail</spf>                           <!-- SPF alignment result -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>contoso.com</header_from>      <!-- From address domain -->
      <envelope_from>bounces.adatum.com</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>contoso.com</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>bounces.adatum.com</domain>
        <result>pass</result>                     <!-- SPF passed but... -->
      </spf>
    </auth_results>
  </record>
</feedback>

Lire les rapports agrégés

Utilisez le tableau suivant pour interpréter les champs les plus importants dans un rapport d’agrégation DMARC et déterminer quelle action de dépannage effectuer.

Élément XML	Ce qu’il vous dit	Action de résolution des problèmes
<source_ip>	Adresse IP qui a envoyé les messages	Identifier s’il s’agit d’un expéditeur légitime ou non autorisé
<count>	Nombre de messages provenant de cette source	Nombre élevé d’adresses IP inconnues = usurpation potentielle
<disposition>	Action effectuée par le récepteur (none, quarantine, reject)	Vérifier que le destinataire respecte votre stratégie
<dkim> Sous <policy_evaluated>	Si DKIM est aligné (pas seulement passé)	fail = Le domaine DKIM ne correspond pas au domaine From
<spf> Sous <policy_evaluated>	Si SPF est aligné (pas seulement passé)	fail = Le domaine de MAIL FROM ne correspond pas au domaine du champ From
<domain> Sous <auth_results><spf>	Domaine sur lequel SPF a été vérifié	Si différent du domaine de l’expéditeur = problème d’alignement
<domain> Sous <auth_results><dkim>	Domaine de signature DKIM	Doit correspondre au domaine From pour l’alignement DMARC
<result> Sous <auth_results>	Résultat brut de réussite/échec SPF/DKIM (avant la vérification de l’alignement)	pass + alignement fail = problème d’alignement classique

Conseil

L’enseignement le plus important des rapports agrégés consiste à identifier l’écart entre la réussite de l’authentification et la réussite de l’alignement :

• <auth_results><spf><result>pass</result> + <policy_evaluated><spf>fail</spf> = SPF passé mais les domaines ne sont pas alignés.
• Cette combinaison signifie que l’expéditeur est autorisé (pass SPF), mais qu’il n’est pas correctement configuré pour DMARC (échec de l’alignement).

Modèles et correctifs de rapport d’agrégation courants

Le tableau suivant présente les modèles courants que vous pouvez trouver dans les rapports d’agrégation et les actions dont ils ont généralement besoin.

Modèle dans le rapport	Interprétation	Corriger
Adresse IP connue, authentification SPF=réussie, alignement SPF=échec	Service légitime avec un domaine MAIL FROM incorrect	Configurer le service pour utiliser votre domaine dans MAIL FROM ou configurer la signature DKIM avec votre domaine
IP connue, DKIM auth=pass, alignement DKIM=échec	Le service signe DKIM avec son propre domaine	Configurer un DKIM personnalisé au service avec d=contoso.com
Adresse IP inconnue, volume élevé, tous les échecs	Campagne potentielle d’usurpation d’identité/hameçonnage	Aucune action n’est nécessaire. Votre stratégie DMARC protège les destinataires.
Adresse IP connue (Microsoft 365), SPF aligned=pass	Flux de messagerie Microsoft 365 normal	Sain. Aucune action n’est nécessaire.
Faible volume du service légitime, échec de SPF+DKIM	Service non inclus dans SPF et non signature DKIM	Ajouter un service à l’enregistrement SPF et/ou configurer DKIM
Courriel transféré (adresses IP des listes de diffusion), tout échoue	Le transfert des e-mails rompt SPF ; la modification du corps du message rompt DKIM	Normal pour le courrier transféré. Utilisez ARC ou acceptez certains échecs.

Rapports d’investigation

Comme indiqué dans la section DMARC pour le courrier entrant , Microsoft 365 n’envoie pas de rapports d’investigation. Toutefois, vous pouvez les recevoir d’autres fournisseurs. Le tableau suivant compare les deux types de rapports :

Aspect	Rapports agrégés (rua)	Rapports d’investigation (ruf)
Frequency	Tous les jours (généralement)	En quasi temps réel (à chaque défaillance)
Content	Statistiques récapitulatives par adresse IP source	Détails des messages individuels
Volume	Un rapport par jour par reporter	Un rapport par échec (il peut s’agir d’un volume élevé)
Confidentialité	Adresses IP et nombres uniquement	Peut inclure des en-têtes/corps de message (rédigé)
Support	Largement pris en charge par les récepteurs	Prise en charge limitée (de nombreux destinataires n’envoient pas ruf)
Cas d’utilisation	Analyse des tendances, identification des expéditeurs inconnus	Débogage de défaillances spécifiques, analyse forensique

Remarque

Si vous avez besoin de détails d’échec par message de Microsoft 365, utilisez la trace des messages et l’analyse des en-têtes de message au lieu de rapports d’investigation.

L’exemple suivant montre la structure d’un rapport d’investigation DMARC (format AFRF/RFC 6591) qu’un récepteur envoie à votre ruf adresse lorsqu’un message échoue. Recherchez les champs Feedback-Type, Source-IP et Authentication-Results pour identifier les détails de l’échec :

From: noreply-dmarc-support@fabrikam.com
To: ruf@contoso.com
Subject: Report Domain: contoso.com Submitter: fabrikam.com

Feedback-Type: auth-failure
User-Agent: fabrikam.com/dmarc-reporter
Version: 1
Original-Mail-From: bounces@adatum.com
Arrival-Date: Mon, 15 Jan 2024 10:30:00 -0000
Source-IP: 198.51.100.10
Authentication-Results: fabrikam.com; dmarc=fail (p=reject)
  header.from=contoso.com
Reported-Domain: contoso.com
Original-Envelope-Id: <abc123@mail.adatum.com>

Bonnes pratiques pour les rapports DMARC

Utilisez les meilleures pratiques suivantes pour gérer efficacement les rapports DMARC.

Recommandation	Détails
Utiliser une boîte aux lettres dédiée pour rua	Créez une boîte aux lettres partagée (par exemple, dmarc-reports@contoso.com). N’utilisez pas de boîtes aux lettres utilisateur individuelles.
Utiliser un groupe Microsoft 365	Les groupes offrent une meilleure collaboration et un accès partagé à l’équipe de sécurité
Envisager un service de création de rapports DMARC	DMARC Reporting Services analyse le code XML dans des tableaux de bord. Recherchez DMARC dans le catalogue MISA.
Commencer par rua uniquement	Ajoutez ruf ultérieurement si nécessaire. Les rapports d’investigation peuvent générer un volume élevé.
Surveiller régulièrement	Examiner les rapports agrégés chaque semaine pendant le déploiement initial, puis tous les mois une fois le système stabilisé.
Définir des attentes réalistes	Tous les destinataires n’envoient pas de rapports. La couverture est généralement de 70 à 90 % du volume total de courrier

Rapports inter-domaines

Si votre adresse DMARC rua ou ruf se trouve dans un domaine différent de celui surveillé, le domaine destinataire doit publier un enregistrement TXT DNS autorisant la remise du rapport :

Exemple : DMARC pour contoso.com envoyer des rapports à dmarc@fabrikam.com

Pour autoriser fabrikam.com à recevoir des rapports DMARC pour le compte de contoso.com, l’administrateur de fabrikam.com doit publier l’enregistrement TXT DNS suivant :

Hostname: contoso.com._report._dmarc
Type: TXT
Value: v=DMARC1;

Sans cet enregistrement, les récepteurs ne livrent pas de rapports DMARC à l’adresse externe.

Informations de référence sur la résolution des problèmes DMARC

Le tableau suivant fournit une référence rapide pour les symptômes DMARC courants, leurs causes probables, les étapes de diagnostic et les résolutions.

Symptôme	Cause probable	Étape de diagnostic	Résolution
dmarc=fail mais SPF et DKIM passent tous les deux individuellement	Échec de l’alignement : les domaines ne correspondent pas à From	Vérifier smtp.mailfrom= et header.d= vs header.from= dans Authentication-Results	Configurer SPF/DKIM avec des domaines alignés
dmarc=bestguesspass	Aucun enregistrement DMARC publié pour le domaine From	Interroger _dmarc.domain.com un enregistrement TXT	Microsoft déduit une passe. Publier un enregistrement DMARC explicite.
dmarc=fail action=oreject mais le message a été remis	Respecter le paramètre DMARC désactivé ou autoriser la liste/remplacement en place	Vérifier les paramètres de la stratégie anti-hameçonnage et la liste Autoriser/Bloquer du locataire	Activer le respect de la politique de l’enregistrement DMARC si une application stricte est souhaitée
dmarc=fail pour les messages transférés	Le transfert rompt l’alignement SPF ; les modifications du corps du message rompent la validation DKIM	Vérifier si le message a traversé l’intermédiaire (en-têtes X-MS-Exchange)	Configurer le scellant ARC approuvé pour le service de transfert
dmarc=fail pour l’expéditeur SaaS non-Microsoft	Le service utilise son propre domaine dans MAIL FROM et DKIM d=	Vérifier les rapports agrégés pour l’adresse IP du service	Configurer la signature DKIM personnalisée au niveau du service + aligner MAIL FROM
dmarc=temperror ou dmarc=permerror	Problèmes DNS lors de la récupération de l’enregistrement DMARC (délai d’expiration, erreur de syntaxe)	Valider la syntaxe d’enregistrement DMARC avec nslookup -type=TXT _dmarc.domain.com	Corriger les erreurs de syntaxe DNS ; vérifier qu’un _dmarc seul enregistrement TXT existe
compauth=fail reason=000	Échec de l’authentification composite (échec explicite)	Vérifier tous les résultats d’authentification (SPF, DKIM, DMARC, ARC)	Correction des problèmes SPF/DKIM/DMARC sous-jacents
compauth=fail reason=100	Échec explicite de DMARC avec l’application de la stratégie	La stratégie DMARC de l’expéditeur a provoqué l’échec	Corriger l’alignement dans la source, ou configurer ARC/une dérogation si légitime
Rapports agrégés non reçus	rua adresse inaccessible ou authentification inter-domaines manquante	Vérifier l’existence d’une boîte aux lettres et l’enregistrement d’autorisation DNS pour les domaines externes	Corriger le routage des boîtes aux lettres ; ajouter un domain._report._dmarc enregistrement TXT

Workflow de diagnostic DMARC

Procédez comme suit pour diagnostiquer un message avec dmarc=fail:

1. Identifiez le domaine From : recherchez la header.from= valeur dans l’en-tête Authentication-Results .

2. Vérifier l’alignement SPF : le smtp.mailfrom= domaine correspond-il au header.from= domaine ?

   • Oui (même domaine d’organisation avec aspf=r) : SPF est aligné.
   • Non : l’alignement SPF échoue.
   • SPF a-t-il réussi du tout (spf=pass vs spf=fail) ? Si la valeur est spf=fail, corrigez D’abord SPF en ajoutant l’expéditeur à l’enregistrement SPF.

3. Vérifier l’alignement DKIM : la header.d= valeur du DKIM-Signature correspond-elle au header.from= domaine ?

   • Oui (même domaine d’organisation avec adkim=r) : DKIM est aligné.
   • Non : L’alignement DKIM échoue.
   • DKIM a-t-il réussi du tout (dkim=pass vs dkim=fail) ? Si la valeur est dkim=fail, corrigez DKIM en publiant la clé et en vérifiant la signature.

4. Si les deux alignements échouent, DMARC échoue. Options de résolution :

   • Correction de l’alignement SPF : remplacez l’adresse MAIL FROM par votre domaine.
   • Correction de l’alignement DKIM : signez avec d=contoso.com.
   • Utilisez un sous-domaine : Envoyer à partir de sub.domain.com avec son propre enregistrement DMARC.
   • Si le message est transféré : Configurez un scellant ARC approuvé.

5. Vérifiez l’action de stratégie :

   • p=none: Aucun effet sur la livraison (surveillance uniquement).
   • p=quarantine: le message est envoyé à Junk Email (si la stratégie Honor DMARC est activée).
   • p=reject: le message est rejeté (si la stratégie Honor DMARC est activée). Si le courrier légitime est rejeté, utilisez ARC, une liste d’autorisation ou corrigez l’authentification à la source d’envoi.

Commandes PowerShell utiles pour la résolution des problèmes DMARC

Connectez-vous à Exchange Online PowerShell et utilisez les commandes suivantes pour vérifier vos paramètres DMARC de stratégie anti-hameçonnage, vérifier les enregistrements DNS DMARC et DKIM, passer en revue les échecs DMARC récents et inspecter la configuration ARC :

# Check your organization's anti-phishing policy DMARC settings
Get-AntiPhishPolicy | Format-List Name, HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

# Verify DMARC record for a domain
Resolve-DnsName -Name "_dmarc.contoso.com" -Type TXT | Select-Object -ExpandProperty Strings

# Check DKIM configuration (alignment prerequisite)
Get-DkimSigningConfig | Format-List Domain, Enabled, Selector1CNAME, Selector2CNAME

# Review messages that failed DMARC in the last 24 hours
Get-MailDetailSpamReport -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) |
  Where-Object { $_.MessageTraceId } |
  Select-Object Date, SenderAddress, RecipientAddress, Subject, SpamScore

# Check ARC configuration (for forwarding scenarios)
Get-ArcConfig | Format-List ArcTrustedSealers

# View anti-phishing policy DMARC override actions
Get-AntiPhishPolicy -Identity "Office365 AntiPhish Default" |
  Select-Object HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

Conseil

Lors de la résolution des échecs DMARC pour un expéditeur spécifique :

1. Commencez par l’en-tête Authentication-Results pour identifier le type d’échec.
2. Recoupez ces informations avec vos rapports d’agrégation DMARC pour voir le volume et les adresses IP sources.
3. Utilisez Get-MessageTrace pour rechercher des messages spécifiques et Get-MessageTraceDetail pour examiner les événements de remise.
4. Si l’expéditeur est légitime, collaborez avec lui pour corriger l’alignement SPF/DKIM avant de créer des remplacements.

Étapes suivantes

Pour le courrier entrant dans Microsoft 365, vous devrez peut-être également configurer des scellants ARC approuvés si vous utilisez des services qui modifient les messages en transit avant leur remise à votre organization. Pour plus d’informations, consultez Configurer des scellants ARC approuvés.

Pour diagnostiquer et corriger les échecs d’authentification par e-mail, consultez Résoudre les problèmes d’authentification par e-mail dans Microsoft 365.