Exchange Online Outage: Email Delays and 'Server Busy' Errors — Defender's Response and Resilience Guide

Microsoft is actively working to resolve an ongoing Exchange Online outage that is delaying email sent to and received from external domains, with affected users reporting 'Server busy' errors when attempting to send messages. For organizations that run their business on Microsoft 365 — which is most of them — this is not a minor inconvenience. Email is the backbone of everything from password reset flows and MFA delivery to contract execution and incident notification. When Exchange Online degrades, security operations degrade with it.

This post breaks down what we know about the incident, what it means for your security posture, and the concrete steps your team should take during and after the outage — including a threat consideration most coverage will miss: outages are prime phishing season.

What Happened

According to the incident reporting, Microsoft confirmed an Exchange Online service degradation impacting mail flow to and from external domains. Users attempting to send messages are encountering 'Server busy' errors — a symptom consistent with transport-layer backpressure, where the service deliberately sheds or queues load rather than accepting messages it cannot process in a timely manner.

Key characteristics of the event:

• Affected service: Exchange Online (Microsoft 365 / Office 365 cloud email)
• Impact: Delayed delivery of email sent to and received from external domains; intermittent 'Server busy' errors on send attempts
• Internal mail flow: Intra-organization mail (same-tenant delivery) typically routes through a different path and is often less impacted during these events — but verify against your own tenant's experience
• Root cause: Microsoft has not attributed this to a security event; it is being handled as a service availability incident tracked in the Microsoft 365 admin center

There is no CVE associated with this event, and at the time of writing there is no indication of malicious activity as the root cause. That said, availability incidents of this scale have real security consequences, which is why this belongs on your SOC's radar even though it isn't an exploit.

Why Security Teams Should Care About an 'IT Problem'

A common failure mode in enterprise security is treating service outages as purely an infrastructure/IT concern. That is a mistake. Here is why your SOC and IR functions need to be engaged during an Exchange Online degradation:

1. Security alerting pipelines break silently

If your SIEM forwarding, DLP alerts, phishing report workflows, or SOAR notifications traverse Exchange Online, they are queuing or failing right now. Alert fatigue is bad — alert absence during an outage is worse, because it is invisible until someone asks why nothing fired. Verify that detection pipelines that depend on email transport have fallback paths or are being monitored for delivery gaps.

2. Time-sensitive security workflows stall

Password reset links, MFA enrollment invitations, breach notification emails, vendor security advisories, and legal hold notifications all ride on mail flow. Delays measured in hours can have compliance implications (breach notification clocks under HIPAA and state laws don't pause for Microsoft's outages) and can lock users out of recovery flows.

3. Outages are social engineering gold

This is the one that keeps me up. Within hours of any widely publicized Microsoft outage, we consistently see phishing campaigns weaponizing it: fake 'Microsoft 365 Support' messages claiming the user's mailbox needs 're-verification,' fraudulent notices directing users to credential-harvesting portals to 'restore delayed emails,' and help-desk impersonation calls offering to 'fix' the sync problem. Your users are already primed to believe something is wrong with their email — attackers exploit exactly that psychological state. Assume the lure emails are already being drafted.

4. Outage + incident is a compound-risk scenario

If you suffer a security incident during the outage, your IR communications plan — which almost certainly assumes email works — is degraded. Alternate channels need to be stood up proactively, not improvised mid-crisis.

Technical Analysis

Affected platform

• Product: Microsoft Exchange Online, the cloud-hosted email component of Microsoft 365
• Scope: Mail flow involving external domains (inbound from and outbound to non-Microsoft 365 recipients)
• Symptom: 'Server busy' responses to send attempts; delivery delays for external mail

'Server busy' in the Exchange transport context indicates the receiving transport service is applying backpressure — resource exhaustion thresholds (memory, disk, queue depth) have been crossed, and the service is protecting itself by deferring new work. At Microsoft's scale, this usually reflects a capacity, routing, or dependency failure within a region or service partition rather than anything a tenant can influence. The practical takeaway for defenders: your tenant cannot fix this, but your queues, connectors, and downstream systems will feel second-order effects — delayed journaling, stuck hybrid transport queues, and retry storms from on-premises or third-party mail systems.

Exploitation status

There is no vulnerability and no exploitation associated with this event. This is a service availability incident. The exploitation risk is derivative: threat actors exploiting the news cycle around the outage for phishing and vishing, which is a well-documented pattern following high-visibility Microsoft service disruptions.

What to verify in your own environment

If you run hybrid Exchange or route mail through third-party gateways (Proofpoint, Mimecast, Barracuda, Ironscales, etc.), check:

• On-premises hybrid queues: Messages bound for Exchange Online may be queueing on your hybrid servers with retry backlogs that will burst when service restores — watch for a post-outage delivery flood that can trip rate limits or look anomalous in mail flow analytics
• Connector status: Verify inbound/outbound connector health in the Exchange admin center once Microsoft declares recovery; stale TLS or forced-retry behavior can strand mail
• Message trace: Use message trace in the EAC/Defender portal to quantify actual delay impact for your tenant rather than relying on anecdote — this data matters for SLA credits and for your own incident documentation

Detection & Response

This is an availability incident, not a technical threat — there is no CVE, exploit chain, or malware to write behavioral detections against. Publishing Sigma rules or VQL artifacts here would generate noise, not signal, and we don't ship detections we wouldn't run in our own clients' environments.

The correct defensive response is operational. These are the takeaways we'd give any client during this event.

Executive Takeaways

1. Confirm scope and monitor authoritative channels. Check the Microsoft 365 admin center (Service Health dashboard) for the incident ID affecting your tenant, and track updates there — not on social media. Assign someone to own monitoring until full recovery is declared. Do not rely on user reports as your source of truth.

2. Verify security tooling that depends on email transport. Audit SIEM alerting, SOAR playbooks, DLP notifications, phishing-report mailboxes, and any scheduled report delivery that routes through Exchange Online. Identify gaps now and document the window of degraded visibility — your post-incident reviewers and auditors will ask.

3. Pre-empt outage-themed phishing. Send a proactive, plain-language communication to all users through a channel that still works (Teams, Slack, intranet banner): state that Microsoft is experiencing a known outage, that IT will never email asking them to verify credentials or click a link to 'restore' delayed mail, and give them a single verified path for questions. Then alert your SOC to tighten scrutiny on inbound mail impersonating Microsoft support or your own help desk for the next 72 hours.

4. Stand up alternate IR communications before you need them. If email is your incident coordination channel, it is currently unreliable. Confirm your out-of-band channel (dedicated Teams/Slack space, bridge line, pager tree) works, and make sure your IR contact list doesn't live exclusively in an Exchange mailbox nobody can reach.

5. Watch for the post-recovery surge. When Microsoft restores service, queued mail — including queued malicious mail that bypassed nothing but got delayed — will flood in. Ensure your email security gateway and Defender for Office 365 policies are fully applied to delayed messages, and brief analysts that retro-detected threats from the outage window are expected, not a new campaign.

6. Document everything for SLA and compliance. Capture the service health incident ID, your tenant's measured impact (from message trace), affected business processes, and any compliance-relevant delays (e.g., breach notification timelines). Microsoft SLA credits require a claim — and if the outage touched regulated communications, your documentation needs to show you tracked it.

Remediation

There is no patch, workaround configuration, or tenant-side fix for a Microsoft-side service degradation — remediation here means resilience and recovery discipline.

Immediate actions:

• Track the incident in the Microsoft 365 admin center under Service Health (https://admin.microsoft.com/servicestatus) and cross-reference at https://status.office.com if admin center access is impaired
• Run message trace in the Microsoft Defender portal / Exchange admin center to quantify delayed and failed messages for your tenant
• Do not mass-resend queued external mail; Exchange transport retries automatically, and manual resends create duplicates and delivery storms
• If you operate hybrid Exchange, monitor on-premises transport queues (Get-Queue on your Exchange servers) and prepare for controlled drain when service restores

Post-recovery actions:

• Confirm all delayed security alerts and reports eventually delivered; investigate any that did not
• Review inbound mail from the outage window for phishing that exploited the disruption theme
• File an SLA credit claim with Microsoft if your tenant qualifies
• Conduct a short retrospective: did your IR communications, security alerting, and user-communication plan survive a few hours without Exchange Online? If not, that is a gap in your business continuity plan — fix it while the memory is fresh

Strategic hardening for the next outage (there will be one):

• Build alerting-pipeline redundancy so detections don't silently depend on a single transport
• Maintain a tested out-of-band incident communications channel and an offline-accessible contact tree
• Add 'major cloud provider outage' to your threat intelligence watchlist criteria, because the phishing follow-on is predictable

The Bottom Line

An Exchange Online outage is not a breach — but treating it as 'just an IT ticket' is how organizations get phished, lose alerting visibility, and botch compliance timelines. The defenders who handle these events well are the ones who already assumed email would fail someday and planned accordingly. Use this incident as a live-fire test of your resilience assumptions, and close whatever gaps it exposes.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub