# Microsoft 451 4.7.500 deferrals: a sender playbook

Canonical: https://brew.new/blog/microsoft-451-4-7-500-deferrals-playbook
Author: Thomas Park
Published: 2026-10-05
Updated: 2026-10-05

A Microsoft deferral is a temporary SMTP refusal, a response starting with 4, that Outlook.com or a Microsoft 365 server sends when it won't take your message right now. Your server should keep it and retry. The best known is `451 4.7.500 Server busy. Please try again later`, and the same code can mean "your sending looks suspicious" or "Microsoft is having a bad day".

On September 4, 2026 it meant the second, and at least one experienced operator spent the morning chasing the first. Here's how to tell them apart.

## Key takeaways

- Read the host first. `*.olc.protection.outlook.com` is Outlook.com consumer mail, `*.mail.protection.outlook.com` is a Microsoft 365 tenant. Different docs, different escalation.
- A 4xx means queue and retry: RFC 5321 says at least 30 minutes apart, for at least 4 to 5 days. A 5xx means stop. Microsoft's policies forbid retrying it.
- If every IP gets the same Microsoft code in the same minute while Gmail and Yahoo are fine, suspect Microsoft and check mailop before changing anything.
- Since May 5, 2025, Outlook.com has enforced SPF, DKIM and DMARC for domains sending 5,000 or more messages a day. `550 5.7.515` is always yours to fix.
- Register sending IPs in SNDS and JMRP now. SNDS access expires after 10 months unless you reattest.
- Don't retry harder, rotate to fresh IPs or suppress deferred contacts.

## First, find out which Microsoft you are talking to

Microsoft runs two receiving systems.

**Outlook.com** is consumer mail: `outlook.com`, `hotmail.com`, `live.com` and `msn.com`, with MX hosts like `hotmail-com.olc.protection.outlook.com`. It has the [Outlook.com Postmaster site](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting), SNDS for reputation and its own sender support form.

**Microsoft 365** (Exchange Online) hosts business mailboxes. Mail for `acme.com` goes to `acme-com.mail.protection.outlook.com`. Errors are documented on [Microsoft Learn](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), blocks go through `sender.office.com`, and the recipient's admins control how their tenant treats you.

The domain name won't tell you which one you're hitting. The response will. In this log line [posted to mailop](https://www.mail-archive.com/mailop@mailop.org/msg27209.html) on September 4, the `relay=` host is a Microsoft 365 tenant:

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

## Decode the response

Read the basic code (`451`), the enhanced code (`4.7.500`) and the bracketed subcode like `(S77714)`. Microsoft doesn't publish S-subcodes, but many senders reporting the same one at once is a signal.

| Response | Where | What Microsoft's docs say | First move |
|---|---|---|---|
| `451 4.7.500 Server busy. Please try again later from [IP]. (S77714)` | Microsoft 365 | Learn lists 4.7.500-699 as "Access denied, please try again later": suspicious activity, sending temporarily restricted. | Let the queue retry. Check scope first. |
| `451 4.7.500-699 (ASxxx)` | Microsoft 365 | IP throttling when the connecting IP "changed its previous email sending patterns by sending a much higher volume". | Slow the ramp. It clears "over a period of a few days". |
| `451 4.7.650 ... temporarily rate limited due to IP reputation (S775)` | Outlook.com | Not in Microsoft's published table. | Cut volume and concurrency, then check SNDS. |
| `451 4.7.652 ... exceeded the maximum number of connections (S3115)` | Outlook.com | Not in the table. The text names the cause. | Open fewer connections. |
| `421 RP-001`, `RP-002`, `RP-003` | Outlook.com | Rate, per-connection rate and connection limits exceeded, "related to IP/domain reputation". | Throttle, then check SNDS. |
| `550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.` | Outlook.com | Domain sends 5,000+ a day and fails the SPF, DKIM and DMARC requirement. | Fix authentication and alignment. |
| `550 5.7.1 ... part of their network is on our block list (S3150)` | Outlook.com | Block on your IP or range. | Stop sending from that IP and open a ticket. |
| `550 SC-001`, `SC-004`, `OU-002` and similar | Outlook.com | Policy rejections for content, reputation or complaints. SC-004 points to JMRP. | Find the cause before resuming. |
| `550 5.7.606-649 Access denied, banned sending IP [IP]` | Microsoft 365 | IP is on the blocked senders list. | Request removal at `sender.office.com`. |
| `550 5.7.511 Access denied, banned sender` | Microsoft 365 | Needs manual investigation. | Forward the NDR to `delist@microsoft.com`. |

Sources: Microsoft's [Exchange Online NDR reference](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/non-delivery-reports-in-exchange-online), [ASxxx article](https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/fix-error-code-451-4-7-500-699-asxxx-in-exchange-online), Postmaster code table and [550 5.7.515 article](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com); Al Iverson on [S775](https://www.spamresource.com/2026/02/microsoft-rate-limiting-issues.html) and [S3115](https://www.spamresource.com/2025/07/microsoft-says-too-many-connections.html); Twilio SendGrid on [S3140/S3150 blocks](https://support.sendgrid.com/hc/en-us/articles/38465017420955-Troubleshooting-Microsoft-Delivery-Issues-With-Error-550-5-7-1-S3140-S3150-Blocks).

### The 4 versus the 5 is the instruction

[M3AAWG's Sender Best Common Practices](https://www.m3aawg.org/sites/default/files/document/M3AAWG_Senders_BCP_Ver3-2015-02.pdf) say that after a temporary failure "the sender should close the connection and open a new connection later", and that senders must never treat a tempfail as permanent. Microsoft's [sender policies](https://substrate.office.com/ip-domain-management-snds/Postmaster/Policies) on 5xx: "the sender must not attempt to retransmit that message to that recipient."

A 451 is not a bounce. If your platform or a script treats it as one, fix that first.

## Microsoft incident or your reputation

Microsoft's 4.7.500 guidance points you at your own sending. Usually that's right, but not always.

### What September 4, 2026 looked like

Qboxmail [told mailop](https://www.mail-archive.com/mailop@mailop.org/msg27208.html) the problem "started at 9:47 CEST on all our IPs at once", with subcodes S77714, S77717 and S77719. Poppulo's [status page](https://poppulo1.statuspage.io/incidents/w0671ycn23fw) quoted Microsoft's incident ID, EX1467029, starting 11:19 BST.

Per emailexpert's [September 10 write-up](https://emailexpert.com/microsofts-ten-days-three-exchange-online-incidents-three-causes/), one operator blamed fiber cuts until One.com, Qboxmail, Mailjet and Poppulo reported the same codes across every sending IP and region. Microsoft blamed an anti-spam model, then a throttling rule still firing during recovery. emailexpert found no public post-incident report. A separate authentication fault, MO1465074, ran about 67 hours from August 31 to September 3. Our [September report](/blog/state-of-email-september-2026) covers those ten days.

### Five checks before you act

1. **Your own scope.** Platform problems hit every IP, domain and stream within minutes. Reputation problems usually start on one.
2. **Other providers.** If Gmail, Yahoo and Apple accept normally and other senders report the same Microsoft code, the cause is probably Microsoft.
3. **Your last 72 hours.** A volume spike, new IP, imported list, DNS edit or reactivation send needs fixing regardless.
4. **Ask around.** Check the mailop archive and status pages. A Microsoft 365 admin can open **Health > Service health**, whose [Issue history](https://learn.microsoft.com/en-us/microsoft-365/enterprise/view-service-health) covers the last 7 or 30 days of incidents posted to your tenant. That's where Poppulo found EX1467029.
5. **SNDS.** Green with no blocks while deferrals pile up points away from you.

| Signal | Points to Microsoft | Points to you |
|---|---|---|
| Timing | Every IP starts in the same minute | One IP or domain, or a gradual climb |
| Other providers | Normal | Also degrading, or complaints rising |
| Other senders | Same code on mailop and status pages | Nobody else talking about it |
| Your recent changes | None | Volume jump, new IP, new list |
| SNDS | Green, no block | Yellow or red, complaints, "Blocked" |
| Code | 4.7.500 with a subcode others report | RP-00x, 4.7.650, 5.7.515, S3150 |

![A decision flowchart for Microsoft responses: 5xx codes route to fixing authentication, the delist portal or a support ticket; 4xx codes route to an incident check, then either waiting it out or throttling and checking SNDS.](/images/blog/microsoft-451-4-7-500-deferrals-playbook-flowchart.png)

*Routing a Microsoft response, from Microsoft's docs and the September 2026 incident reports.*

## SNDS and JMRP: set them up before you need them

[Smart Network Data Services](https://substrate.office.com/ip-domain-management-snds/snds) (SNDS) is Microsoft's free per-IP reputation portal for Outlook.com. The [SNDS FAQ](https://substrate.office.com/ip-domain-management-snds/SNDS/FAQ) lists what each authorized IP shows:

- **Filter result.** Green is under 10% spam verdicts, yellow 10% to 90%, red over 90%.
- **Complaint rate**, complaints over recipients. More than 30% of IPs stay under 0.3%, "a good bar to shoot for."
- **RCPT commands versus message recipients.** A big gap means stale lists.
- **IP status**: Blocked, Bot or Junked.

Data "may not be present for IPs which sent less than 100 messages on the given day." To get access, request an IP, range or ASN, and SNDS emails a link to addresses it finds via reverse DNS (`postmaster@`, `abuse@`) or RDAP. No manual requests.

SNDS relaunched in June 2026. Al Iverson [noted on June 19](https://www.spamresource.com/2026/06/snds-and-jmrp-in-transition.html) that JMRP return-paths no longer reliably identify campaign and recipient, so encode those elsewhere. Per the SNDS home page (updated September 22), access expires 10 months after approval or migration, with three reminders. Calendar it.

The [Junk Mail Reporting Program](https://substrate.office.com/ip-domain-management-snds/Postmaster/Services) (JMRP), enrolled inside SNDS, returns each message an Outlook.com user marks as junk, often "within as little as 72 hours" of enrolling. Remove complainers from every list and enroll new IPs as you add them. On shared IPs you can't register, ask your provider what it watches.

## Sender support and delisting

**Outlook.com.** The support form on the [Postmaster troubleshooting page](https://substrate.office.com/ip-domain-management-snds/Postmaster/Troubleshooting) needs a Microsoft account, covers only the four consumer domains, and "does not guarantee" delivery. Twilio SendGrid (vendor advice) says to include your domain, IPs, stream description, bounce text and SNDS screenshots, answer the automated first reply asking for escalation, and request your volume quota and a Volume-Based Limit review.

**Microsoft 365.** For `5.7.606-649`, use the [delist portal](https://learn.microsoft.com/en-us/defender-office-365/external-senders-use-the-delist-portal-to-unblock-yourself) at `sender.office.com`: one address and one IP per visit, confirmed by email. Removal "might take up to 24 hours or longer." For `5.7.511`, email the NDR to `delist@microsoft.com`, and expect a reply within 48 hours.

An ASxxx throttle has no delist. If the recipient company filters inbound mail through a third party before Microsoft 365, the Learn article says a connector set up by its admin removes the throttling. Otherwise it clears as you build history.

## Retry, throttle and ramp

**Retry on a schedule.** [RFC 5321, section 4.5.4.1](https://www.rfc-editor.org/rfc/rfc5321.html#section-4.5.4.1) says "the retry interval SHOULD be at least 30 minutes" and the give-up time "generally needs to be at least 4-5 days," with two attempts in the first hour, then one every two or three hours. Don't shorten it for an urgent send.

**Throttle per destination.** M3AAWG says receivers expect adjustment "as a wholesale process for all emails sent to them by the same IP address." When Microsoft defers, slow everything to that MX family (Outlook.com or Microsoft 365).

**Watch connections.** Outlook.com policy says senders "must not open more than 500 simultaneous connections" without prior arrangement. That's a ceiling, and a `4.7.652 (S3115)` means you're over yours.

**Ramp new IPs and domains.** Microsoft says a new IP "can expect to be fully ramped within a couple of weeks or sooner," depending on volume, list accuracy and complaints. New IPs covered by an existing SPF record inherit some domain reputation. Start with recent engagers.

## What not to do

- **Retry harder.** Flushing the queue every few minutes piles connections onto an IP Microsoft wants slowed, and earns you a 4.7.652.
- **Switch IPs to dodge it.** New IPs have no reputation and are more likely to have problems, and spreading mail across fresh IPs is what snowshoe spammers do.
- **Retry a 5xx.** Microsoft forbids it, and after "multiple non-delivery responses" you must stop sending to that recipient.
- **Suppress deferred contacts.** The address is still valid.
- **Re-send to deferred recipients.** Their messages are still queued. You'd send duplicates.
- **Edit DNS in a panic.** Changing SPF or DKIM mid-incident adds a second problem, unless you got a `5.7.515`.

For DMARC alignment and moving from `p=none` to enforcement, see our [deliverability guide](/blog/email-deliverability). To keep password resets and receipts moving, our [transactional email guide](/blog/transactional-emails) covers putting them on their own domain.

## How this looks in Brew

Brew runs the sending infrastructure and retries temporary failures, so you never tune queues or connection limits. What you see:

- **Delayed events.** A deferral records a Delayed event (`delivery_delayed`), and the recipient moves from accepted to delayed, then delivered or bounced. In **Events**, search "delayed", then type `@hotmail.com` or `@outlook.com` to narrow to Outlook.com (domain filters combine with OR; Microsoft 365 recipients use their own domains). The event says the message is waiting, not why.
- **Bounce details.** A bounced event's Metadata holds the bounce type and provider message.
- **Counts over the API.** The [analytics overview](https://docs.brew.new/api-reference/public-v1/analytics/brand-overview-totals-rates-timeseries) returns `deliveryDelayed` and `pending` beside delivered and bounced. `get_email_analytics` does the same over MCP.
- **Suppression that respects 4xx.** Hard bounces and complaints suppress immediately. Soft bounces suppress only after three within 30 days.
- **Ramping.** [Gradual send](https://docs.brew.new/create-emails/send-options#gradual-send) splits a large send into hourly or daily percentage batches you can pause if Outlook.com starts deferring.
- **Domain health.** Each domain's Deliverability card scores 0 to 100 across inbox placement, reputation, authentication, content and sending setup, also available via the `get_domain_health` MCP tool. An inbox placement test (10 credits) hits seed mailboxes at Gmail, Outlook, Yahoo, Apple and others.

Per-provider breakdowns, delivery webhooks and SNDS or JMRP data aren't in Brew yet, so use Microsoft's portals for reputation. During a suspected Microsoft incident, we'd leave the send alone and watch Delayed turn into Delivered.

## Frequently asked questions

### What does 451 4.7.500 Server busy mean from Outlook or Microsoft 365?

It's a temporary refusal from Microsoft 365 (Exchange Online), listed as "Access denied, please try again later" after suspicious activity. Usually your sending pattern changed, but on September 4, 2026 it was a Microsoft incident (EX1467029). Let your server retry and check whether other senders see it too.

### How long will Microsoft keep deferring my email?

Microsoft says pattern-based throttling resolves "over a period of a few days" as you build history, and delisting can take up to 24 hours or longer. Keep retrying for at least 4 to 5 days, as RFC 5321 recommends, and most deferred mail still delivers.

### What is 550 5.7.515 and how do I fix it?

Outlook.com rejects mail from domains sending 5,000 or more a day that miss its authentication rules, enforced since May 5, 2025. SPF and DKIM must pass, the domain must publish DMARC (`p=none` is enough), and SPF or DKIM must align with the From domain.

### Should I get a new IP address if Microsoft blocks mine?

No. Microsoft says new IPs have no reputation and are more likely to have problems. Fix the cause, request delisting and ramp back up on the IP you have.

### Do Microsoft deferrals count as bounces?

No. M3AAWG says senders must not treat a 4xx as permanent. It becomes a bounce only if retries run out or the server returns a 5xx. In Brew, a deferral shows as a Delayed event, and contacts are suppressed only after repeated soft bounces.