451 4.7.500 Server busy from Microsoft 365 — is it you or Microsoft?

Short answer: 451 4.7.500 Server busy. Please try again later from [x.x.x.x]. (S77719) is a temporary deferral from Exchange Online Protection, not a block and not a blacklist. If it appeared on nearly all of your sending IPs at the same time between 31 August and 4 September 2026, it was Microsoft's incident (EX1464935, then EX1467029), not your reputation — keep the queue retrying and change nothing. If it persists on one IP after other senders report normal delivery, Microsoft is rate-limiting that IP for reputation reasons, and the fix is on your side.

What the error actually says

The full response usually looks like one of these:

• 451 4.7.500 Server busy. Please try again later from [1.2.3.4]. (S77719)
• 451 4.7.500 Server busy. Please try again later from [1.2.3.4]. (S77714) or (S77717)

Three parts matter. 451 is a 4xx code: the receiving server is telling yours to retry, and a properly configured mail server will, automatically, for days. 4.7.500 is Microsoft's enhanced status for "server busy" throttling. The S-code in brackets identifies which internal throttling rule fired; S77714, S77717 and S77719 are all variants of the same connection-rate throttle rather than distinct problems. None of them is a reputation verdict by itself — the same code is returned both during Microsoft-side capacity incidents and when Microsoft is deliberately slowing a low-reputation IP.

The 31 August – 4 September 2026 incident

On 31 August 2026, senders worldwide began receiving 451 4.7.500 on nearly every IP sending into Microsoft 365, regardless of reputation. Microsoft tracked it as EX1464935, initially attributed to an expired certificate. Conditions were reported as improved, then a second wave on 4 September was tracked as EX1467029; European operators saw a sharp spike in reports around 11:00 UTC, with mail queues of thousands of messages backing up toward Microsoft 365 tenants. Microsoft's public status page showed no issue for much of that time. Operators reported improvement from about 15:00 UTC on 4 September, with residual "Server busy" deferrals continuing for several hours afterwards on some routes.

Two weeks earlier, from 14 to 17 August 2026, a different Microsoft-side event had increased 550 5.7.511 Access denied, banned sender rejections across shared ESP infrastructure — Twilio SendGrid reported block rates up 10 to 15 percent across its IP estate — before Microsoft applied mitigations on 17 August without publishing a cause. The pattern for 2026 is clear: Microsoft-side rejection events are recurring, they are rarely acknowledged in real time, and they look, from a single sender's logs, exactly like a reputation problem.

Is it you or Microsoft? A five-minute test

Check	Points to Microsoft	Points to you
Which IPs are affected?	All of them, at the same moment, including IPs with unrelated traffic	One IP, or one pool, while others deliver normally
Are other senders seeing it?	Yes — MailOp list threads, Downdetector spikes for Microsoft 365, admin forums within the hour	No — nobody else is reporting it
Which recipients?	Every Microsoft 365 tenant, including your own test tenant	Specific tenants, or Outlook.com/Hotmail but not corporate tenants
What changed on your side?	Nothing	New IP, new domain, volume spike, list import, or a template change in the last 48 hours
Microsoft 365 admin center service health (if you have a tenant)	An EX-numbered incident is listed, sometimes hours after it started	No incident listed and the deferrals continue for more than a day

Microsoft's rejection codes, side by side

Microsoft uses several codes that senders confuse with each other. They mean different things and call for different responses.

Response	Meaning	What to do
451 4.7.500 Server busy (S777xx)	Temporary throttling — capacity or reputation	Retry (automatic). Reduce concurrent connections. Diagnose with the test above.
451 4.7.650 The mail server [IP] has been temporarily rate limited due to IP reputation (S775)	Explicit reputation throttle on that IP	It's you. Slow down, check SNDS, fix authentication, warm the IP.
550 5.7.511 Access denied, banned sender	Permanent block of the sender (IP or domain) by Microsoft's filters	Not a retry. Identify the cause; ESP pool moves if shared.
550 5.7.606 – 5.7.649 Access denied, banned sending IP	IP on Microsoft's internal block list	The delist portal is for this code — Microsoft blocking guide.
550 5.7.1 ... [S3150]	Microsoft rejecting because the IP is on Spamhaus	Follow the Spamhaus removal guide.
550 5.7.708 Service unavailable. Access denied, traffic not accepted from this IP	Traffic blocked from an IP with no established reputation	See Microsoft 5.7.708.

What to do during a Microsoft-side incident

1. Change nothing. Don't rotate to a fresh IP or domain; new infrastructure entering mid-incident starts with no reputation and gets treated worse once Microsoft recovers.
2. Let the queue retry. A 4xx deferral is retried automatically. Most mail servers keep trying for one to five days; don't shorten that. The queue drains on its own when Microsoft recovers.
3. Reduce concurrency, not volume. If your platform lets you, lower the number of simultaneous connections to Microsoft destinations. Fewer parallel connections hitting the throttle means fewer deferrals and a faster drain.
4. Pause new sequences into Microsoft-hosted domains if your outreach tool treats deferrals as failures or burns retries; resume when other senders report recovery.
5. Tell stakeholders once, with the incident ID. "Microsoft 365 incident EX1467029, inbound mail delayed, no action on our side" ends the internal panic.

What to do if it's you

If the deferrals continue on a specific IP after other senders report normal delivery, Microsoft is throttling that IP's reputation. Delisting requests won't help — the portal only processes the permanent banned-IP codes. Work the reputation instead:

• Register the IP in Microsoft SNDS and read the colour and complaint data for the affected days. Note that SNDS no longer shows spam-trap data, so a green SNDS doesn't rule out trap hits.
• Verify authentication. SPF within the 10-lookup limit, DKIM aligned, DMARC published. Microsoft weights DMARC alignment heavily for unknown IPs. Grade the domain in one check.
• Cut per-connection volume. Throttle to a small number of messages per connection and a low connection count per Microsoft destination, then step up over days.
• Check the IP on the lists Microsoft consults — a Spamhaus listing produces S3150 rather than 4.7.500, but a borderline reputation often shows up on SpamCop or Barracuda first. Run the blacklist check.
• If it's a shared ESP pool, ask your provider whether Microsoft deferrals are elevated across the pool. If so, it's their appeal to make and your pool move to request.

Monitor Microsoft separately

The lesson from both 2026 incidents is that Microsoft rejection rates move independently of the rest of your delivery. A sender whose overall bounce rate looks fine can be losing every corporate prospect on Microsoft 365 for a day. Track deferral and rejection rates per destination provider, and alert on Microsoft-specific changes. A dashboard that sums everything together will show the incident a week late, in the reply-rate.

FAQ

Is 451 4.7.500 a blacklist?

No. It is throttling by Exchange Online Protection. No DNS blocklist is involved, and no delisting form applies.

Will retrying hurt my reputation?

Normal retry schedules don't. Hammering the destination with aggressive retries and high concurrency during a throttle can, which is why reducing connections is the one change worth making.

Why can't I reach Microsoft support about this?

Microsoft's sender support is designed around its delisting portal and the permanent banned-IP codes. For throttling on a non-Microsoft sender there is effectively no support path; the practical route is SNDS data, reputation repair, and time.

How do I know when the incident is over?

The MailOp list and Microsoft 365 admin-center service health are the earliest signals; Downdetector's Microsoft 365 graph is the fastest public one. Your own queue draining is the confirmation.