Delayed Emails and the Exchange Online Server Busy Error: What It Means and How to Fix It

The Exchange Online Server Busy error, most often seen as “451 4.7.500 Server busy. Please try again later”, is not an outage in the strict sense: it is a temporary refusal. Microsoft 365 is telling the sending server to come back later because the IP address knocking at the door has suddenly started sending far more mail than it usually does. The messages do arrive in the end, minutes or hours late. The lasting fix is almost always a properly configured inbound connector, once you have checked that Microsoft is not reporting an incident on its side.

At a glance: the quick fix

• Note the full code from the delay notification or from the sending server’s logs: 451 4.7.500 through 699, 4.7.850 through 899 and 432 4.3.2 do not mean the same thing.
• Open the Microsoft 365 admin center, go to Health > Service health, and look at the Exchange Online row.
• Run a message trace in the Exchange admin center: Mail flow > Message trace.
• No declared incident and delays limited to one specific source (on-premises server, filtering gateway, application): create or correct the matching inbound connector.
• Ask senders not to resend their messages over and over: it makes the throttling worse.

Recognizing the problem

Your users complain that emails from outside the company land one, two, sometimes six hours after they were sent. Internal messages, meanwhile, are instant. Nothing is lost, everything eventually shows up, often in batches. On their end, senders receive a “Delivery is delayed” notice, with no final rejection.

In the sending server’s logs or in the non-delivery report, the response from Microsoft 365 looks like one of these lines.

The first digit is the key. A code starting with 4 is temporary: the sending server has to retry, and will do so on its own. A code starting with 5 is permanent: the message is rejected and will not come back without someone stepping in.

Why the Exchange Online Server Busy error happens

Exchange Online protects its shared platform with a mechanism Microsoft calls IP throttling. Every server that hands over mail has a history. As long as it sends volumes consistent with its past, everything goes through. When it starts sending a lot more, or shows up for the first time with a heavy flow, the service gets wary and tells it to come back later. It is a form of graylisting: a probation period during which a sender with no track record is handled with caution.

A legitimate server retries on a growing schedule, a few minutes at first and then longer and longer intervals. A spam bot generally does not retry at all. So the filter works, but its side effect is well known: legitimate mail runs late while the address builds its reputation.

The catch is that this protection is very often triggered by a configuration issue rather than by real volume. Three situations come up again and again.

The first involves hybrid organizations. Your on-premises Exchange server, your copier or your line-of-business application relays mail to Microsoft 365. Without an inbound connector that identifies this source as yours, by its certificate or its IP address, Exchange Online treats it like any stranger on the internet and throttles it.

The second involves filtering gateways. If your MX record points to a third-party antispam service that then relays to Microsoft 365, all of the company’s inbound mail arrives from a handful of IP addresses. From Microsoft’s side, that is an abnormal surge from a single source.

The third comes from a genuine change in volume: a mailbox migration, a bulk mailing campaign, a runaway application, a compromised account.

Code 432 4.3.2 follows a different logic. It protects one given mailbox, not the service: a mailbox can only receive 3,600 messages per hour from all sources combined, and a single sender can only take up a third of that ceiling. Shared mailboxes that collect monitoring alerts hit it regularly.

Before you start

You need an account with an Exchange administration role for message tracing and connectors. Viewing service health is open to more limited roles, including the Helpdesk admin.

Gather three things before you touch anything: a sample email that arrived late, with its full headers, the exact text of the error as seen by a sender, and the approximate time the delays began. Timestamps in Microsoft’s tools are in UTC, so remember to convert.

Do not change the MX record or existing connectors in the middle of the working day without writing down the current configuration first. A mistake at that level turns delays into rejections.

Solution 1: Read the header and the error code

Do this first. No risk, ten minutes.

1. Get the headers of a delayed message

In Outlook, open the message and go to File > Properties: the Internet headers are at the bottom of the window. Copy all of them.

2. Run them through Microsoft’s analyzer

Paste them into the Message Header Analyzer tool (mha.azurewebsites.net). It lays out each hop of the message as a table, with the time spent at each step. The Received lines read from bottom to top: the lowest one is the departure, the highest one the arrival in the mailbox.

3. Find where the time went

If the delay sits before the first line that mentions a Microsoft server (names ending in outlook.com or protection.outlook.com), the message waited at the sender’s end or on an intermediate gateway, typically because it was being temporarily refused. If the delay appears between two Microsoft servers, the slowdown is inside the service and there is nothing you can do about it: that is a case for service health and support.

4. Look at authentication

The Authentication-Results line shows the outcome of SPF, DKIM and DMARC. An spf=fail or a dmarc=fail on mail from your own partners does not explain a delay, but it does explain messages sent to quarantine, which users often mistake for delays.

Solution 2: Check service health

Use this every time before changing your configuration.

1. Open the health page

In the Microsoft 365 admin center (admin.microsoft.com), go to Health > Service health. An Exchange Online row flagged with an incident or an advisory gives you an ID, a description of the impact and regular updates.

2. Tell an incident from an advisory

An incident is a critical interruption of a major feature. An advisory is a problem that affects some users while the service stays available, often intermittently. Delivery delays are classified as advisories most of the time, which explains why they go unnoticed if you only watch for red alerts.

3. If the admin center is unreachable

Check status.cloud.microsoft, the public status page, and the @MSFT365Status account on X.

4. Report the problem if it is not listed

The Report an issue button on the health page lets you flag a problem that is not listed. When several organizations do so, the investigation starts sooner.

If a current event describes inbound mail delays, your work stops here: tell your users and watch for updates. Otherwise, keep going.

Solution 3: Trace the affected messages

Use this to measure the scale and identify the source. No risk.

1. Run the trace

In the Exchange admin center (admin.exchange.microsoft.com), open Mail flow > Message trace. Enter an affected sender or recipient and a time range that covers the start of the delays. For ten days or less, the results appear immediately.

2. Read the statuses and events

A message with a Pending status is still being attempted. In the details, the Defer event means delivery was postponed and will be retried. Compare the time of the Receive event with the time of Deliver: if the two are close together while the user got the message hours after it was sent, the whole delay happened before the message entered Exchange Online. That is the signature of throttling at the door.

3. Know what the trace does not show

A message that is temporarily refused at connection time has not yet been accepted by the service. It can therefore be missing from the trace until the sending server manages to hand it over. An empty trace does not prove nothing was sent.

4. In PowerShell

Get-MessageTraceV2 -SenderAddress [email protected] -StartDate <start date> -EndDate <end date>

Replace the address and both dates with your own, in the date format of your PowerShell session. The command queries ten days at most per run and returns 1,000 results by default.

5. Request an extended report

To get the originating IP address and routing details, choose the Enhanced summary report or the Extended report, both delivered as CSV. The IP address column will tell you whether the delayed messages all come through the same source.

Solution 4: Tell Microsoft throttling from a fault on your side

This is the diagnostic step that keeps you from fixing the wrong thing.

Ask yourself four questions. Do the delays affect every external sender, or only some? Does the delayed mail always travel through the same IP address? Did anything change in your routing just before the first delays: a new antispam service, a new public IP address, a renewed certificate, a migration? Is an incident showing in service health?

Every sender, no common source, incident showing: the problem is at Microsoft. Every sender, a common source that happens to be your filtering gateway: the problem is on your side, and it is a missing connector. Only a few senders: the problem is on their side, with a sending IP address that is on probation or poorly authenticated. Only the mail relayed by your on-premises server: an inbound connector that is missing or no longer recognizes the server.

That last case deserves a word. A connector identifies your server either by the name on its TLS certificate or by its IP address. Switch internet providers, or renew the certificate with a different subject name, and the connector stops recognizing anything without showing a single error. Mail keeps leaving, but it is now treated as anonymous.

Solution 5: Create or correct the inbound connector

Use this as soon as the source of the delays is a server or service you control. Moderate risk: test outside peak hours.

1. For an on-premises server or an application

In the Exchange admin center, open Mail flow > Connectors and add a connector with Your organization’s email server as the origin and Office 365 as the destination. Two identification methods are offered. Microsoft recommends certificate verification: the subject name on the certificate your server presents has to match a domain you declare. The alternative is to list the public IP addresses that belong exclusively to your organization.

2. For a third-party filtering gateway

Create a Partner organization connector, restricted to that provider’s IP addresses or certificate. Microsoft states that this connector avoids the graylisting that would otherwise hit the large volume of mail coming from that source.

3. Check what already exists

If a connector is already in place, compare the IP addresses and certificate name it expects with what your server actually presents. The IP address as seen by Microsoft appears in the 451 error itself and in the extended trace report.

4. Validate

Use the validation wizard offered at the end of the creation process, then send several test messages. To verify: in your server’s logs, the 451 responses disappear and the queue drains.

Solution 6: Deal with the queue on a hybrid server

Use this when the on-premises Exchange server is piling up messages.

1. Inspect the queues

In the Exchange Management Shell on the on-premises server:

Get-Queue -Server Mailbox01 -Exclude Empty

The last error column repeats the response from Microsoft 365. Queue Viewer, in the Exchange Toolbox, gives the same view in graphical form.

2. Retry after the fix

Once the connector is corrected, there is no need to wait for the next automatic attempt:

Retry-Queue -Filter "Status -eq 'Retry'"

3. Check that the server itself is not overloaded

If your on-premises server is the one answering “busy” to senders, the cause is internal: a full disk, not enough memory. Exchange then protects itself by temporarily refusing inbound connections. Free up space on the volume that hosts the queues before doing anything else.

Solution 7: Clean up authentication and sending volumes

Use this for delays and rejections in the outbound direction, and to keep your domain from getting a poor reputation.

1. SPF

The basic record for a domain that only sends from Microsoft 365 is:

v=spf1 include:spf.protection.outlook.com -all

Add your other legitimate sources to it. Watch the ceiling of ten DNS lookups: beyond that, SPF fails with a permanent error and all your mail loses its authentication.

2. DKIM and DMARC

Turn on DKIM signing for your domain in the Defender portal (security.microsoft.com/authentication, DKIM tab), after creating the two CNAME records selector1._domainkey and selector2._domainkey. Then publish a DMARC policy.

3. Stay within the limits

An Exchange Online mailbox can send at most 30 messages per minute and reach 10,000 recipients per day. An overall cap on external recipients also applies to the organization, in proportion to the number of licenses. Domains ending in onmicrosoft.com are limited to 100 external recipients per 24 hours. For bulk sending, Microsoft points to specialized services.

4. Make sure no account is compromised

Outbound volume that explodes for no reason, a 5.1.8 or 5.7.705 code: look for a hacked account before considering anything else. Mail judged suspicious goes out through a high-risk pool of IP addresses that many recipients refuse.

What the external sender can do

Not much, and you need to tell them so plainly. If they resend the same message ten times, they increase the very volume that triggered the throttling. Their server will retry by itself. What they can do is pass the exact error text on to their own administrator, who will check the queue, the domain’s SPF and DKIM authentication, and the reputation of the sending IP address. For an urgent document, another channel remains the only immediate answer.

What to tell your users

A short message is enough: emails from outside are currently arriving late, none are lost, internal messages are not affected, and there is no point asking contacts to resend. Give a fallback channel for emergencies and the time of your next update. Do not announce a recovery time you have no control over.

Summary table

If nothing works

Open a service request from the Microsoft 365 admin center, under Support. A well-prepared ticket gets handled faster. Attach the full text of the error with its reference in parentheses, the sending IP address involved, two or three message IDs taken from the trace, the headers of a delayed message, the times in UTC, a diagram of your routing (MX, gateway, connectors) and when your infrastructure last changed.

If the error concerns an external sender, it is up to their administrator to act: you cannot get throttling lifted on an IP address that does not belong to you.

Keeping it from happening again

Document your connectors and add a check of them to your certificate renewal and provider change procedures. That is the most common cause of a relapse.

Subscribe to service health email notifications for Exchange Online, and pick an address outside your organization: an alert about mail delays sent to the affected mailbox arrives too late.

Ramp up gradually during a migration or when bringing a new sending IP address into service. Route monitoring alerts to several mailboxes or to a channel that is not email. Finally, keep an eye on DMARC reports and on the size of the queues on your on-premises server.

Frequently asked questions

Are delayed emails lost?

No, as long as the code starts with 4. The sending server holds on to them and retries. They are only dropped if the attempts keep failing until expiration, which produces a non-delivery report.

How long does 451 4.7.500 throttling last?

Left alone, it fades as the IP address builds a history, which can take a few days. With a suitable connector, it stops as soon as the connector is recognized.

Can I ask Microsoft to lift the throttling?

There is no button for that. The expected answer is a correct connector. Support can confirm the diagnosis.

Why are only external emails affected?

Internal mail does not cross the service boundary and is not subject to IP address reputation checks.

Does Server busy mean Microsoft’s servers are overloaded?

Rarely. The wording is misleading: in most cases it is your sending source that is being throttled, not the service running out of capacity.

If the Exchange Online Server Busy error persists in your environment, leave a comment with the full code, the direction of the affected mail flow and your routing architecture: those three details are often enough to point to the faulty connector.