# Microsoft 451 4.7.500 : le plan d’action face aux reports

URL canonique : https://brew.new/fr/blog/microsoft-451-4-7-500-deferrals-playbook
Rédigé par Thomas Park
Publication : 2026-10-05
Mise à jour : 2026-10-05

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.

## À retenir

- Lisez d’abord l’hôte. `*.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.
- Un 4xx signifie qu’il faut mettre en file d’attente et réessayer : la RFC 5321 préconise au moins 30 minutes entre deux tentatives, pendant au moins 4 à 5 jours. Un 5xx signifie qu’il faut arrêter : les règles de Microsoft interdisent de le retenter.
- Si toutes vos IP reçoivent le même code Microsoft dans la même minute alors que Gmail et Yahoo fonctionnent normalement, soupçonnez Microsoft et consultez mailop avant de changer quoi que ce soit.
- Depuis le 5 mai 2025, Outlook.com impose SPF, DKIM et DMARC aux domaines qui envoient plus de 5 000 messages par jour. Un `550 5.7.515` est toujours à corriger de votre côté.
- Inscrivez dès maintenant vos IP d’envoi à SNDS et à JMRP. L’accès à SNDS expire au bout de 10 mois si vous ne renouvelez pas votre attestation.
- Ne réessayez pas plus agressivement, ne basculez pas sur de nouvelles IP et n’excluez pas les contacts dont les e-mails sont différés.

## D’abord, identifiez à quel Microsoft vous avez affaire

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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting), 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](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), 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](https://www.mail-archive.com/mailop@mailop.org/msg27209.html) le 4 septembre, l’hôte `relay=` est un tenant Microsoft 365 :

```text
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))
```

## Décodez la réponse

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](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online) de Microsoft, son [article sur ASxxx](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-451-4-7-500-699-asxxx-in-exchange-online), le tableau des codes du site Postmaster et l’[article sur 550 5.7.515](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com) ; Al Iverson sur [S775](https://www.spamresource.com/2026/02/microsoft-rate-limiting-issues.html) et [S3115](https://www.spamresource.com/2025/07/microsoft-says-too-many-connections.html) ; Twilio SendGrid sur les [blocages S3140/S3150](https://support.sendgrid.com/hc/en-us/articles/38465017420955-Troubleshooting-Microsoft-Delivery-Issues-With-Error-550-5-7-1-S3140-S3150-Blocks).

### Le 4 ou le 5 vous dit quoi faire

Les [Sender Best Common Practices du M3AAWG](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf) 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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies), à 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.

## Incident Microsoft ou problème de réputation

Les consignes de Microsoft sur 4.7.500 vous renvoient à vos propres envois. C’est généralement la bonne piste, mais pas toujours.

### À quoi ressemblait le 4 septembre 2026

Qboxmail [a indiqué sur mailop](https://www.mail-archive.com/mailop@mailop.org/msg27208.html) 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](https://poppulo1.statuspage.io/incidents/w0671ycn23fw) 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](https://emailexpert.com/microsofts-ten-days-three-exchange-online-incidents-three-causes/), 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](/fr/blog/state-of-email-september-2026) couvre ces dix jours.

### Cinq vérifications avant d’agir

1. **Le périmètre touché chez vous.** Un problème de plateforme touche en quelques minutes toutes les IP, tous les domaines et tous les flux. Un problème de réputation commence généralement sur un seul.
2. **Les autres fournisseurs.** Si Gmail, Yahoo et Apple acceptent normalement vos e-mails et que d’autres expéditeurs signalent le même code Microsoft, la cause se trouve probablement chez Microsoft.
3. **Vos 72 dernières heures.** Un pic de volume, une nouvelle IP, une liste importée, une modification DNS ou un envoi de réactivation sont à corriger dans tous les cas.
4. **Renseignez-vous.** Consultez les archives de mailop et les pages de statut. Un admin Microsoft 365 peut ouvrir **Intégrité > Intégrité du service** (**Health > Service health** en anglais), dont l’[historique des problèmes](https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health) couvre les incidents publiés sur votre tenant au cours des 7 ou 30 derniers jours. C’est là que Poppulo a trouvé EX1467029.
5. **SNDS.** Un statut vert, sans blocage, alors que les reports s’accumulent, indique que le problème ne vient pas de vous.

| 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 |

![Logigramme de décision pour les réponses de Microsoft : les codes 5xx mènent à la correction de l’authentification, au portail de retrait de liste ou à un ticket d’assistance ; les codes 4xx mènent à une vérification d’incident, puis soit à l’attente, soit à la limitation du débit et à la consultation de SNDS.](/images/blog/microsoft-451-4-7-500-deferrals-playbook-flowchart.png)

*Comment traiter une réponse de Microsoft, d’après sa documentation et les comptes rendus de l’incident de septembre 2026.*

## SNDS et JMRP : configurez-les avant d’en avoir besoin

[Smart Network Data Services](https://substrate.office.com/ip-domain-management-snds/snds) (SNDS) est le portail gratuit de Microsoft qui indique la réputation de chaque IP auprès d’Outlook.com. La [FAQ de SNDS](https://substrate.office.com/ip-domain-management-snds/SNDS/FAQ) liste ce qu’affiche chaque IP autorisée :

- **Résultat du filtrage.** Vert : moins de 10 % de verdicts spam ; jaune : de 10 % à 90 % ; rouge : plus de 90 %.
- **Taux de plainte** : le nombre de plaintes rapporté au nombre de destinataires. Plus de 30 % des IP restent sous 0,3 %, « un bon niveau à viser ».
- **Commandes RCPT et destinataires des messages.** Un écart important signale des listes obsolètes.
- **Statut de l’IP** : Blocked, Bot ou Junked.

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](https://www.spamresource.com/2026/06/snds-and-jmrp-in-transition.html) 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](https://substrate.office.com/ip-domain-management-snds/Postmaster/Services) (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.

## Assistance aux expéditeurs et demandes de retrait

**Outlook.com.** Le formulaire d’assistance de la [page de dépannage du site Postmaster](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting) 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](https://learn.microsoft.com/en-us/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself) 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éessayer, limiter le débit, monter en charge

**Réessayez selon un calendrier.** La [RFC 5321, section 4.5.4.1](https://www.rfc-editor.org/rfc/rfc5321.html#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.

## Ce qu’il ne faut pas faire

- **Réessayer plus agressivement.** Vider la file d’attente toutes les quelques minutes accumule les connexions sur une IP que Microsoft veut ralentir, et vous vaut un 4.7.652.
- **Changer d’IP pour contourner le problème.** Les nouvelles IP n’ont aucune réputation et risquent davantage de rencontrer des problèmes, et répartir ses envois sur des IP neuves, c’est précisément la technique des spammeurs « snowshoe ».
- **Retenter un 5xx.** Microsoft l’interdit, et après « plusieurs réponses de non-remise », vous devez cesser d’écrire à ce destinataire.
- **Exclure les contacts différés.** L’adresse est toujours valide.
- **Renvoyer l’e-mail aux destinataires différés.** Leurs messages sont toujours en file d’attente : vous enverriez des doublons.
- **Modifier le DNS dans la panique.** Changer SPF ou DKIM en plein incident ajoute un second problème, sauf si vous avez reçu un `5.7.515`.

Pour l’alignement DMARC et le passage de `p=none` à une politique appliquée, consultez notre [guide de la délivrabilité](/fr/blog/email-deliverability). Pour que vos réinitialisations de mot de passe et vos reçus continuent de passer, notre [guide des e-mails transactionnels](/fr/blog/transactional-emails) explique comment les placer sur leur propre domaine.

## Comment cela se présente dans Brew

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 :

- **Événements « Différé ».** Un report enregistre un événement « Différé » (`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.
- **Détails du rebond.** Les **Métadonnées** d’un événement de rebond contiennent le type de rebond et le message du fournisseur.
- **Décomptes via l’API.** La [vue d’ensemble des statistiques](https://docs.brew.new/api-reference/public-v1/analytics/brand-overview-totals-rates-timeseries) renvoie `deliveryDelayed` et `pending` à côté des e-mails délivrés et des rebonds. `get_email_analytics` fait de même via MCP.
- **Des exclusions qui respectent les 4xx.** Les rebonds définitifs et les plaintes entraînent une exclusion immédiate. Les rebonds temporaires n’entraînent une exclusion qu’après trois occurrences en 30 jours.
- **Montée en charge.** L’[envoi progressif](https://docs.brew.new/create-emails/send-options#gradual-send) divise un gros envoi en lots horaires ou quotidiens, exprimés en pourcentage, que vous pouvez mettre en pause si Outlook.com commence à différer vos e-mails.
- **Santé du domaine.** La carte **Délivrabilité** de chaque domaine attribue un score de 0 à 100 qui couvre le placement en boîte de réception, la réputation, l’authentification, le contenu et la configuration d’envoi ; il est aussi disponible via l’outil 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é ».

## Questions fréquentes

### Que signifie 451 4.7.500 Server busy chez Outlook ou Microsoft 365 ?

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.

### Combien de temps Microsoft va-t-il différer mes e-mails ?

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.

### Qu’est-ce que l’erreur 550 5.7.515 et comment la corriger ?

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.

### Faut-il changer d’adresse IP si Microsoft bloque la mienne ?

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.

### Les reports de Microsoft comptent-ils comme des rebonds ?

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.