## TL;DR
Treat 451 4.7.500 as a temporary refusal and fix the burst that caused it: spread the sending rate, stop retry storms from your own gateway, and check whether one application is flooding the connector. Throttling errors resolve on their own once load drops, so the real work is finding the sender whose volume or retry behaviour keeps your tenant or IP in the throttled state, then smoothing that flow.

```text
"451 4.7.500" server busy throttling error delays legitimate mail through exchange online protection
```

## Use this when
- Sending servers log 451 4.7.500 server busy and mail delivers late rather than bouncing.
- Delays cluster around bulk sends, report runs, or retry backlogs.
- Message trace in Microsoft 365 shows the mail eventually delivered.

## Not for this skill when
- Mail is hard rejected with a 550 policy error. That is a block, not throttling.
- Your own server is out of disk or connections. That is a local capacity fault with different logs.

## Steps
1. Collect the deferral logs and chart them by hour and by sending application to find the burst pattern. Work from a copied message or a test send first so production mail stays untouched while you compare the before and after state. Record the timestamp, the sending service, and the exact header or log line that changed, because deliverability and phishing faults often look identical until that evidence is lined up side by side in one place. Verify: the deferrals map to a named sending pattern or time window
2. Check your gateway retry settings and confirm a deferred message is not retried aggressively from multiple queue hosts at once. Do not change more than one setting at a time here. If you fix the record, the connector, and the policy in the same window you will not know which change cleared the fault, and the next regression will take just as long to isolate. Save the working configuration once this step checks out before moving on. Verify: retry intervals follow a sane backoff and are not firing in parallel storms
3. Reduce the burst: rate limit the offending application, split bulk sends into smaller batches, or move bulk mail to its own service. Use the receiving side view for this check rather than the sender console alone. Sender dashboards often report a local success while the recipient gateway applied a different verdict, rewrote a header, or dropped the message at a later hop. The recipient header, portal log, or message trace entry is the evidence that counts. Verify: the sending rate change is live in the application or gateway config
4. Watch deferral counts for the next sending cycle at the new rate. Keep any exception you create narrow and time boxed. Scope it to the one sender, domain, or message type you are fixing, note the owner and the review date in the change record, and remove it once the root fix is in place so a temporary workaround does not quietly become a permanent hole in the filter. Verify: 451 deferrals fall sharply or disappear at the smoothed rate
5. Confirm with message trace that delayed mail is now delivered within your normal window. Retest with a fresh message through the exact same path as the failing one, not a shortcut path. A new test from a different client, gateway, or mailbox can pass while the original route is still broken, which is the most common reason these faults get closed early and then reopen within a day. Verify: traced messages show delivery times back inside the normal range

## Why it happens
Exchange Online Protection protects shared capacity by deferring senders whose behaviour looks abusive: sudden volume spikes, high invalid recipient ratios, or aggressive retries. A 451 is deliberately temporary, and well behaved servers back off and deliver later. Senders that retry instantly from many hosts keep the pressure on and stay throttled, so a fix aimed only at Microsoft misses the part of the system you actually control.

## Variants and edge cases
### 451 4.7.500 server busy throttling exchange online delays mail
The exact error plus the delay symptom.
### exchange online protection throttling legitimate bulk mail deferred
The bulk sender variant for report and campaign traffic.
### 451 server busy retry storm gateway deferred mail fix rate
The retry behaviour variant naming the self inflicted part.

Compatibility: Microsoft 365 Exchange Online Protection throttling, on premises gateway queue management.

Edge cases to check:
- A high bad recipient ratio from an old address list triggers throttling fast; clean the list as part of the fix.
- Separate bulk and transactional streams so a throttled campaign cannot delay password resets and invoices.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ua9pvkHO-F8k6nb52kSSGg