Transformez vos e-mails en revenus avec Brew.
Décodez les réponses 451 4.7.500, 4.7.650, RP-001 et 550 5.7.515 de Microsoft, distinguez un incident Outlook d’un problème de réputation et sachez quoi éviter.
Un report Microsoft est un refus SMTP temporaire, c’est-à-dire une réponse qui commence par 4, qu’un serveur Outlook.com ou Microsoft 365 renvoie quand il refuse de prendre votre message pour le moment. Votre serveur doit le conserver et réessayer. Le plus connu est 451 4.7.500 Server busy. Please try again later, et ce même code peut signifier « vos envois ont l’air suspects » comme « Microsoft passe une mauvaise journée ».
Le 4 septembre 2026, c’était le second cas, et au moins un opérateur expérimenté a passé la matinée à chercher du côté du premier. Voici comment les distinguer.
*.olc.protection.outlook.com désigne la messagerie grand public Outlook.com, *.mail.protection.outlook.com un tenant Microsoft 365. Documentation différente, recours différents.550 5.7.515 est toujours à corriger de votre côté.Microsoft exploite deux systèmes de réception.
Outlook.com est la messagerie grand public : outlook.com, hotmail.com, live.com et msn.com, avec des hôtes MX comme hotmail-com.olc.protection.outlook.com. Elle dispose du site Postmaster d’Outlook.com, de SNDS pour la réputation et de son propre formulaire d’assistance aux expéditeurs.
Microsoft 365 (Exchange Online) héberge les boîtes aux lettres professionnelles. Les e-mails destinés à acme.com arrivent sur acme-com.mail.protection.outlook.com. Les erreurs sont documentées sur Microsoft Learn, les demandes de déblocage passent par sender.office.com, et ce sont les admins du destinataire qui décident de la façon dont leur tenant vous traite.
Le nom de domaine ne vous dira pas lequel des deux vous atteignez. La réponse, si. Dans cette ligne de journal publiée sur mailop le 4 septembre, l’hôte relay= est un tenant Microsoft 365 :
relay=xxxx-com.mail.protection.outlook.com[52.101.10.16]:25, dsn=4.7.500,
status=deferred (host xxx-com.mail.protection.outlook.com[52.101.10.16] said:
451 4.7.500 Server busy. Please try again later from [199.89.3.6]. (S77714)
[BN2PEPF000055E1.namprd21.prod.outlook.com 2026-09-04T10:28:53.346Z ...]
(in reply to end of DATA command))Lisez le code de base (451), le code de statut étendu (4.7.500) et le sous-code entre parenthèses, comme (S77714). Microsoft ne publie pas les sous-codes S, mais quand de nombreux expéditeurs signalent le même au même moment, c’est un signal.
| Réponse | Où | Ce que dit la documentation de Microsoft | Premier réflexe |
|---|---|---|---|
451 4.7.500 Server busy. Please try again later from [IP]. (S77714) |
Microsoft 365 | Learn classe 4.7.500-699 sous « Access denied, please try again later » : activité suspecte, envoi temporairement restreint. | Laissez la file d’attente réessayer. Vérifiez d’abord le périmètre touché. |
451 4.7.500-699 (ASxxx) |
Microsoft 365 | Limitation de débit appliquée à l’IP qui se connecte quand elle « a modifié ses habitudes d’envoi en envoyant un volume beaucoup plus élevé ». | Ralentissez la montée en charge. La limitation se lève « sur une période de quelques jours ». |
451 4.7.650 ... temporarily rate limited due to IP reputation (S775) |
Outlook.com | Absent du tableau publié par Microsoft. | Réduisez le volume et le parallélisme, puis consultez SNDS. |
451 4.7.652 ... exceeded the maximum number of connections (S3115) |
Outlook.com | Absent du tableau. Le texte nomme la cause. | Ouvrez moins de connexions. |
421 RP-001, RP-002, RP-003 |
Outlook.com | Dépassement des limites de débit, de débit par connexion et de connexions, « liées à la réputation de l’IP ou du domaine ». | Limitez le débit, puis consultez SNDS. |
550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level. |
Outlook.com | Le domaine envoie plus de 5 000 e-mails par jour et ne satisfait pas aux exigences SPF, DKIM et DMARC. | Corrigez l’authentification et l’alignement. |
550 5.7.1 ... part of their network is on our block list (S3150) |
Outlook.com | Blocage de votre IP ou de votre plage d’adresses. | Cessez d’envoyer depuis cette IP et ouvrez un ticket. |
550 SC-001, SC-004, OU-002 et codes similaires |
Outlook.com | Rejets au titre des règles sur le contenu, la réputation ou les plaintes. SC-004 renvoie à JMRP. | Trouvez la cause avant de reprendre. |
550 5.7.606-649 Access denied, banned sending IP [IP] |
Microsoft 365 | L’IP figure sur la liste des expéditeurs bloqués. | Demandez le retrait sur sender.office.com. |
550 5.7.511 Access denied, banned sender |
Microsoft 365 | Nécessite une enquête manuelle. | Transférez le rapport de non-remise (NDR) à delist@microsoft.com. |
Sources : la référence des NDR d’Exchange Online de Microsoft, son article sur ASxxx, le tableau des codes du site Postmaster et l’article sur 550 5.7.515 ; Al Iverson sur S775 et S3115 ; Twilio SendGrid sur les blocages S3140/S3150.
Les Sender Best Common Practices du M3AAWG indiquent qu’après un échec temporaire, « l’expéditeur devrait fermer la connexion et en ouvrir une nouvelle plus tard », et qu’un expéditeur ne doit jamais traiter un échec temporaire comme définitif. Les règles de Microsoft pour les expéditeurs, à propos des 5xx : « l’expéditeur ne doit pas tenter de retransmettre ce message à ce destinataire ».
Un 451 n’est pas un rebond. Si votre plateforme ou un script le traite comme tel, corrigez cela en premier.
Les consignes de Microsoft sur 4.7.500 vous renvoient à vos propres envois. C’est généralement la bonne piste, mais pas toujours.
Qboxmail a indiqué sur mailop que le problème « a commencé à 9 h 47 CEST sur toutes nos IP à la fois », avec les sous-codes S77714, S77717 et S77719. La page de statut de Poppulo citait l’identifiant d’incident de Microsoft, EX1467029, à partir de 11 h 19 BST.
Selon le compte rendu d’emailexpert du 10 septembre, un opérateur a d’abord accusé des coupures de fibre, jusqu’à ce que One.com, Qboxmail, Mailjet et Poppulo signalent les mêmes codes sur toutes leurs IP d’envoi et dans toutes les régions. Microsoft a mis en cause un modèle antispam, puis une règle de limitation de débit qui continuait de se déclencher pendant le rétablissement. emailexpert n’a trouvé aucun rapport post-incident public. Une panne d’authentification distincte, MO1465074, a duré environ 67 heures, du 31 août au 3 septembre. Notre rapport de septembre couvre ces dix jours.
| Signal | Plutôt Microsoft | Plutôt vous |
|---|---|---|
| Chronologie | Toutes les IP sont touchées dans la même minute | Une seule IP ou un seul domaine, ou une hausse progressive |
| Autres fournisseurs | Normaux | Se dégradent aussi, ou plaintes en hausse |
| Autres expéditeurs | Même code sur mailop et sur les pages de statut | Personne d’autre n’en parle |
| Vos changements récents | Aucun | Hausse brutale du volume, nouvelle IP, nouvelle liste |
| SNDS | Vert, aucun blocage | Jaune ou rouge, plaintes, « Blocked » |
| Code | 4.7.500 avec un sous-code que d’autres signalent | RP-00x, 4.7.650, 5.7.515, S3150 |
Comment traiter une réponse de Microsoft, d’après sa documentation et les comptes rendus de l’incident de septembre 2026.
Smart Network Data Services (SNDS) est le portail gratuit de Microsoft qui indique la réputation de chaque IP auprès d’Outlook.com. La FAQ de SNDS liste ce qu’affiche chaque IP autorisée :
Les données « peuvent être absentes pour les IP qui ont envoyé moins de 100 messages le jour concerné ». Pour obtenir l’accès, demandez une IP, une plage ou un ASN : SNDS envoie un lien aux adresses qu’il trouve via le DNS inverse (postmaster@, abuse@) ou RDAP. Aucune demande manuelle n’est possible.
SNDS a été relancé en juin 2026. Al Iverson a noté le 19 juin que les Return-Path de JMRP n’identifient plus de façon fiable la campagne et le destinataire : encodez ces informations ailleurs. D’après la page d’accueil de SNDS (mise à jour le 22 septembre), l’accès expire 10 mois après l’approbation ou la migration, avec trois rappels. Notez la date dans votre agenda.
Le Junk Mail Reporting Program (JMRP), auquel on s’inscrit depuis SNDS, vous renvoie chaque message qu’un utilisateur d’Outlook.com marque comme indésirable, souvent « en 72 heures à peine » après l’inscription. Retirez les plaignants de toutes vos listes et inscrivez vos nouvelles IP au fur et à mesure que vous les ajoutez. Pour les IP partagées, que vous ne pouvez pas enregistrer, demandez à votre prestataire d’envoi ce qu’il surveille.
Outlook.com. Le formulaire d’assistance de la page de dépannage du site Postmaster exige un compte Microsoft, ne couvre que les quatre domaines grand public et « ne garantit pas » la délivrance. Twilio SendGrid (conseil d’un éditeur) recommande d’y indiquer votre domaine, vos IP, une description du flux, le texte du rebond et des captures d’écran de SNDS, de répondre à la première réponse automatique en demandant une escalade, et de demander votre quota de volume ainsi qu’un réexamen de votre Volume-Based Limit.
Microsoft 365. Pour 5.7.606-649, utilisez le portail de retrait de liste sur sender.office.com : une adresse et une IP par visite, avec confirmation par e-mail. Le retrait « peut prendre jusqu’à 24 heures, voire plus ». Pour 5.7.511, envoyez le rapport de non-remise à delist@microsoft.com et comptez sur une réponse sous 48 heures.
Une limitation ASxxx ne se lève pas par une demande de retrait. Si l’entreprise destinataire filtre ses e-mails entrants via un service tiers avant Microsoft 365, l’article de Learn indique qu’un connecteur configuré par son admin supprime la limitation. Sinon, elle disparaît à mesure que vous construisez un historique.
Réessayez selon un calendrier. La RFC 5321, section 4.5.4.1 indique que « l’intervalle entre deux tentatives DEVRAIT (SHOULD) être d’au moins 30 minutes » et que le délai d’abandon « doit généralement être d’au moins 4 à 5 jours », avec deux tentatives dans la première heure, puis une toutes les deux ou trois heures. Ne le raccourcissez pas pour un envoi urgent.
Limitez le débit par destination. Selon le M3AAWG, les serveurs de réception s’attendent à un ajustement « global, pour tous les e-mails que leur envoie une même adresse IP ». Quand Microsoft diffère vos e-mails, ralentissez tout ce qui part vers cette famille de MX (Outlook.com ou Microsoft 365).
Surveillez les connexions. Les règles d’Outlook.com précisent que les expéditeurs « ne doivent pas ouvrir plus de 500 connexions simultanées » sans accord préalable. C’est un plafond, et un 4.7.652 (S3115) signifie que vous dépassez le vôtre.
Montez en charge progressivement sur les nouvelles IP et les nouveaux domaines. Selon Microsoft, une nouvelle IP « peut s’attendre à atteindre son plein régime en quelques semaines, voire moins », selon le volume, l’exactitude de la liste et les plaintes. Les nouvelles IP couvertes par un enregistrement SPF existant héritent d’une partie de la réputation du domaine. Commencez par les contacts récemment engagés.
5.7.515.Pour l’alignement DMARC et le passage de p=none à une politique appliquée, consultez notre guide de la délivrabilité. Pour que vos réinitialisations de mot de passe et vos reçus continuent de passer, notre guide des e-mails transactionnels explique comment les placer sur leur propre domaine.
Brew gère l’infrastructure d’envoi et réessaie après les échecs temporaires : vous n’avez jamais à régler de files d’attente ni de limites de connexions. Voici ce que vous voyez :
delivery_delayed), et le destinataire passe d’accepté à différé, puis à délivré ou à rebond. Dans Événements, recherchez « différé », puis tapez @hotmail.com ou @outlook.com pour vous limiter à Outlook.com (les filtres de domaine se combinent avec un OU ; les destinataires Microsoft 365 utilisent leurs propres domaines). L’événement indique que le message est en attente, pas pourquoi.deliveryDelayed et pending à côté des e-mails délivrés et des rebonds. get_email_analytics fait de même via MCP.get_domain_health. Un test de placement en boîte de réception (10 crédits) envoie vers des boîtes témoins chez Gmail, Outlook, Yahoo, Apple et d’autres.Brew ne propose pas encore de webhooks de délivrance ni de données SNDS ou JMRP (les décomptes par fournisseur s’obtiennent avec l’API des événements et groupBy=recipientDomain) : utilisez les portails de Microsoft pour la réputation. Pendant un incident Microsoft présumé, nous laisserions l’envoi tel quel et regarderions les événements « Différé » devenir « Délivré ».
C’est un refus temporaire de Microsoft 365 (Exchange Online), répertorié sous « Access denied, please try again later » après une activité suspecte. En général, vos habitudes d’envoi ont changé, mais le 4 septembre 2026, il s’agissait d’un incident Microsoft (EX1467029). Laissez votre serveur réessayer et vérifiez si d’autres expéditeurs le voient aussi.
Selon Microsoft, la limitation liée aux habitudes d’envoi se résorbe « sur une période de quelques jours », à mesure que vous construisez un historique, et un retrait de liste peut prendre jusqu’à 24 heures, voire plus. Continuez à réessayer pendant au moins 4 à 5 jours, comme le recommande la RFC 5321 : la plupart des e-mails différés finissent quand même par être délivrés.
Outlook.com rejette les e-mails des domaines qui en envoient plus de 5 000 par jour sans respecter ses règles d’authentification, appliquées depuis le 5 mai 2025. SPF et DKIM doivent réussir, le domaine doit publier DMARC (p=none suffit), et SPF ou DKIM doit être aligné sur le domaine From.
Non. Selon Microsoft, les nouvelles IP n’ont aucune réputation et risquent davantage de rencontrer des problèmes. Corrigez la cause, demandez le retrait de la liste de blocage et remontez progressivement en charge sur l’IP dont vous disposez.
Non. Le M3AAWG indique qu’un expéditeur ne doit pas traiter un 4xx comme définitif. Il ne devient un rebond que si les nouvelles tentatives sont épuisées ou si le serveur renvoie un 5xx. Dans Brew, un report apparaît comme un événement « Différé », et un contact n’est exclu qu’après des rebonds temporaires répétés.
