Reference: 451 4.7.500–699 in the error code wiki
On this page
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
Microsoft's NDR reference describes 4.7.500-699 as suspicious activity that has temporarily restricted sending while it is evaluated. In practice 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 and stop 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 header 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.
Related
Sources
- Email nondelivery reports and SMTP errors in Exchange Online (Microsoft Learn), 4.7.500-699 as a temporary restriction, 4.4.7 as a message that expired in the queue, and 5.7.708 as traffic refused from the IP.
- Fix NDR error codes 550 5.7.703, 5.7.705, 5.7.708 and 5.7.750 (Microsoft Learn), Microsoft names a low-reputation IP as the cause of 5.7.708.
- Anti-spam message headers (Microsoft Learn), where EOP stamps the SCL and BCL values you read in delivered mail.
- RFC 5321: Simple Mail Transfer Protocol, a 4xx reply is transient, the client must delay retries, and the give-up time is generally at least 4 to 5 days.