Référence : 451 4.7.500–699 dans le wiki des codes d’erreur
Sur cette page
Quand Microsoft 365 renvoie ce report temporaire :
421 4.7.500 Server busy. Please try again later.
… on dirait un incident d'infrastructure passager. Ce n'en est presque jamais un. Le 4.7.500 (et son proche cousin 4.7.501) est un throttling fondé sur la réputation déguisé en message de charge serveur. Si vous ne le reconnaissez pas, vos e-mails restent en report indéfiniment et finissent par expirer.
Ce que signifie vraiment le 4.7.500
La référence NDR de Microsoft décrit les codes 4.7.500-699 comme une activité suspecte qui a temporairement restreint l'envoi le temps de l'évaluer. En pratique, EOP renvoie un 4.7.500 quand l'une de ces conditions est remplie :
- Le débit d'envoi de votre IP vers ce tenant Microsoft (ou vers M365 dans son ensemble) dépasse ce qu'EOP est prêt à accepter à ce moment-là.
- La réputation de votre IP a assez baissé pour qu'EOP veuille vous ralentir sans vous bloquer purement et simplement.
- Le tenant a configuré un throttling agressif et vous l'avez atteint.
Le 4.7.501 est le même signal avec un déclencheur légèrement différent, en général un throttling davantage pondéré par la réputation.
Dans les trois cas, la classe SMTP est 4xx, donc votre MTA réessaie. Avec un MTA en bonne santé, vous finirez par livrer. Avec un MTA mal réglé, soit vous ralentirez trop (les e-mails expirent), soit vous réessaierez trop agressivement (Microsoft passe alors au blocage définitif 5.7.708).
Comment lire le signal
Si vous ne voyez des 4.7.500 / 4.7.501 qu'occasionnellement (disons sur moins de 0,5 % des tentatives vers M365), c'est le throttling de fond normal. Ignorez-le.
Si vous en voyez sur plus de 5 % des tentatives, c'est un signal de réputation :
- Votre IP est jaune ou rouge dans SNDS.
- Vous avez récemment fait grimper le volume d'un coup.
- Vous écrivez à une forte proportion de destinataires M365 inactifs.
- Vous tournez autour d'un seuil de taux de plaintes.
Une stratégie de nouvelles tentatives raisonnable
Un MTA bien réglé devrait faire ceci :
| Tentative | Délai après la précédente |
|---|---|
| 1 | Immédiat (envoi initial) |
| 2 | 15 minutes |
| 3 | 30 minutes |
| 4 | 1 heure |
| 5 | 2 heures |
| 6 | 4 heures |
| Plafond | 24 à 72 heures en file d'attente au total |
Si vous n'avez pas livré dans les 24 heures de nouvelles tentatives après un 4.7.500, considérez le message comme non délivrable pour cet envoi et arrêtez d'insister. Microsoft surveille les schémas de nouvelles tentatives, et des tentatives agressives depuis un expéditeur ralenti mènent vite à un blocage définitif.
Étapes de reprise
- Mettez en pause les envois agressifs vers Microsoft. Réduisez de 50 % le volume vers les adresses Microsoft pendant 48 heures.
- Consultez SNDS. Si vous êtes en jaune, vous avez une marge. Si vous êtes en rouge, vous êtes à quelques jours d'un blocage dur.
- Passez Domain Health et assurez-vous que SPF, DKIM et DMARC sont propres et alignés.
- Segmentez par engagement. Pendant la semaine qui vient, n'écrivez qu'aux destinataires qui ont ouvert un e-mail dans les 30 derniers jours.
- Vérifiez la réputation en amont avec le vérificateur de blacklists. Les listages Spamhaus vont souvent de pair avec une escalade du throttling d'EOP.
- Examinez les en-têtes des e-mails récemment livrés chez M365 avec l'analyseur d'en-têtes e-mail. Un SCL / BCL en hausse est l'indicateur avancé.
4.7.500, 4.4.7 ou 5.7.708
| Code | Signification | Action |
|---|---|---|
| 4.7.500 | Ralenti (temporaire) | Ralentir, réessayer raisonnablement |
| 4.4.7 | Message expiré dans la file d'attente | Chercher pourquoi les nouvelles tentatives n'ont pas abouti |
| 5.7.708 | Blocage définitif de l'IP | Arrêter les nouvelles tentatives ; corriger ; ouvrir un dossier de support |
Les causes que je rencontre souvent
- Un nouveau client sur IP partagée, ajouté au pool de votre ESP, a fait plonger la réputation commune.
- Un import de liste sans vérification, qui provoque des pics soudains de plaintes et de bounces.
- Un système transactionnel réutilisé pour le marketing sans warm-up.
- Une boucle de nouvelles tentatives mal configurée qui martèle un seul tenant Microsoft.
FAQ
Faut-il réessayer un 4.7.500 immédiatement ? Non. Réessayez avec un backoff exponentiel (en commençant à 15 minutes). Des nouvelles tentatives immédiates aggravent la situation.
Changer d'IP corrige-t-il le 4.7.500 ? Cela peut masquer le symptôme, mais ne corrige pas la cause. Si vous changez d'IP en gardant le même comportement d'envoi, la nouvelle IP sera ralentie en quelques jours.
Microsoft publie-t-il ses seuils de throttling ? Non. Les seuils varient selon le tenant et selon la réputation globale de l'expéditeur.
À lire aussi
- Le 550 5.7.708 Access Denied décrypté
- Pourquoi vos e-mails arrivent dans le courrier indésirable d'Outlook
Sources
- Email nondelivery reports and SMTP errors in Exchange Online (Microsoft Learn), les codes 4.7.500-699 comme restriction temporaire, le 4.4.7 comme message expiré dans la file d'attente, et le 5.7.708 comme trafic refusé depuis l'IP.
- Fix NDR error codes 550 5.7.703, 5.7.705, 5.7.708 and 5.7.750 (Microsoft Learn), Microsoft désigne une IP de faible réputation comme cause du 5.7.708.
- Anti-spam message headers (Microsoft Learn), où EOP inscrit les valeurs SCL et BCL que vous lisez dans les e-mails livrés.
- RFC 5321: Simple Mail Transfer Protocol, une réponse 4xx est transitoire, le client doit espacer ses nouvelles tentatives, et le délai d'abandon est en général d'au moins 4 à 5 jours.