Quand des emails n’arrivent pas avec Microsoft 365, le dépannage ne commence pas toujours dans Outlook. Le problème peut venir d’Exchange Online, du DNS, du MX, de SPF, DKIM, DMARC, d’un rejet visible dans Message trace ou du filtre du destinataire.
Pour une PME de moins de 50 utilisateurs, l’objectif est d’identifier vite si le blocage concerne la réception, l’envoi ou l’authentification du domaine.
Un email peut être bloqué à plusieurs endroits : avant d’arriver chez Microsoft 365, dans Exchange Online, chez le destinataire, dans un filtre anti-spam ou à cause d’un service tiers mal déclaré. La bonne méthode consiste donc à distinguer “je ne reçois pas” de “mes clients ne reçoivent pas mes emails”.
Réponse courte :
Si vos emails Microsoft 365 n’arrivent pas, vérifiez d’abord si le problème concerne les messages entrants ou sortants. Ensuite, contrôlez le MX du domaine, lancez un Message trace dans Exchange Online, puis vérifiez SPF, DKIM et DMARC. Si plusieurs utilisateurs sont touchés, collectez les preuves avant toute modification DNS.
Votre PME utilise Microsoft 365 au quotidien et certains emails n’arrivent plus ? Axorys peut diagnostiquer l’origine du blocage, vérifier Message trace, MX, SPF, DKIM, DMARC, les DNS du domaine et les erreurs Exchange Online.
Dans une petite entreprise sans administrateur Microsoft 365 dédié, il faut éviter de modifier les DNS trop vite. Le premier réflexe consiste à savoir où se situe le blocage : réception, envoi, authentification du domaine ou filtre du destinataire.
| Situation | Cause probable | Première action |
|---|---|---|
| Vous ne recevez plus aucun email | MX incorrect, ancien fournisseur, incident Exchange | Vérifier MX et Message trace |
| Vous ne recevez pas certains emails | Quarantaine, filtre anti-spam, rejet expéditeur | Lancer Message trace avec l’expéditeur |
| Vos clients ne reçoivent pas vos emails | SPF, DKIM, DMARC, réputation ou filtre destinataire | Vérifier l’authentification du domaine |
| Vos emails arrivent en spam | DKIM absent, DMARC faible, SPF incomplet | Contrôler SPF, DKIM et DMARC |
| Un outil tiers n’envoie plus | CRM, ERP, scanner ou newsletter absent du SPF | Inventorier les expéditeurs |
| Problème après migration | Ancien MX, DNS incomplet, propagation | Comparer DNS Microsoft 365 et DNS public |
Cette distinction évite de traiter un problème d’envoi comme un problème de réception. Par exemple, si votre PME reçoit les emails mais que les clients ne reçoivent pas vos réponses, le MX n’est pas forcément en cause. Il faut plutôt regarder SPF, DKIM, DMARC, les rejets et les filtres destinataires.
Message trace est l’un des tests les plus utiles dans Exchange Online. Il permet de vérifier ce que Microsoft 365 a fait d’un message : reçu, livré, rejeté, différé ou encore en attente. Microsoft explique que Message trace permet de suivre les messages dans le service cloud et d’obtenir leur statut. (Microsoft Learn)
Procédure courte :
Message trace aide à répondre à une question simple : Exchange Online a-t-il vu le message ?
Si le message est livré, le blocage peut venir de la boîte du destinataire, de la quarantaine, d’une règle Outlook, du courrier indésirable ou d’un filtre local. Si le message est rejeté ou différé, il faut lire le code d’erreur, souvent dans un NDR, c’est-à-dire un rapport de non-remise.
Le MX est l’enregistrement DNS qui indique où les emails de votre domaine doivent arriver. Si le MX pointe encore vers un ancien fournisseur mail, ou si plusieurs MX sont mal priorisés, certains messages peuvent partir au mauvais endroit.
Microsoft indique que l’enregistrement MX est requis pour Microsoft 365 et qu’il détermine où les emails du domaine doivent être envoyés. Microsoft précise aussi qu’un ancien MX doit être supprimé ou placé avec une priorité inférieure au MX Microsoft 365. (Microsoft Learn)
| Élément DNS | Rôle | Point de vigilance |
|---|---|---|
| MX | Réception des emails | Doit pointer vers la valeur Microsoft 365 du tenant |
| Ancien MX | Ancien fournisseur mail | À supprimer ou rendre moins prioritaire |
| SPF TXT | Autorise les serveurs d’envoi | Un seul SPF par domaine ou sous-domaine |
| DKIM CNAME | Permet la signature Microsoft 365 | Microsoft 365 utilise des CNAME, pas un TXT DKIM classique |
| DMARC TXT | Donne la règle si SPF/DKIM échouent | Commencer prudemment en observation |
| Autodiscover | Configuration Outlook | À ne pas détailler ici, article dédié |
Après une migration, cette vérification est prioritaire. Un domaine peut sembler migré côté utilisateurs, alors que l’ancien fournisseur mail reste encore prioritaire dans le DNS. Dans ce cas, certains emails arrivent dans l’ancien environnement, d’autres dans Microsoft 365, et le diagnostic devient confus.
Pour les problèmes de connexion Outlook liés à Autodiscover, il vaut mieux traiter le sujet séparément via l’article Autodiscover Exchange Online et Outlook.
SPF, pour Sender Policy Framework, est un enregistrement TXT DNS qui liste les serveurs autorisés à envoyer des emails pour le domaine.
Dans Microsoft 365, SPF sert notamment à autoriser Exchange Online à envoyer des emails avec votre domaine. Microsoft documente la configuration SPF pour identifier les sources de courrier valides dans Microsoft 365. (Microsoft Learn)
Un SPF Microsoft 365 contient généralement :
include:spf.protection.outlook.com
Le point sensible en PME vient souvent des services tiers. Un CRM, un ERP, un outil de facturation, un scanner multifonction, un site web ou une newsletter peut envoyer des emails au nom du domaine. Si ces services ne sont pas pris en compte, certains emails peuvent être rejetés ou arriver en spam.
À vérifier :
Il ne faut pas empiler plusieurs SPF. Un domaine ne doit pas avoir plusieurs enregistrements SPF séparés, sinon les serveurs destinataires peuvent mal interpréter la règle.
DKIM, pour DomainKeys Identified Mail, ajoute une signature cryptographique aux emails. Cette signature aide le serveur destinataire à vérifier que le message n’a pas été modifié et qu’il est bien associé au domaine d’envoi.
Microsoft explique comment utiliser DKIM avec un domaine personnalisé dans Microsoft 365. (Microsoft Learn)
Dans Microsoft 365, DKIM repose sur des enregistrements CNAME à publier dans le DNS du domaine. Ce point est important, car beaucoup d’utilisateurs cherchent un simple enregistrement TXT DKIM, alors que Microsoft 365 fonctionne avec des CNAME spécifiques.
À vérifier :
Dans une PME qui envoie des devis, factures et réponses clients depuis Microsoft 365, l’objectif n’est pas d’optimiser une campagne marketing. L’objectif est que les messages métier légitimes soient authentifiés et traçables.
DMARC, pour Domain-based Message Authentication, Reporting and Conformance, indique aux serveurs destinataires quoi faire lorsqu’un email échoue à l’authentification SPF ou DKIM.
Microsoft précise que DMARC s’active en créant un enregistrement TXT dans le DNS. (Microsoft Learn)
| Politique DMARC | Effet | Usage PME recommandé |
|---|---|---|
p=none | Observer sans bloquer | Départ, collecte de rapports |
p=quarantine | Mettre en spam les messages suspects | Après correction des expéditeurs légitimes |
p=reject | Rejeter les messages non conformes | Quand SPF/DKIM sont maîtrisés |
rua | Recevoir des rapports agrégés | Utile pour identifier les sources d’envoi |
sp | Politique pour sous-domaines | À prévoir si des sous-domaines envoient |
Ne passez pas directement en p=reject si les expéditeurs légitimes ne sont pas connus : CRM, outil de facturation, ERP, plateforme de support, newsletter, copieur, site web ou application métier.
Une politique DMARC trop stricte peut bloquer des emails légitimes si SPF et DKIM ne sont pas prêts. La bonne approche consiste à commencer en observation, corriger les sources d’envoi, puis durcir progressivement.
Pour une vérification propre, suivez cet ordre :
Cette procédure doit être documentée. Une capture DNS, un export Message trace et une liste des services d’envoi valent mieux qu’une modification faite “au feeling”.
Même si cet article n’est pas un guide de délivrabilité marketing, les grands fournisseurs de messagerie sont plus stricts sur l’authentification des emails.
Google indique que tous les expéditeurs vers Gmail doivent utiliser SPF ou DKIM, et que les expéditeurs de plus de 5 000 messages par jour doivent configurer SPF, DKIM et DMARC. Google recommande aussi SPF, DKIM et DMARC pour améliorer la livraison et protéger le domaine contre l’usurpation. (Assistance Google)
Pour une PME, le sujet n’est pas le warm-up, les campagnes ou la réputation IP en détail. Le sujet est plus simple : les emails de devis, factures, relances, réponses clients et notifications métier doivent être correctement authentifiés.
Un message peut être techniquement envoyé par Microsoft 365, mais finir en spam chez Gmail ou Outlook.com si l’authentification du domaine est faible, absente ou incohérente.
| Symptôme | Cause probable | Action recommandée |
|---|---|---|
| Aucun email entrant n’arrive | MX incorrect ou ancien fournisseur prioritaire | Vérifier MX public et DNS Microsoft 365 |
| Un client dit ne pas recevoir vos emails | Rejet côté destinataire, spam, SPF/DKIM/DMARC | Demander le NDR ou tester un autre destinataire |
| Emails en spam chez Gmail ou Outlook.com | Authentification incomplète | Vérifier SPF, DKIM, DMARC |
| Emails envoyés depuis le CRM non reçus | CRM absent du SPF ou DKIM non aligné | Inventorier les services d’envoi |
| Message trace indique “delivered” | Mail livré à Exchange mais non vu par l’utilisateur | Vérifier quarantaine, règles, dossier indésirable |
| Message trace indique “failed” ou “rejected” | Rejet technique ou politique | Lire le code d’erreur et collecter la trace |
| Problème après migration | Ancien MX ou DNS partiellement basculé | Comparer DNS attendus et DNS publics |
| Un seul utilisateur touché | Règle Outlook, boîte, filtre local | Ne pas modifier les DNS trop vite |
Le piège le plus courant consiste à changer SPF, DKIM ou DMARC alors que le problème touche un seul utilisateur. Si un seul salarié ne voit pas certains emails, commencez par la boîte, les règles Outlook, le courrier indésirable, la quarantaine et Message trace.
Pour les problèmes où Outlook ne se connecte plus à Exchange Online, l’article Outlook ne se connecte plus à Exchange Online est plus adapté.
Pour une structure de 10 à 20 postes, les preuves évitent les allers-retours inutiles. Un prestataire ne doit pas seulement “regarder le DNS”. Il doit pouvoir dire ce qui a été testé, ce qui bloque, ce qui a été corrigé et ce qui reste à valider.
Preuve utile pour le support :
Ces éléments permettent de distinguer un problème Microsoft 365, un problème DNS, un rejet destinataire, une erreur de migration ou un service tiers mal déclaré.
Le dépannage peut rester simple si un seul utilisateur est touché et si Message trace montre que les emails sont bien livrés. En revanche, certains cas doivent être traités plus méthodiquement.
Contactez un prestataire si :
Dans ce cas, la page dépannage Outlook et Exchange permet de traiter le problème avec une méthode structurée : diagnostic, preuves, correction et validation.
| Action | PME | Prestataire |
|---|---|---|
| Signaler les utilisateurs touchés | Responsable | Appui |
| Fournir exemples d’emails non reçus | Responsable | Appui |
| Lancer Message trace | Appui si accès admin | Responsable si mandat |
| Vérifier MX public | Appui | Responsable |
| Corriger SPF | Validation métier des expéditeurs | Responsable |
| Activer DKIM | Validation | Responsable |
| Déployer DMARC progressivement | Validation | Responsable |
| Documenter l’incident | Appui | Responsable |
Cette répartition évite les malentendus. La PME fournit le contexte métier et valide les expéditeurs légitimes. Le prestataire vérifie, corrige, teste et documente.
Pour une entreprise sans DSI interne, l’ordre de diagnostic doit rester simple :
Pour replacer ce diagnostic dans une vision plus large, consultez le guide Microsoft 365 pour PME de moins de 50 utilisateurs ou les guides Microsoft 365 PME.
En cas de problème après une migration, les articles sur la migration OVH vers Exchange Online et la migration Google Workspace vers Exchange Online peuvent aider à comprendre les erreurs DNS les plus fréquentes.
Vos emails Microsoft 365 peuvent ne pas arriver à cause d’un mauvais MX, d’un ancien fournisseur mail encore actif, d’un SPF incorrect, d’un DKIM non activé, d’un DMARC mal réglé, d’un rejet côté destinataire ou d’un message bloqué dans Exchange Online.
Lancez Message trace dans Exchange Online. Si le message est rejeté, différé ou non trouvé, le problème est probablement visible côté Microsoft 365 ou DNS. Si le message est livré, il faut vérifier la boîte du destinataire, sa quarantaine, son dossier indésirable ou ses règles.
Non. SPF, DKIM et DMARC améliorent l’authentification du domaine et réduisent les risques de rejet ou de spam, mais ils ne garantissent pas la livraison. Le contenu, les filtres du destinataire, les pièces jointes, les règles anti-spam et la réputation peuvent aussi intervenir.
Vérifier SPF, activer DKIM, publier DMARC, contrôler les services tiers qui envoient au nom du domaine et analyser les en-têtes d’un message arrivé en spam. Google exige au minimum SPF ou DKIM pour tous les expéditeurs vers Gmail, et SPF, DKIM et DMARC pour les gros volumes.
Vérifier que le MX pointe vers Microsoft 365, que l’ancien fournisseur mail n’est plus prioritaire, que SPF contient Microsoft 365, que DKIM est activé et que DMARC ne bloque pas les expéditeurs légitimes.
Contactez un prestataire si plusieurs utilisateurs sont touchés, si le DNS doit être modifié, si Message trace affiche des rejets répétés, si DKIM ou DMARC sont mal configurés, ou si des outils tiers envoient au nom du domaine.
Quand des emails Microsoft 365 n’arrivent pas, le problème n’est pas toujours Outlook. Il peut venir d’un MX incorrect, d’un ancien fournisseur mail, d’un SPF mal construit, d’un DKIM non activé, d’un DMARC trop strict, d’un service tiers oublié ou d’un rejet visible dans Message trace.
La bonne méthode consiste à avancer dans l’ordre : réception ou envoi, Message trace, MX, SPF, DKIM, DMARC, services tiers et preuves. Cela permet de corriger le bon point sans casser le reste de la messagerie.
Votre PME utilise Microsoft 365 au quotidien et certains emails n’arrivent plus ? Axorys peut diagnostiquer l’origine du blocage, vérifier Message trace, MX, SPF, DKIM, DMARC, les DNS du domaine et les erreurs Exchange Online.