La réception d’e‑mails externes s’arrête soudainement ? Ce guide pas à pas vous aide à isoler la cause (client, service, DNS), à corriger les paramètres clés (restriction de destinataire, quarantaine, règles, connecteurs) et à valider l’enregistrement MX de Microsoft 365.
Impossible de recevoir des e‑mails externes dans Microsoft 365 (Exchange Online)
Plusieurs symptômes sont rapportés : aucun message externe n’arrive ; seuls certains expéditeurs échouent (parfois avec NDR/bounce) alors que ces mêmes messages atteignent d’autres adresses (par ex. @msn) ; la case « Accepter les messages de tous les expéditeurs » paraît cochée ; une question récurrente porte sur l’enregistrement MX et sa vérification. Ci‑dessous : une procédure de triage courte, puis des diagnostics précis côté boîte, côté organisation et DNS, et des correctifs prêts à l’emploi.
Triage rapide (isoler la cause)
- Tester via Outlook sur le web (OWA)
Connectez‑vous avec le compte professionnel/école et envoyez un message vers votre boîte depuis une adresse externe (ex. un compte personnel).
Interprétation :
— Si OWA reçoit le message : la panne est côté client (profil Outlook, complément, règle côté poste).
— Si OWA ne reçoit pas : la cause se situe côté service (Exchange Online, filtres, règles de flux, connecteur, DNS/MX). - Obtenir un NDR/bounce auprès du ou des expéditeurs affectés.
Les codes (ex.550 5.7.x) orientent immédiatement : authentification de domaine, réputation IP, connecteur, restriction de destinataire, DMARC, etc.
| Résultat du test | Probable origine | Étape suivante |
|---|---|---|
| OWA reçoit | Client Outlook/POP/IMAP/Profil/Complément/Règle locale | Réinitialiser le profil, désactiver compléments, vérifier règles locales et dossiers |
| OWA ne reçoit pas | Service (EOP/EXO), règles de flux, quarantaine, connecteurs, DNS/MX | Lancer un Message trace, vérifier quarantaine, restrictions de remise, MX |
Contrôles côté boîte aux lettres (administration Microsoft 365)
Restrictions de remise (bloqueur #1 le plus courant)
Vérifiez que la boîte n’exige pas des expéditeurs authentifiés. Ce paramètre, s’il est activé, bloque tous les expéditeurs externes (anonymes) : seuls les utilisateurs internes authentifiés passent.
- Par l’interface : Centre d’administration Exchange (EAC) > Destinataires > Boîtes aux lettres > sélectionnez la boîte > Fonctionnalités de boîte / Restrictions de remise > assurez‑vous que « Exiger l’authentification de tous les expéditeurs » est désactivé.
- Par PowerShell (Exchange Online) :
# Vérifier
Get-Mailbox user@domaine.tld | fl RequireSenderAuthenticationEnabled
# Désactiver si nécessaire
Set-Mailbox [user@domaine.tld](mailto:user@domaine.tld) -RequireSenderAuthenticationEnabled \$false Astuce : appliquez d’abord sur une seule boîte impactée, testez, puis corrigez à l’échelle si besoin.
Règles côté boîte et règles de flux (transport)
- Règles de boîte : dans OWA, inspectez Règles de boîte (déplacement/suppression automatique, mots‑clés, expéditeurs). Désactivez‑les temporairement pour tester.
- Règles de flux : EAC > Flux de courrier > Règles. Recherchez toute condition sur « L’expéditeur est externe », domaine spécifique, IP, liste noire, type de pièce jointe ou marqueurs anti‑phishing. Une règle « Rejeter le message et inclure une explication » déclenchée pour les expéditeurs externes bloquera la réception.
# Inventorier rapidement les règles de boîte
Get-InboxRule -Mailbox user@domaine.tld | ft Name,Enabled,Priority,Description
# Inventorier les règles de transport
Get-TransportRule | ft Name,Mode,State,Priority,Comments Courrier indésirable : expéditeurs bloqués / approuvés
Dans OWA : Paramètres > Courrier > Courrier indésirable : vérifiez les expéditeurs et domaines bloqués et les expéditeurs approuvés. Retirez des blocages excessifs ou ajoutez temporairement un expéditeur légitime à la liste approuvée pour confirmer le diagnostic.
Quarantaine (Microsoft Defender)
Les messages peuvent être reçus par le service mais retenus en quarantaine (phishing, spam élevé, malware, règles). Via le portail de sécurité : accédez à Email & collaboration > Review > Quarantine, filtrez sur le destinataire, ouvrez un message et libérez‑le s’il est légitime. Tenez compte du verdict (ex. High confidence phishing) : il aiguillera le correctif (règle, liste d’autorisation, formation utilisateur, ajustement de politique).
Traçage de message (Message trace)
Dans le nouvel EAC : Flux de courrier > Traçage des messages. Le traçage indique si le message a été reçu, rejeté, différé, quarantainé ou livré, et quelle action l’a affecté (filtrage spam, règle, connecteur, limite, taille).
# Traçage rapide 48h
Get-MessageTrace -RecipientAddress user@domaine.tld `
-StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date)
# Détails d’un message précis (remplacez les valeurs)
Get-MessageTraceDetail -MessageTraceId \ -RecipientAddress [user@domaine.tld](mailto:user@domaine.tld) | Statut de trace | Signification | Action conseillée |
|---|---|---|
| Delivered | Message remis à la boîte ou au dossier | Vérifier règles locales, dossiers, classement ciblé |
| Quarantined | Retenu par une politique (spam/phishing/malware) | Libérer si légitime, ajuster politique ou ajouter autorisation |
| FilteredAsSpam | Classé spam (SCL élevé) | Réviser expéditeur, contenu, ajouter autorisation si justifié |
| Expanded | Liste de distribution étendue | Vérifier membres/permissions, limites du groupe |
| Failed/Rejected | Rejet (politique, connecteur, destinataire) | Lire le code NDR, corriger la cause (voir tableau NDR) |
| Deferred | Différé (temporaire : réputation, charge, DNS) | Attendre la nouvelle tentative, contrôler DNS/volumétrie |
Vérifications côté organisation et DNS
Enregistrement MX du domaine
L’enregistrement MX indique aux autres serveurs où livrer le courrier pour votre domaine. Pour Microsoft 365, la cible doit être le service de protection Exchange (EOP) au format <votre-domaine-avec-tirets>.mail.protection.outlook.com. Microsoft recommande un seul MX pointant vers Microsoft 365 avec la priorité la plus élevée : des MX concurrents (ex. ancien prestataire) provoquent des routages aléatoires et des pertes de courrier.
Comment vérifier
- Dans l’Admin center Microsoft 365 : Paramètres > Domaines : choisissez votre domaine, puis utilisez les vérifications de santé. L’interface signale un MX non conforme et propose de corriger.
- Dans votre hébergeur DNS (registrar/zone publique) : ouvrez la zone et confirmez que l’unique MX prioritaire pointe vers mail.protection.outlook.com.
- En ligne de commande (pour contrôle indépendant) :
# Windows
nslookup -type=mx votre-domaine.tld
# macOS/Linux
dig MX votre-domaine.tld +short
# PowerShell (Windows)
Resolve-DnsName -Name votre-domaine.tld -Type MX | Résultat attendu | Interprétation | Action |
|---|---|---|
| Un seul MX → …mail.protection.outlook.com (priorité la plus basse/valeur la plus faible) | Conforme Microsoft 365 | Passer aux autres vérifications (règles, quarantaine, connecteurs) |
| Plusieurs MX (dont un vers un ancien fournisseur) | Routage imprévisible | Supprimer l’ancien MX, ne garder que Microsoft 365 |
| MX autre que Microsoft 365 | Courrier non acheminé vers EOP | Mettre à jour le MX vers Microsoft 365 |
Propagation DNS : points d’attention
- TTL (time to live) : privilégiez un TTL court (300–900 s) pendant une migration, puis remontez‑le (ex. 1 h) après stabilisation.
- Propagation : la majorité des résolveurs prennent en compte la nouvelle valeur dans les minutes qui suivent l’expiration du TTL, mais certains caches peuvent durer plus longtemps.
- Surveillance : testez depuis plusieurs réseaux (entreprise, 4G, Wi‑Fi invité) pour éviter l’effet de cache local.
Domaines acceptés et connecteurs (scénarios avancés)
- Domaines acceptés : dans l’EAC > Flux de courrier > Domaines acceptés, votre domaine doit être Authoritative (sauf coexistence/hybride). En « Internal relay », Exchange peut relayer vers une destination externe si un connecteur/passerelle le requiert.
- Connecteurs : si vous utilisez des connecteurs entrants/sortants (TLS obligatoire, liste d’IP autorisées, certificats), tout écart (mauvais certificat, IP non autorisée, domaine mal orthographié) génère des rejets
5.7.x. Révisez : Flux de courrier > Connecteurs.
# Vérifier les domaines acceptés
Get-AcceptedDomain | ft Name,DomainName,DomainType,Default
# Lister les connecteurs entrants/sortants
Get-InboundConnector | ft Name,Enabled,SenderIPAddresses,RequireTls,SenderDomains
Get-OutboundConnector | ft Name,Enabled,SmartHosts,ConnectTo,RouteAllMessagesViaOnPremises Quand seuls certains expéditeurs sont bloqués
Ce cas n’implique pas forcément un problème chez vous. Le NDR côté expéditeur est déterminant : SPF/DKIM/DMARC échoués, IP sur liste noire, format d’adresse invalide, taille/zip protégés, etc. Pendant l’investigation, vous pouvez appliquer des autorisations temporaires et ciblées dans la Tenant Allow/Block List pour un domaine, une adresse, une URL ou une pièce jointe.
# Rechercher des entrées existantes
Get-TenantAllowBlockListItems | ft ListType,Entries,Notes,ExpirationDate
# Ajouter une autorisation temporaire (ex. expéditeur)
New-TenantAllowBlockListItems -ListType Sender -Entries "[contact@fournisseur.com](mailto:contact@fournisseur.com)" \`
-ExpirationDate (Get-Date).AddDays(7) -Notes "Dépannage blocage fournisseur"
# Supprimer l’autorisation quand l’expéditeur a corrigé son domaine
Remove-TenantAllowBlockListItems -ListType Sender -Entries "[contact@fournisseur.com](mailto:contact@fournisseur.com)" Bonnes pratiques : privilégiez l’autorisation au niveau le plus précis (adresse plutôt que domaine ; domaine plutôt qu’IP) et limitez dans le temps. Demandez à l’expéditeur de corriger SPF/DKIM/DMARC, le reverse DNS et sa réputation d’envoi.
| Symptôme côté expéditeur | Cause fréquente | Action chez l’expéditeur |
|---|---|---|
NDR 550 5.7.23/26 (DMARC/SPF échoué) | Authentification de domaine non alignée | Signer DKIM, aligner SPF et DMARC, corriger l’enveloppe d’envoi |
NDR 550 5.7.1 (policy) | IP sur liste de blocage, réputation dégradée | Nettoyer la réputation, désinscrire des RBL, mettre en place des limites |
| Quelques destinataires reçoivent, d’autres non | MX multiples chez le destinataire ou filtrage sélectif | Vérifier routeur de mail du destinataire et refaire l’envoi après correction |
Comptes grand public (Outlook.com/Hotmail/MSN)
Vous n’avez pas l’EAC. Depuis le webmail, ouvrez Paramètres > Courrier > Courrier indésirable : supprimez l’expéditeur des bloqués et ajoutez‑le aux approuvés. Si l’expéditeur reçoit des bounces vers Outlook.com/Hotmail, orientez‑le vers le Postmaster et les outils de réputation pour analyser son IP et son authentification.
Focus « MX record » — ce qu’il faut vérifier
- Définition : l’enregistrement MX de votre domaine indique aux serveurs où déposer votre courrier entrant.
- Valeur attendue pour Microsoft 365 : un unique MX prioritaire vers
<votre-domaine-avec-tirets>.mail.protection.outlook.com. - Où le voir/modifier : chez votre fournisseur DNS (zone publique), et dans l’Admin center > Paramètres > Domaines pour un contrôle d’intégrité.
- Tests : la commande ci‑dessous doit renvoyer …mail.protection.outlook.com avec la priorité la plus haute.
nslookup -type=mx votre-domaine.tld
Attention : évitez de garder un ancien MX « au cas où » ; il crée des boucles et des pertes. Si vous travaillez avec une passerelle tierce (sécurité/archivage), définissez un unique MX pointant vers cette passerelle ou vers Microsoft 365 selon l’architecture choisie, mais pas les deux.
Commandes utiles supplémentaires (administrateurs)
# Vérifier rapidement le paramètre de restriction sur plusieurs boîtes
Get-Mailbox -ResultSize Unlimited | select PrimarySmtpAddress,RequireSenderAuthenticationEnabled `
| ft -AutoSize
# Lister les politiques anti-spam/malware
Get-HostedContentFilterPolicy | ft Name,SpamAction,HighConfidenceSpamAction
Get-MalwareFilterPolicy | ft Name,Action
# Vérifier l'état d'une adresse dans la quarantaine via audit
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) \`
-Operations QuarantineReleased,QuarantineMessage Scénarios typiques et résolutions
Paramètre « Exiger l’authentification » activé par erreur
Symptôme : aucun expéditeur externe ne passe, les internes oui. Diagnostic : trace « Rejected » sans passer par l’anti‑spam. Correctif : désactiver RequireSenderAuthenticationEnabled sur la boîte (ou par lot si plusieurs affectées), puis tester.
MX pointant toujours vers l’ancien fournisseur
Symptôme : certains e‑mails arrivent encore chez l’ancien prestataire, ou nulle part. Diagnostic : nslookup montre plusieurs MX. Correctif : supprimer tous les MX sauf celui de Microsoft 365, TTL court, attente de propagation, test depuis plusieurs réseaux.
Architecture hybride ou passerelle tierce avec connecteurs stricts
Symptôme : bounces 5.7.x (TLS requis, IP non autorisée). Diagnostic : Message trace et journaux passerelle. Correctif : valider certificats, plages IP, domaines expéditeurs et règles des connecteurs (inbound/outbound). S’assurer que le type de domaine (Authoritative / Internal relay) correspond au design.
Quarantaine pour hameçonnage à forte confiance
Symptôme : l’expéditeur « bien connu » n’arrive plus. Diagnostic : trace « Quarantined » avec verdict phishing élevé. Correctif : libérer, créer une autorisation temporaire (adresse ou domaine), puis faire corriger par l’expéditeur (DKIM, lien d’abonnement, contenu, envoi par lot).
Échec DMARC/SPF sur certains envois de marketing
Symptôme : seuls les envois via un outil tierce part tombent en NDR 5.7.23/26. Diagnostic : Authentication‑Results indique SPF ou DKIM non aligné. Correctif : publier l’enregistrement SPF avec l’inclusion du routeur d’envoi, activer DKIM pour le domaine d’envoi, vérifier l’alignement DMARC (From: / d= / mfrom).
Foire aux questions
Combien de temps pour voir l’effet d’un changement MX ?
Généralement à l’expiration du TTL. Avec un TTL de 300 s, comptez quelques minutes ; certains caches publics persistent plus longtemps. Testez depuis plusieurs réseaux.
Dois‑je garder un ancien MX en secours ?
Non. Un MX supplémentaire introduit un routage imprévisible. Utilisez un seul MX conforme au design (Microsoft 365 ou passerelle tierce, pas les deux).
Changer le MX suffit‑il ?
Oui pour le routing de base, mais des règles, la quarantaine ou des connecteurs peuvent toujours intercepter un message. Utilisez le Message trace pour confirmer le chemin réel.
Et si les e‑mails volumineux sont bloqués ?
Vérifiez les limites de taille côté expéditeur et côté tenant (règles, politiques de transport). Le message trace indiquera un rejet pour taille excessive le cas échéant.
Checklist express
- Tester avec Outlook sur le web (client vs service).
- Vérifier la quarantaine et libérer si nécessaire.
- Lancer un Message trace sur un exemple réel.
- Dans la boîte : désactiver « Exiger l’authentification de tous les expéditeurs ».
- Contrôler règles (boîte/transport) et expéditeurs bloqués.
- Confirmer l’MX : un seul MX vers …mail.protection.outlook.com avec la priorité la plus élevée.
- Vérifier Domaines acceptés (Authoritative) et connecteurs (TLS/IP/domaines) le cas échéant.
- Si un expéditeur précis est bloqué, créer une autorisation temporaire (Allow) le temps qu’il corrige SPF/DKIM/DMARC.
- Réessayer et archiver horodatage + NDR (si reçu).
- Si compte Outlook.com/Hotmail/MSN, gérer les expéditeurs approuvés côté webmail et orienter l’expéditeur vers les outils Postmaster.
Annexe : erreurs NDR courantes et correctifs
| Code NDR | Cause probable | Correctif côté destinataire (vous) | Correctif côté expéditeur |
|---|---|---|---|
| 550 5.1.1 | Destinataire inconnu | Vérifier l’adresse/proxy SMTP, synchronisation Azure AD | Corriger l’adresse saisie |
| 550 5.1.10 / 5.7.1 (relay) | Relais non autorisé | Vérifier domaine accepté/authoritative, connecteurs | Utiliser un serveur d’envoi autorisé |
| 550 5.7.23 / 5.7.26 | Échec DMARC/SPF/DKIM | Rajouter autorisation temporaire si nécessaire | Aligner SPF, signer DKIM, DMARC en p=none/quarantine/reject selon maturité |
| 550 5.7.64 | Échec de l’authentification TLS/certificat | Vérifier connecteurs, certificats attendus | Présenter le bon certificat, chaîne valide |
| 451 4.7.500 / 421 4.4.2 | Temporaire : réputation, flux, DNS | Surveiller et relancer, vérifier MX/DNS | Améliorer réputation, ralentir le débit, vérifier SPF |
| 550 5.7.705 | Blocage par réputation IP/domain | Autorisation temporaire ciblée | Demande de retrait des listes, hygiène des envois |
Modèle d’e‑mail à envoyer à votre hébergeur DNS
Objet : Demande de mise à jour de l’enregistrement MX pour <votre-domaine.tld>
Bonjour,
Merci de remplacer l’enregistrement MX actuel par l’unique entrée suivante :
Type : MX
Nom : @
Valeur : \.mail.protection.outlook.com
Priorité : 0 (ou la plus faible valeur)
TTL : 300 secondes (temporaire le temps du basculement)
Veuillez supprimer tout autre enregistrement MX existant pour ce domaine.
Merci de me confirmer une fois l’opération effectuée.
Cordialement,
\ Bonnes pratiques et prévention
- Avant migration : abaissez le TTL du MX (300 s) 24–48 h avant le basculement.
- Après migration : supprimez les anciens MX, remontez le TTL, documentez l’architecture (avec ou sans passerelle tierce).
- Politiques EOP : évitez les exemptions globales. Préférez des autorisations ciblées et temporaires.
- Observabilité : validez régulièrement la santé du domaine dans l’Admin center et auditez les quarantaines.
- Sécurité : activez DKIM pour vos domaines Microsoft 365, publiez DMARC (au moins
p=noneau départ) et tenez votre SPF à jour. - Procédures : gardez un runbook de réponse incident e‑mail (qui fait quoi, où trouver traces et quarantaines, comment escalader).
En bref
Une panne globale de réception externe est le plus souvent due à : (i) une restriction de destinataire activée par erreur, (ii) un MX non orienté vers Microsoft 365 (ou en concurrence avec un ancien MX), (iii) un filtrage (quarantaine/règle) qui intercepte les messages, ou (iv) des conditions de connecteur non satisfaites. En suivant la liste ci‑dessus, vous isolez et corrigez rapidement la cause, tout en durcissant votre posture d’envoi/réception pour la suite.