E-mails en retard et erreur Server Busy dans Exchange Online : comprendre et corriger

L’erreur Server Busy dans Exchange Online, le plus souvent sous la forme « 451 4.7.500 Server busy. Please try again later », n’est pas une panne au sens strict : c’est un refus temporaire. Microsoft 365 demande au serveur expéditeur de revenir plus tard parce que l’adresse IP qui se présente envoie soudain bien plus de courrier qu’à son habitude. Les messages finissent par arriver, avec des minutes ou des heures de retard. La correction durable passe presque toujours par un connecteur entrant correctement configuré, après avoir vérifié que Microsoft ne signale pas d’incident de son côté.

En bref : la solution rapide

• Relevez le code complet dans l’avis de retard ou dans les journaux du serveur expéditeur : 451 4.7.500 à 699, 4.7.850 à 899 ou 432 4.3.2 ne désignent pas la même chose.
• Ouvrez le Centre d’administration Microsoft 365, Intégrité > Intégrité du service, et regardez la ligne Exchange Online.
• Lancez un suivi des messages dans le Centre d’administration Exchange : Flux de messagerie > Suivi des messages.
• Pas d’incident déclaré et retards limités à une source précise (serveur local, passerelle de filtrage, application) : créez ou corrigez le connecteur entrant correspondant.
• Demandez aux expéditeurs de ne pas renvoyer leurs messages en boucle : cela aggrave la limitation.

Reconnaître le problème

Vos utilisateurs se plaignent que les e-mails venus de l’extérieur arrivent une, deux, parfois six heures après leur envoi. Les messages internes, eux, sont instantanés. Aucun message n’est perdu, tout finit par arriver, souvent par paquets. Les expéditeurs reçoivent de leur côté un avis du type « La remise est retardée » (Delivery is delayed), sans rejet définitif.

Dans les journaux du serveur d’envoi ou dans l’avis de non-remise, la réponse de Microsoft 365 ressemble à l’une de ces lignes.

Le premier chiffre est la clé de lecture. Un code en 4 est temporaire : le serveur expéditeur doit réessayer, et le fera tout seul. Un code en 5 est définitif : le message est rejeté et ne reviendra pas sans intervention.

Pourquoi cela se produit

Exchange Online protège sa plateforme partagée par un mécanisme que Microsoft appelle la limitation par adresse IP (IP throttling). Chaque serveur qui dépose du courrier possède un historique. Tant qu’il envoie des volumes cohérents avec son passé, tout passe. Lorsqu’il se met à envoyer beaucoup plus, ou lorsqu’il apparaît pour la première fois avec un gros débit, le service se méfie et lui répond de repasser plus tard. C’est une forme de liste grise : une période probatoire pendant laquelle un expéditeur sans antécédents est traité avec prudence.

Un serveur légitime réessaie selon un calendrier croissant, quelques minutes puis des intervalles de plus en plus longs. Un robot de spam, lui, ne réessaie généralement pas. Le filtre est donc efficace, mais son effet de bord est connu : le courrier légitime prend du retard pendant que la réputation de l’adresse s’établit.

Le piège, c’est que cette protection se déclenche très souvent pour une raison de configuration et non de volume réel. Trois situations reviennent sans cesse.

La première concerne les organisations hybrides. Votre serveur Exchange local, votre copieur ou votre application métier relaie du courrier vers Microsoft 365. Sans connecteur entrant qui identifie cette source comme la vôtre, par son certificat ou par son adresse IP, Exchange Online la traite comme n’importe quel inconnu sur Internet et la bride.

La deuxième concerne les passerelles de filtrage. Si votre enregistrement MX pointe vers un service tiers d’antispam qui relaie ensuite vers Microsoft 365, tout le courrier entrant de l’entreprise arrive depuis une poignée d’adresses IP. Vu de Microsoft, c’est un afflux anormal depuis une seule source.

La troisième tient à un vrai changement de volume : migration de boîtes, campagne d’envoi massif, application qui s’emballe, compte compromis.

Le code 432 4.3.2 relève d’une autre logique. Il protège une boîte aux lettres donnée, pas le service : une boîte ne peut recevoir que 3 600 messages par heure, toutes sources confondues, et un seul expéditeur ne peut occuper qu’un tiers de ce plafond. Les boîtes partagées qui collectent des alertes de supervision l’atteignent régulièrement.

Avant de commencer

Il vous faut un compte avec un rôle d’administration Exchange pour le suivi des messages et les connecteurs. La consultation de l’intégrité du service est ouverte à des rôles plus restreints, dont l’administrateur du support technique.

Rassemblez trois éléments avant de toucher à quoi que ce soit : un exemple d’e-mail arrivé en retard avec ses en-têtes complets, le texte exact de l’erreur vue par un expéditeur, et l’heure approximative du début des retards. Les horodatages des outils Microsoft sont en UTC, pensez à convertir.

Ne modifiez pas l’enregistrement MX ni les connecteurs existants en pleine journée sans avoir noté la configuration actuelle. Une erreur à ce niveau transforme des retards en rejets.

Solution 1 : lire l’en-tête et le code d’erreur

À faire en premier. Sans risque, dix minutes.

1. Récupérez les en-têtes d’un message en retard

Dans Outlook, ouvrez le message puis Fichier > Propriétés : les en-têtes Internet sont en bas de la fenêtre. Copiez-les en entier.

2. Passez-les dans l’analyseur de Microsoft

Collez-les dans l’outil Message Header Analyzer (mha.azurewebsites.net). Il présente chaque saut du message sous forme de tableau, avec le délai passé à chaque étape. Les lignes Received se lisent de bas en haut : la plus basse est le départ, la plus haute l’arrivée dans la boîte.

3. Repérez où le temps s’est perdu

Si le délai se situe avant la première ligne mentionnant un serveur Microsoft (noms en outlook.com ou protection.outlook.com), le message a attendu chez l’expéditeur ou sur une passerelle intermédiaire, typiquement parce qu’il était refusé temporairement. Si le délai apparaît entre deux serveurs Microsoft, le ralentissement est interne au service et vous n’y pouvez rien : c’est un cas pour l’intégrité du service et le support.

4. Regardez l’authentification

La ligne Authentication-Results indique le résultat de SPF, DKIM et DMARC. Un spf=fail ou un dmarc=fail sur le courrier de vos propres partenaires n’explique pas un retard, mais explique des mises en quarantaine que les utilisateurs confondent souvent avec des retards.

Solution 2 : vérifier l’intégrité du service

À utiliser systématiquement avant de modifier votre configuration.

1. Ouvrez la page d’intégrité

Dans le Centre d’administration Microsoft 365 (admin.microsoft.com), allez dans Intégrité > Intégrité du service (Health > Service health). Une ligne Exchange Online marquée d’un incident ou d’un avis donne un identifiant, une description de l’impact et des mises à jour régulières.

2. Faites la différence entre incident et avis

Un incident désigne une interruption critique d’une fonction majeure. Un avis (advisory) désigne un problème qui touche une partie des utilisateurs alors que le service reste disponible, souvent par intermittence. Des retards de remise sont classés en avis la plupart du temps, ce qui explique qu’ils passent inaperçus si vous ne regardez que les alertes rouges.

3. Si le centre d’administration est inaccessible

Consultez status.cloud.microsoft, la page d’état publique, et le compte @MSFT365Status sur X.

4. Signalez le problème s’il n’est pas listé

Le bouton Signaler un problème (Report an issue) de la page d’intégrité permet de remonter une anomalie non répertoriée. Quand plusieurs organisations le font, l’enquête démarre plus vite.

Si un événement en cours décrit des retards de courrier entrant, votre travail s’arrête là : informez les utilisateurs et surveillez les mises à jour. Sinon, continuez.

Solution 3 : tracer les messages concernés

À utiliser pour mesurer l’ampleur et identifier la source. Sans risque.

1. Lancez le suivi

Dans le Centre d’administration Exchange (admin.exchange.microsoft.com), ouvrez Flux de messagerie > Suivi des messages (Mail flow > Message trace). Indiquez un expéditeur ou un destinataire touché et une plage couvrant le début des retards. Sur dix jours ou moins, le résultat s’affiche immédiatement.

2. Lisez les états et les événements

Un message à l’état En attente (Pending) est en cours de tentative. Dans le détail, l’événement Defer indique que la remise a été différée et sera retentée. Comparez l’heure de l’événement Receive avec celle de Deliver : si les deux sont proches alors que l’utilisateur a reçu le message des heures après son envoi, tout le retard s’est produit avant l’entrée dans Exchange Online. C’est la signature d’une limitation à la porte.

3. Sachez ce que le suivi ne montre pas

Un message refusé temporairement à la connexion n’est pas encore accepté par le service. Il peut donc être absent du suivi tant que le serveur expéditeur n’a pas réussi à le déposer. Un suivi vide ne prouve pas que rien n’a été envoyé.

4. En PowerShell

Get-MessageTraceV2 -SenderAddress [email protected] -StartDate <date de début> -EndDate <date de fin>

Remplacez l’adresse et les deux dates par les vôtres, au format de date de votre session PowerShell. La commande interroge au plus dix jours à la fois et renvoie 1 000 résultats par défaut.

5. Demandez un rapport étendu

Pour obtenir l’adresse IP d’origine et les détails de routage, choisissez le rapport de synthèse amélioré ou le rapport étendu, livrés en CSV. La colonne d’adresse IP vous dira si les messages retardés passent tous par la même source.

Solution 4 : distinguer la limitation Microsoft d’un défaut chez vous

C’est l’étape de diagnostic qui évite de corriger au mauvais endroit.

Posez-vous quatre questions. Les retards touchent-ils tous les expéditeurs externes, ou seulement certains ? Le courrier retardé transite-t-il toujours par la même adresse IP ? Quelque chose a-t-il changé dans votre routage juste avant les premiers retards : nouvel antispam, nouvelle adresse IP publique, certificat renouvelé, migration ? Un incident est-il affiché dans l’intégrité du service ?

Tous les expéditeurs, aucune source commune, incident affiché : le problème est chez Microsoft. Tous les expéditeurs, une source commune qui est votre passerelle de filtrage : le problème est chez vous, c’est un connecteur manquant. Quelques expéditeurs seulement : le problème est chez eux, leur adresse IP d’envoi est en période probatoire ou mal authentifiée. Uniquement le courrier relayé par votre serveur local : connecteur entrant absent ou qui ne reconnaît plus le serveur.

Ce dernier cas mérite un mot. Un connecteur identifie votre serveur soit par le nom figurant sur son certificat TLS, soit par son adresse IP. Changez d’opérateur Internet ou renouvelez le certificat avec un autre nom de sujet, et le connecteur ne reconnaît plus rien sans afficher la moindre erreur. Le courrier continue de partir, mais il est désormais traité comme anonyme.

Solution 5 : créer ou corriger le connecteur entrant

À utiliser dès que la source des retards est un serveur ou un service que vous contrôlez. Risque modéré : testez en dehors des heures de pointe.

1. Pour un serveur local ou une application

Dans le Centre d’administration Exchange, ouvrez Flux de messagerie > Connecteurs et ajoutez un connecteur dont l’origine est le serveur de messagerie de votre organisation et la destination Microsoft 365. Deux méthodes d’identification sont proposées. Microsoft recommande la vérification par certificat : le nom de sujet du certificat présenté par votre serveur doit correspondre à un domaine que vous déclarez. L’alternative consiste à lister les adresses IP publiques qui appartiennent exclusivement à votre organisation.

2. Pour une passerelle de filtrage tierce

Créez un connecteur de type partenaire, limité aux adresses IP ou au certificat de ce fournisseur. Microsoft précise que ce connecteur évite la liste grise qui frapperait sinon le gros volume de courrier venant de cette source.

3. Contrôlez l’existant

Si un connecteur existe déjà, comparez les adresses IP et le nom de certificat qu’il attend avec ce que votre serveur présente réellement. L’adresse IP vue par Microsoft figure dans l’erreur 451 elle-même et dans le rapport de suivi étendu.

4. Validez

Utilisez l’assistant de validation proposé à la fin de la création, puis envoyez plusieurs messages de test. Vérification : dans les journaux de votre serveur, les réponses 451 disparaissent et la file d’attente se vide.

Solution 6 : traiter la file d’attente d’un serveur hybride

À utiliser quand le serveur Exchange local accumule des messages.

1. Inspectez les files

Dans l’Exchange Management Shell du serveur local :

Get-Queue -Server Mailbox01 -Exclude Empty

La colonne de dernière erreur reproduit la réponse de Microsoft 365. La Visionneuse de files d’attente, dans la Boîte à outils Exchange, donne la même vue en mode graphique.

2. Relancez après correction

Une fois le connecteur corrigé, inutile d’attendre la prochaine tentative automatique :

Retry-Queue -Filter "Status -eq 'Retry'"

3. Vérifiez que le serveur n’est pas lui-même saturé

Si c’est votre serveur local qui répond « occupé » aux expéditeurs, la cause est interne : disque plein, mémoire insuffisante. Exchange se protège alors en refusant temporairement les connexions entrantes. Libérez de l’espace sur le volume qui héberge les files d’attente avant toute autre action.

Solution 7 : assainir l’authentification et les volumes d’envoi

À utiliser pour les retards et rejets dans le sens sortant, et pour éviter que votre domaine soit mal noté.

1. SPF

L’enregistrement de base pour un domaine qui n’envoie que depuis Microsoft 365 est :

v=spf1 include:spf.protection.outlook.com -all

Ajoutez-y vos autres sources légitimes. Attention au plafond de dix recherches DNS : au-delà, SPF échoue en erreur permanente et tout votre courrier perd son authentification.

2. DKIM et DMARC

Activez la signature DKIM de votre domaine dans le portail Defender (security.microsoft.com/authentication, onglet DKIM), après avoir créé les deux enregistrements CNAME selector1._domainkey et selector2._domainkey. Publiez ensuite une politique DMARC.

3. Respectez les plafonds

Une boîte Exchange Online envoie au maximum 30 messages par minute et à 10 000 destinataires par jour. Un plafond global de destinataires externes s’applique aussi à l’organisation, proportionnel au nombre de licences. Les domaines en onmicrosoft.com sont limités à 100 destinataires externes par 24 heures. Pour les envois en masse, Microsoft renvoie vers des services spécialisés.

4. Vérifiez qu’aucun compte n’est compromis

Un volume sortant qui explose sans raison, un code 5.1.8 ou 5.7.705 : cherchez un compte piraté avant toute autre hypothèse. Le courrier jugé douteux part par un groupe d’adresses IP à risque que beaucoup de destinataires refusent.

Ce que l’expéditeur externe peut faire

Pas grand-chose, et il faut le lui dire clairement. S’il renvoie dix fois le même message, il augmente le volume qui a déclenché la limitation. Son serveur retentera de lui-même. Il peut en revanche transmettre le texte exact de l’erreur à son propre administrateur, qui vérifiera la file d’attente, l’authentification SPF et DKIM du domaine, et la réputation de l’adresse IP d’envoi. Pour un document urgent, un autre canal reste la seule solution immédiate.

Quoi dire aux utilisateurs

Un message court suffit : les e-mails venant de l’extérieur arrivent actuellement avec retard, aucun n’est perdu, les messages internes ne sont pas concernés, il est inutile de demander aux correspondants de renvoyer. Indiquez un canal de secours pour les urgences et l’heure de votre prochain point. N’annoncez pas d’heure de rétablissement que vous ne maîtrisez pas.

Tableau récapitulatif

Si rien ne fonctionne

Ouvrez une demande d’assistance depuis le Centre d’administration Microsoft 365, rubrique Support. Un ticket bien préparé se traite plus vite. Joignez le texte intégral de l’erreur avec sa référence entre parenthèses, l’adresse IP d’envoi concernée, deux ou trois identifiants de message issus du suivi, les en-têtes d’un message retardé, les heures en UTC, le schéma de votre routage (MX, passerelle, connecteurs) et la date du dernier changement d’infrastructure.

Si l’erreur concerne un expéditeur externe, c’est à son administrateur d’agir : vous ne pouvez pas faire lever une limitation sur une adresse IP qui ne vous appartient pas.

Éviter que cela se reproduise

Documentez vos connecteurs et ajoutez leur vérification à la procédure de renouvellement de certificat et de changement d’opérateur. C’est la cause la plus fréquente de rechute.

Abonnez-vous aux notifications par e-mail de l’intégrité du service pour Exchange Online, en choisissant une adresse hors de votre organisation : une alerte sur un retard de messagerie envoyée dans la boîte concernée arrive trop tard.

Montez en charge progressivement lors d’une migration ou de la mise en service d’une nouvelle adresse IP d’envoi. Dirigez les alertes de supervision vers plusieurs boîtes ou vers un canal qui n’est pas la messagerie. Surveillez enfin les rapports DMARC et la taille des files d’attente de votre serveur local.

Questions fréquentes

Les e-mails en retard sont-ils perdus ?

Non, tant que le code commence par 4. Le serveur expéditeur les conserve et retente. Ils ne sont abandonnés que si les tentatives échouent jusqu’à expiration, ce qui produit un avis de non-remise.

Combien de temps dure une limitation 451 4.7.500 ?

Sans correction, elle s’estompe à mesure que l’adresse IP se constitue un historique, ce qui peut prendre quelques jours. Avec un connecteur adapté, elle cesse dès que celui-ci est reconnu.

Puis-je demander à Microsoft de lever la limitation ?

Il n’existe pas de bouton pour cela. La réponse attendue est un connecteur correct. Le support peut confirmer le diagnostic.

Pourquoi seuls les e-mails externes sont-ils touchés ?

Le courrier interne ne franchit pas la frontière du service et n’est pas soumis au contrôle de réputation des adresses IP.

Server busy veut-il dire que les serveurs de Microsoft sont surchargés ?

Rarement. Le libellé est trompeur : dans la plupart des cas, c’est votre source d’envoi qui est bridée, pas le service qui sature.

Si l’erreur Server Busy dans Exchange Online persiste chez vous, indiquez en commentaire le code complet, le sens du flux touché et l’architecture de votre routage : ces trois éléments permettent souvent de pointer le connecteur fautif.