421 4.7.500 "Server busy. Please try again later" — Microsoft Throttling Decoded
Microsoft's 421 4.7.500 / 4.7.501 deferrals usually aren't about server load — they're soft throttling tied to reputation. Here's how to spot the difference and recover delivery.
When Microsoft 365 returns this temporary defer:
421 4.7.500 Server busy. Please try again later.
…it looks like a transient infrastructure issue. It almost never is. 4.7.500 (and its close cousin 4.7.501) is reputation-based throttling dressed up as a server-load message. If you don't recognise it, your mail keeps deferring forever and eventually times out.
What 4.7.500 Actually Means
EOP returns 4.7.500 when one of these is true:
- Your IP's sending rate to this Microsoft tenant (or to M365 overall) is above what EOP is willing to accept right now.
- Your IP's reputation has dropped enough that EOP wants to slow you down without outright blocking.
- The tenant has aggressive throttling configured and you've hit it.
4.7.501 is the same signal with a slightly different trigger — usually a more reputation-weighted throttle.
In all three cases the SMTP class is 4xx so your MTA retries. With a healthy MTA you'll eventually deliver. With a poorly tuned MTA you'll either back off too hard (mail times out) or retry too aggressively (Microsoft escalates to 5.7.708 permanent block).
How to Read the Signal
If you see 4.7.500 / 4.7.501 only occasionally — say <0.5% of M365 attempts — that's normal background throttling. Ignore it.
If you see it on > 5% of attempts, it's a reputation signal:
- Your IP is yellow or red in SNDS.
- You recently spiked volume.
- You're sending to a high proportion of unengaged M365 recipients.
- You've been hovering near a complaint-rate threshold.
Sensible Retry Strategy
A well-behaved MTA should:
| Attempt | Delay after previous |
|---|---|
| 1 | Immediate (initial send) |
| 2 | 15 minutes |
| 3 | 30 minutes |
| 4 | 1 hour |
| 5 | 2 hours |
| 6 | 4 hours |
| Cap | 24–72 hour total queue |
If you don't deliver within 24 hours of 4.7.500 retries, treat the message as undeliverable for that send — don't keep hammering. Microsoft watches retry patterns and aggressive retries on a throttled sender are a fast path to a permanent block.
Recovery Steps
- Pause aggressive sends to Microsoft. Drop volume to Microsoft addresses by 50% for 48 hours.
- Check SNDS. If you're yellow, you have a window. If you're red, you're days away from a hard block.
- Run Domain Health and ensure SPF, DKIM, DMARC are clean and aligned.
- Segment by engagement. Send only to recipients who've opened in the last 30 days for the next week.
- Check upstream reputation with Blacklist Checker — Spamhaus listings often correlate with EOP throttling escalation.
- Inspect headers of recently-delivered M365 mail with Email Headers Analyzer — rising SCL / BCL is the leading indicator.
4.7.500 vs 4.4.7 vs 5.7.708
| Code | Meaning | Action |
|---|---|---|
| 4.7.500 | Throttled (temp) | Slow down, retry sensibly |
| 4.4.7 | Message expired in queue | Investigate why retries didn't deliver |
| 5.7.708 | Permanent IP block | Stop retrying; remediate; open support case |
Common Causes I See
- A new shared-IP customer onboarded onto your ESP pool and tanked the shared reputation.
- A list import without verification, generating sudden complaint and bounce spikes.
- A transactional system being repurposed for marketing without warm-up.
- A misconfigured retry loop hammering one Microsoft tenant.
FAQ
Should I retry 4.7.500 immediately? No. Retry with exponential backoff (start at 15 minutes). Immediate retries make it worse.
Will switching IPs fix 4.7.500? It can mask the symptom but doesn't fix the cause. If you switch and keep the same sending behaviour, the new IP will throttle within days.
Does Microsoft publish their throttling thresholds? No. The thresholds vary by tenant and by overall sender reputation.