Résoudre les problèmes d’authentification par e-mail dans Microsoft 365

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 sur 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 par e-mail et les enregistrements DNS correspondants permettent de protéger votre organisation contre l’usurpation, l’hameçonnage et le courrier indésirable. Pour obtenir une vue d’ensemble de l’authentification par e-mail, consultez Authentification par e-mail dans Microsoft 365. En cas d’échec de l’authentification, les messages légitimes peuvent être mis en quarantaine, rejetés ou routés vers le dossier Courrier indésirable. Utilisez les tableaux de résolution des problèmes de référence rapide pour identifier les symptômes et les causes courants, suivis d’instructions détaillées pour chaque scénario d’échec.

Tables de résolution des problèmes de référence rapide

Utilisez les tableaux des sections suivantes pour identifier rapidement le symptôme, la cause probable et le lien vers les instructions détaillées pertinentes.

Échecs SPF

Pour résoudre les erreurs SPF (Sender Policy Framework), utilisez les informations du tableau suivant :

Symptôme Cause probable Conseils détaillés
La vérification SPF renvoie none (aucun enregistrement n’a été trouvé) Aucun enregistrement TXT SPF n’est publié pour le domaine d’envoi dans DNS. Configurer SPF pour identifier les sources de courrier valides
La vérification SPF renvoie permerror L’enregistrement SPF dépasse la limite de recherche DNS de 10, ou plusieurs enregistrements SPF existent pour le même domaine. Configurer SPF - Résolution des problèmes
La vérification SPF renvoie temperror Une défaillance DNS temporaire s’est produite lors de l’interrogation de l’enregistrement SPF (le serveur DNS faisant autorité était inaccessible ou a expiré). Configurer SPF - Résolution des problèmes
La vérification SPF retourne softfail ou fail L’adresse IP d’envoi n’est pas incluse dans l’enregistrement SPF du domaine. Ce résultat est courant après l’ajout d’un nouveau service de messagerie ou d’un relais non-Microsoft. Configurer SPF pour identifier les sources de courrier valides
SPF est validé, mais l’e-mail est toujours marqué comme indésirable SPF seul n’empêche pas l’usurpation d’identité. DKIM et DMARC sont également nécessaires. L’authentification composite peut toujours échouer. Comment SPF, DKIM et DMARC fonctionnent ensemble
Les messages transférés échouent à la vérification SPF L’adresse IP du serveur de transfert ne figure pas dans l’enregistrement SPF de l’expéditeur d’origine. Ce comportement est normal. Configurer des scellants ARC approuvés

Échecs DKIM

Pour résoudre les erreurs DKIM (DomainKeys Identified Mail), utilisez les informations du tableau suivant :

Symptôme Cause probable Conseils détaillés
dkim=none (aucune signature trouvée) La signature DKIM n’est pas configurée pour le domaine d’envoi, ou le message n’a pas été signé. Configurer DKIM pour signer le courrier à partir de votre domaine
dkim=fail (échec de la vérification de la signature) La clé publique DKIM dans DNS ne correspond pas à la clé privée utilisée pour signer le message, ou l’enregistrement du sélecteur est manquant. Configurer DKIM pour signer le courrier à partir de votre domaine
dkim=fail (le hachage du corps n’a pas été vérifié) Le corps du message a été modifié après la signature (par exemple, par une liste de diffusion, une règle de transport ou un service intermédiaire). Configurer des scellants ARC (Authenticated Received Chain) approuvés
La recherche de clé DKIM expire L’enregistrement TXT DKIM est trop volumineux ou le serveur DNS faisant autorité est lent à répondre, ce qui entraîne des délais d’attente de recherche. Configurer DKIM pour signer le courrier à partir de votre domaine
Le bouton bascule DKIM ne fonctionne pas dans le portail Defender Les enregistrements CNAME (Nom canonique) requis ne sont pas créés auprès du bureau d’enregistrement de domaines, ou la propagation DNS n’est pas terminée. Résoudre les problèmes de configuration DNS DKIM

Échecs de DMARC

Pour résoudre les erreurs DMARC (Domain-based Message Authentication, Reporting, and Conformance), utilisez les informations du tableau suivant :

Symptôme Cause probable Conseils détaillés
dmarc=fail action=quarantine ou dmarc=fail action=oreject SPF et DKIM n’ont pas été validés et n’étaient pas alignés sur le domaine de l’adresse From. La stratégie DMARC de l’expéditeur spécifie la mise en quarantaine ou le rejet. Configurer DMARC pour votre domaine
dmarc=bestguesspass Il n’existe aucun enregistrement DMARC pour le domaine de l’expéditeur. Microsoft 365 a déduit une passe à l’aide de la méthode heuristique. Authentification composite
DMARC échoue en raison d’un mauvais alignement de domaine Le domaine MAIL FROM (expéditeur d’enveloppe) diffère du domaine d’adresse De (en-tête), et SPF ou DKIM ne s’aligne pas sur le domaine De. Comment SPF, DKIM et DMARC fonctionnent ensemble
Courrier transféré légitime rejeté par DMARC Le transfert interrompt l’alignement SPF et, si DKIM échoue également (corps modifié), DMARC échoue. Le scellement ARC n’est pas configuré. Configurer des scellants ARC approuvés
Les rapports DMARC montrent des échecs inattendus Les services non-Microsoft qui envoient au nom de votre domaine ne sont pas inclus dans votre enregistrement SPF ou ne sont pas signés DKIM avec votre domaine. Configurer SPF et configurer DKIM

Échecs d’authentification composite

Pour résoudre les erreurs d’authentification composite (compauth), utilisez les informations du tableau suivant :

Symptôme Cause probable Conseils détaillés
compauth=fail avec raison 000 Échec de l’authentification explicite du message. La vérification DMARC a échoué et la politique DMARC est définie sur p=quarantine ou p=reject. En-tête du message Authentication-Results
compauth=fail avec raison 001 Échec de l’authentification implicite du message. Le domaine d’envoi n’a aucun enregistrement d’authentification par e-mail ou a une stratégie d’échec faible (~all ou ?all). En-tête du message Authentication-Results
compauth=fail avec raison 002 Une paire expéditeur/domaine est explicitement bloquée pour l’envoi d’e-mails usurpés dans l’organisation. Insight d’intelligence contre l’usurpation d’identité
compauth=fail avec raison 010 Le message n’a pas passé les vérifications DMARC alors que la stratégie de l’expéditeur est définie sur « rejeter » ou « quarantaine », et le domaine expéditeur est l’un des domaines acceptés de votre organisation. Paramètres de simulation dans les politiques anti-hameçonnage

NDR pour les échecs d’authentification de messagerie

Utilisez les informations du tableau suivant pour résoudre les problèmes de non-remise des rapports (également appelés NDR ou messages de rebond) liés aux échecs d’authentification par e-mail.

Symptôme Cause probable Conseils détaillés
NDR avec le code d’erreur 550 5.7.23 L’enregistrement SPF du domaine d’envoi est manquant ou mal configuré, ce qui entraîne le rejet du message par le serveur de destination. Correction de l’erreur NDR « 550 5.7.23 »
NDR avec le code d’erreur 5.7.367 Les messages transférés ou relayés à partir de Microsoft 365 sont rejetés, car DKIM/SPF échoue après le relais via une passerelle non-Microsoft. Correction du code d’erreur 5.7.367 dans Exchange Online
NDR avec le code d’erreur 550 5.7.1 Le message a été rejeté comme non autorisé. Les causes courantes incluent un enregistrement SPF incomplet, une configuration de connecteur incorrecte ou les stratégies de sécurité du serveur de destination. Correction de l’erreur NDR « 550 5.7.1 »

Résolution détaillée des problèmes par protocole

Résoudre les problèmes liés à SPF

SPF vérifie que le serveur de messagerie d’envoi est autorisé à envoyer au nom du domaine dans l’adresse MAIL FROM (expéditeur d’enveloppe). Les problèmes courants sont les suivants :

  • Plusieurs enregistrements SPF pour le même domaine : un seul enregistrement TXT SPF est autorisé par domaine ou sous-domaine. Plusieurs enregistrements provoquent un SPF permerror.
  • Dépassement de la limite de 10 recherches DNS : chacun des mécanismes include, a, mx, ptr et redirect compte comme une recherche DNS. Pour réduire les requêtes, aplatissez votre enregistrement SPF ou utilisez les mécanismes ip4/ip6.
  • Expéditeurs autorisés manquants : lorsque vous ajoutez un nouveau service de messagerie (par exemple, une plateforme de gestion de la relation client (CRM) ou un outil marketing), ajoutez son include SPF à votre enregistrement.
  • Durée de vie trop faible : définissez la durée de vie de votre enregistrement TXT SPF sur au moins 3600 secondes (une heure) pour éviter les délais d’expiration de recherche DNS.

Conseil

Utilisez Microsoft Remote Connectivity Analyzer pour valider votre enregistrement SPF.

Pour obtenir des instructions complètes de configuration et de résolution des problèmes, consultez Configurer SPF pour identifier les sources de messagerie valides pour votre domaine Microsoft 365.

Résoudre les problèmes liés à DKIM

DKIM utilise une signature de chiffrement dans l’en-tête du message pour vérifier que le message n’a pas été falsifié lors du transit. Les problèmes courants sont les suivants :

  • Enregistrements CNAME non publiés : après avoir activé DKIM dans le portail Defender, créez deux enregistrements CNAME auprès de votre bureau d’enregistrement de domaines. Pour obtenir des erreurs courantes et des exemples spécifiques au fournisseur, consultez Résoudre les problèmes de configuration DNS DKIM.
  • Échec du hachage du corps après modification : services intermédiaires (par exemple, listes de diffusion ou règles de transport) qui modifient le corps du message après la signature DKIM provoquent l’échec de DKIM. Envisagez de configurer l’intermédiaire en tant que scellant ARC approuvé.
  • Rotation des clés : faites régulièrement pivoter les clés de signature DKIM. Utilisez le cmdlet Rotate-DkimSigningConfig dans Exchange Online PowerShell.

Pour obtenir des instructions d’installation complètes, consultez Configurer DKIM pour signer les messages à partir de votre domaine Microsoft 365.

Résoudre les problèmes liés à DMARC

DMARC s’appuie sur SPF et DKIM pour vérifier l’alignement du domaine avec l’adresse d’expéditeur. Les problèmes courants sont les suivants :

  • Non-alignement du domaine : DMARC exige que SPF ou DKIM soit validé et que le domaine authentifié soit aligné avec le domaine de l’adresse From.
  • Échec de DMARC des services non-Microsoft : ajoutez le service à votre enregistrement SPF ou configurez le service pour signer DKIM avec votre domaine (par défaut). Si ces options ne sont pas possibles, utilisez un sous-domaine pour ce service avec un enregistrement DMARC distinct.
  • Scénarios de transfert : les messages transférés échouent généralement au format DMARC, car le transfert interrompt SPF. Configurez le filtrage amélioré pour les connecteurs ou lesscelleurs ARC approuvés pour conserver les résultats de l’authentification.

Pour obtenir des instructions de configuration complètes, consultez Configurer DMARC pour valider le domaine de l’adresse de l’expéditeur.

Scénarios d’échec combinés

Lorsque plusieurs protocoles d’authentification de messagerie échouent simultanément, la résolution des problèmes nécessite une approche systématique. Utilisez les scénarios suivants pour diagnostiquer et résoudre les échecs combinés.

Échec de SPF et DKIM

Exemple d’en-tête :

Authentication-Results: spf=fail smtp.mailfrom=contoso.com;
 dkim=fail header.d=contoso.com; dmarc=fail action=quarantine;
 compauth=fail reason=000

Analyse : L’authentification SPF et DKIM a échoué, donc DMARC ne peut pas passer (DMARC a besoin d’au moins une passe alignée). Le message est probablement mis en quarantaine ou rejeté.

Étapes de dépannage:

  1. Identifiez l’adresse IP d’envoi dans les en-têtes du message ou en utilisant Get-MessageTrace.
  2. Vérifiez que l’adresse IP d’envoi est incluse dans l’enregistrement SPF du domaine.
  3. Vérifiez que la signature DKIM est activée et que les enregistrements CNAME DNS DKIM existent.
  4. Vérifiez si une passerelle de messagerie modifie les messages (ce qui interrompt DKIM) ou envoie à partir d’une adresse IP qui ne figure pas dans l’enregistrement SPF.

Correction de la priorité :

  1. Corrigez D’abord SPF (modification DNS uniquement ; correctif le plus rapide). Consultez Configurer SPF.
  2. Corriger DKIM en deuxième (peut nécessiter des modifications de Microsoft 365 et DNS). Consultez Configurer DKIM.
  3. Vérifiez l’alignement DMARC. Consultez Configurer DMARC.
  4. Si une passerelle est impliquée, implémentez ARC.

SPF réussit mais DMARC échoue en raison de l’alignement

Exemple d’en-tête :

Authentication-Results: spf=pass smtp.mailfrom=service.contoso.com;
 dkim=fail header.d=contoso.com;
 dmarc=fail (SPF not aligned);
 compauth=fail reason=001

Analyse : SPF est validé, mais le domaine SPF n’est pas aligné avec le domaine de l’adresse From. DKIM échoue également. DMARC a besoin d’au moins une passe alignée, donc elle échoue.

Cas courant : scénario de redirection ou de relais où le domaine de l’adresse d’expéditeur de l’enveloppe diffère du domaine de l’adresse From.

Correction: Activer la signature DKIM pour le domaine de l’adresse d’expéditeur. L’alignement DKIM fournit la passe alignée dont DMARC a besoin.

Connectez-vous à Exchange Online PowerShell et exécutez la commande suivante :

Set-DkimSigningConfig -Identity contoso.com -Enabled $true

Messages de modification de passerelle ou de relais

Exemple d’en-tête :

Authentication-Results: spf=pass smtp.mailfrom=gateway.fabrikam.com;
 dkim=fail (body hash did not verify) header.d=contoso.com;
 dmarc=fail (no aligned pass)

Analyse : le message transmis par le biais d’une passerelle ou d’un service de sécurité qui a modifié le corps du message (par exemple, en ajoutant une clause d’exclusion de responsabilité ou une notification d’analyse). La modification a invalidé la signature DKIM. SPF passe pour le domaine de passerelle, mais ne s’aligne pas sur le domaine From.

Correction des options (par ordre de priorité) :

  1. Configurer ARC sur la passerelle (recommandé) : ARC conserve les résultats de l’authentification par le biais de la modification des messages. Consultez Configurer des scellants ARC approuvés.
  2. Configurer la passerelle pour signer DKIM après modification : la passerelle ajoute sa propre signature DKIM valide à votre domaine après toute modification du contenu.
  3. Ajoutez la passerelle au filtrage amélioré pour les connecteurs : conserve l’adresse IP d’envoi d’origine pour l’évaluation de l’authentification. Consultez Filtrage amélioré pour les connecteurs.

Le transfert interrompt l’authentification

Exemple d’en-tête :

Authentication-Results: spf=fail (sender IP is 10.0.1.x)
 smtp.mailfrom=woodgrovebank.com;
 dkim=pass header.d=woodgrovebank.com;
 dmarc=fail (SPF failed, DKIM not aligned)

Analyse : un message transféré échoue à SPF, car l’adresse IP du serveur de transfert ne se trouve pas dans l’enregistrement SPF de l’expéditeur d’origine. DKIM peut passer si le message n’a pas été modifié, mais l’alignement avec le domaine From peut toujours échouer.

Correctif : Configurez des scellants ARC approuvés. Microsoft 365 fait déjà confiance aux sceaux ARC des principaux fournisseurs (par exemple, Google et Yahoo). Si l’authentification échoue toujours une fois qu’ARC est en place, vérifiez les paramètres de votre stratégie anti-hameçonnage.

Scénarios réels courants

Envoyer au nom de dans Outlook

Ce que l’utilisateur voit :

From: user@contoso.com on behalf of user@contoso.com

Cause racine : SPF softfail ou fail parce que l’adresse IP d’envoi n’est pas autorisée dans l’enregistrement SPF.

Correctif : ajoutez l’adresse IP ou le service d’envoi à l’enregistrement SPF :

v=spf1 ip4:<sending-IP> include:spf.protection.outlook.com ~all

L’automatisation marketing échoue avec DMARC

Exemple d’en-tête :

Authentication-Results: spf=pass smtp.mailfrom=northwindtraders.com;
 dkim=pass header.d=northwindtraders.com;
 dmarc=fail (no aligned pass) header.from=contoso.com

Cause racine : le service marketing (par exemple, Marketo ou HubSpot) envoie à partir de sa propre infrastructure. SPF et DKIM réussissent tous les deux pour le domaine du service, mais aucun des deux n’est aligné avec le domaine de l’adresse From (contoso.com).

Options de correction :

  1. Configurez le service pour signer DKIM avec votre domaine (par défaut).
  2. Ajoutez l’inclusion SPF du service à l’enregistrement SPF de votre domaine (permet une validation SPF alignée).
  3. Utilisez un sous-domaine pour la messagerie marketing (par exemple, marketing.contoso.com) :
    • Configurez SPF et DKIM pour le sous-domaine au niveau du service.
    • Définissez l’alignement souple dans votre enregistrement DMARC : aspf=r; adkim=r.
    • Ajoutez une stratégie de sous-domaine à DMARC : v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc@contoso.com.

La passerelle de sécurité de messagerie cloud interrompt l’authentification

Exemple d’en-tête :

Authentication-Results: spf=pass smtp.mailfrom=tailspintoys.com;
 dkim=fail (body hash did not verify) header.d=contoso.com;
 dmarc=fail

Cause racine : un service de sécurité de messagerie non-Microsoft (par exemple, Proofpoint ou Mimecast) modifie le message, ce qui interrompt DKIM. Le SPF de la passerelle passe pour son propre domaine, mais ne s’aligne pas sur le domaine From.

Correction des options (par ordre de priorité) :

  1. Configurez la passerelle pour ARC (recommandé ; nécessite une prise en charge par la passerelle).
  2. Configurez le filtrage amélioré pour les connecteurs afin d’ignorer l’adresse IP de la passerelle dans l’évaluation de l’authentification. Consultez Filtrage amélioré pour les connecteurs.
  3. Configurez la passerelle pour conserver ou re-signer DKIM après le traitement.

E-mails de domaine partenaire mis en quarantaine malgré une authentification valide

Exemple d’en-tête :

Authentication-Results: spf=pass smtp.mailfrom=wingtiptoys.com;
 dkim=pass header.d=wingtiptoys.com;
 dmarc=pass header.from=wingtiptoys.com;
 compauth=fail reason=001

Cause racine : toutes les authentifications standard réussissent, mais l’authentification composite de Microsoft échoue toujours. L’intelligence contre l’usurpation d’identité signale probablement le domaine partenaire en raison de problèmes d’approbation inter-locataires.

Correction : ajoutez le domaine partenaire à la liste verte des usurpations d’identité à l’aide de la liste verte/de blocage du locataire. Connectez-vous à Exchange Online PowerShell et exécutez la commande suivante :

New-TenantAllowBlockListSpoofItems -SpoofedUser "*@wingtiptoys.com" -SendingInfrastructure wingtiptoys.com -SpoofType External -Action Allow

Matrice de décision

Utilisez le tableau suivant pour identifier rapidement l’action requise en fonction de l’état d’authentification :

État de l’authentification SPF DKIM DMARC Action requise
Tout est réussi Réussite Réussite Réussite Aucune action n’est nécessaire.
Échec de SPF uniquement échec Réussite Réussite Corrigez l’enregistrement SPF. Ajoutez l’adresse IP d’envoi ou incluez.
Seul DKIM échoue Réussite échec Réussite Activez DKIM et ajoutez des enregistrements DNS.
Échec de DMARC (alignement) Réussite Réussite échec Corriger l’alignement du domaine (le domaine SPF ou DKIM doit correspondre à From domain).
Échec de SPF + DKIM échec échec échec Corrigez SPF et DKIM de toute urgence.
Aucune authentification none none none Configurez les trois protocoles.
Problème de passerelle varie échec échec Implémentez ARC ou corrigez la configuration de la passerelle.

Outils de diagnostic

Utilisez les outils suivants pour diagnostiquer les problèmes d’authentification par e-mail :

Outil Objectif
Analyseur d’en-tête de message Analyser les résultats de l’authentification à partir des en-têtes de message (SPF, DKIM, DMARC, authentification composite). Disponible à l’adresse https://mha.azurewebsites.net/.
Analyseur de connectivité à distance Microsoft Testez la configuration de SPF, DKIM et DMARC pour votre domaine. Disponible à l’adresse https://testconnectivity.microsoft.com.
Suivi des messages Suivez la remise des messages et affichez les résultats de l’authentification dans le Centre d’administration Exchange (EAC). Pour plus d’informations, consultez Suivi des messages dans le centre d’administration Exchange moderne.
Insight d’intelligence contre l’usurpation d’identité Affichez les expéditeurs qui usurpent votre domaine et autorisez-les ou bloquez-les. Pour plus d’informations, consultez Spoof Intelligence Insight.

Lire les résultats de l’authentification dans les en-têtes de message

Pour diagnostiquer les échecs d’authentification, examinez l’en-tête Authentication-Results dans le message affecté. Pour obtenir une description complète de tous les champs et codes de raison, consultez En-tête de message Authentication-Results.

Exemple d’en-tête

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

Champs clés

Champ Valeurs possibles Signification
spf pass, fail, , softfailneutral, none, , temperror,permerror Indique si la validation SPF a réussi pour l’adresse IP d’envoi.
dkim pass, , failnone Indique si la vérification de la signature DKIM a réussi.
dmarc pass, , failbestguesspass, ,none Si la validation DMARC a abouti (nécessite la réussite de SPF ou de DKIM avec alignement).
compauth pass, , failsoftpass, ,none Indique si le message a réussi la vérification d’authentification composite de Microsoft (combine SPF, DKIM et d’autres signaux).
reason 000, , 001002, 010, , etc. Code de raison du résultat de l’authentification composite.

Contenu connexe

  • Dernière mise à jour :