We're seeing an increasing number of temporary mail-delivery failures when sending to Exchange Online recipients in Europe. The error is usually "451 4.7.500 Server busy. Please try again later," and messages are backing up in our filtering systems or being delayed by 15–60 minutes. We've seen it from multiple sending platforms and IP addresses, but neither the service health dashboard nor public outage trackers are showing an incident. Is anyone else experiencing this, and have you found a workaround?
5 Answers
Several organizations are seeing the problem through Mimecast, Mesh Security, SpamTitan, LibraESVA, Mailgun, and self-hosted systems. That makes an isolated gateway issue unlikely. It appears to be an Exchange Online-side problem affecting inbound delivery or specific European infrastructure, even though the official status pages haven’t reported it yet.
Yes, this is affecting multiple providers and regions, including the UK, Denmark, Sweden, France, Finland, Belgium, Ireland, and the Netherlands. We’ve seen the same temporary 451 responses from different gateways, shared and dedicated sending IPs, and even direct mail systems, so it doesn’t look limited to one filtering vendor. Some messages eventually deliver after roughly 45–60 minutes, while others remain queued.
This may be throttling or a regional Exchange Online transport issue rather than a total outage. We’ve also noticed broader Exchange behavior problems recently, including trouble accessing the admin center and Graph-based mail applications. The safest approach for now is to leave retries enabled, avoid aggressive retry intervals, and use the direct-MX or connector workaround only after testing it carefully.
A possible workaround is routing mail directly to the organization’s Exchange Online MX endpoint instead of relying on the usual filtering path. Some people reported better results after configuring an Exchange connector that permits their gateway’s public IP, although this may have side effects for companies sharing the same filtering service.
It’s worth opening a support case with Microsoft and including the complete SMTP response, timestamp, destination, and sending IP. Multiple reports may help get the incident recognized, especially since the service dashboard can lag behind the actual impact. Expect messages to keep retrying, but monitor the queue closely in case retries eventually expire.
That matches what we’re seeing: messages are not consistently rejected, but delivery is delayed or intermittently fails. We’ve also opened a support case because the backlog is becoming significant.