If your work email went quiet on Tuesday, you were not imagining it. On 2 June 2026 Microsoft confirmed a widespread Exchange Online outage — incident EX1331830 — that delayed and failed email for Microsoft 365 users across three continents. Here is exactly what broke, what the cryptic error messages meant, and the calm, correct way to handle the next mail-flow outage when it lands.
What happened to Exchange Online on June 2
Microsoft confirmed a service incident affecting the Exchange Online mail flow pipeline, meaning messages were delayed or failed to send and receive. According to BleepingComputer’s report, Microsoft acknowledged the incident — tracked as EX1331830 — at 10:33 EDT on 2 June 2026 after a stream of user reports, first for North America and then expanded “to encompass all potentially affected users” once impact surfaced in the Asia-Pacific and Europe regions. Engineers were reviewing the reports to find the root cause.
This was not a clean on-off failure. Mail flow is the conveyor belt that moves every message between mailboxes, and when it slows, email does not vanish — it backs up. Users reported sending and receiving delays exceeding an hour, with messages sitting in limbo rather than bouncing outright. The independent tracker IsDown logged the incident as detected at the same 10:33 timestamp and still showing impact into the following morning, roughly sixteen hours later — a reminder that a “mail flow” incident can drag on quietly long after the headlines move on.
Why your email went quiet — and what the errors meant
Because Microsoft’s servers were throttling and dropping connections, not rejecting your mail. Two error strings circulated during the incident. The first — “The maximum number of concurrent connections per resource forest has exceeded a limit, closing transmission channel” — is a capacity throttle: too many connections open at once, so new ones are refused. The second — “Connection was closed abruptly (SuspiciousRemoteServerError)” — is a connection cut mid-handshake. Both are temporary deferrals, which tell the sending system to back off and retry, not to give up.
That distinction is the whole story for end users. A deferral is a “come back later”, and well-behaved mail servers do exactly that — they hold the message and retry automatically, typically for 24 hours or more, until the far side accepts it. So the mail that looked stuck on Tuesday was, for the most part, queued and waiting, not lost. It is the same pattern we saw in May’s Outlook, Gmail and Yahoo delivery delays: scary in the moment, self-healing in practice. The danger is human — people hammering “send” again and again, which only piles more load onto a pipeline that is already gasping.
What this means for you — and what to do next time
If your mailbox is part of a Microsoft 365 work or school tenant, this is the service that wobbled — personal Outlook.com runs on a different backend. The right move during any mail-flow outage is to stop resending, check the official Microsoft 365 Service health page for the incident (EX1331830 here), and let deferred mail retry itself. Best for staying sane: treat a confirmed incident as weather — wait it out. The catch: for genuinely time-critical messages, you need a fallback channel that does not depend on the same pipeline.
The practical playbook is short. First, confirm it is them and not you: the Service health dashboard is the source of truth, with third-party trackers like IsDown as a quick sanity check. Second, resist the urge to re-send — duplicate copies will all deliver once the queue clears, and frantic retries can trip spam and duplicate-detection. Third, keep a genuinely independent backup route for the rare message that cannot wait an hour: a second mailbox on another provider, or a phone call. This is exactly why we keep recommending you not put your entire working life behind one vendor — the same resilience logic behind sender-authentication basics like the SMTP AUTH and Basic-auth deadlines Microsoft has been enforcing, and behind keeping an eye on the steady drip of Outlook on the web changes this June. One outage is an inconvenience; no plan B is the actual risk.

Alexis Dollé, email expert for 10+ years. Founder of Email Tools. I test every email client and utility myself, then write about them the way I’d explain them to a friend — no marketing fluff, no sponsored rankings, every claim sourced.
LinkedInFrequently asked questions
What was the Exchange Online outage on June 2, 2026? — a mail-flow incident (EX1331830) that delayed and failed email across three regions
A widespread service incident, tracked by Microsoft as EX1331830, that disrupted the mail flow pipeline for Exchange Online. Microsoft acknowledged it at 10:33 EDT on 2 June 2026 after a stream of user reports, and it caused emails to be delayed or fail to send and receive. It started with North America and Microsoft later expanded the scope to the Asia-Pacific and Europe regions too.
Was my email lost during the outage? — almost certainly not; deferred mail queues and retries automatically
Almost certainly not. The errors seen during the incident — SMTP deferrals and dropped connections — are queue-and-retry conditions, not permanent rejections. When a sending server gets a temporary deferral it holds the message and retries automatically, usually for a day or more, so most mail that looked stuck simply arrived late once the pipeline recovered. A true bounce, by contrast, comes back to you as a non-delivery report.
What do the SMTP error messages mean? — both were temporary deferrals, telling senders to back off and retry
Two were reported. ‘The maximum number of concurrent connections per resource forest has exceeded a limit, closing transmission channel’ means Microsoft’s mail servers were refusing new connections because too many were open at once — a capacity throttle. ‘Connection was closed abruptly (SuspiciousRemoteServerError)’ means the receiving server cut the connection mid-handshake. Both are temporary deferrals: the sending system is told to back off and try again later, not to give up.
Does this affect personal Outlook.com accounts? — no; it hit Exchange Online, the Microsoft 365 work and school backend
The incident was reported against Exchange Online, which powers Microsoft 365 work and school mailboxes. If your email is provided by your employer, school or organisation through Microsoft 365, that is the service that was affected. Personal Outlook.com mailboxes run on a separate consumer backend, so they were not the subject of this particular incident.
How can I check if Microsoft 365 is down right now? — the Service health page in the admin centre is the source of truth
The authoritative source is the Microsoft 365 Service health page in the admin centre (status.cloud.microsoft), where incidents like EX1331830 are posted and updated. Independent trackers such as IsDown and Downdetector are useful for a quick read on whether other users are reporting problems, but only Microsoft’s own dashboard confirms scope, cause and resolution.
What should I do the next time email stops flowing? — stop resending, check official status, and let deferred mail retry
Don’t repeatedly resend — that adds load and can trip duplicate-detection. Check the official status page first. If it confirms an incident, wait it out: deferred mail keeps retrying and delivers itself once service recovers. For anything genuinely urgent, switch to a different channel (phone, chat, or a second email account on another provider) rather than fighting a queue you can’t control.
Sources
- BleepingComputer — Microsoft Exchange Online outage causes email delays, failures (primary report: incident EX1331830 acknowledged 10:33 EDT on 2 June 2026, mail flow pipeline impact, scope expanded from North America to Asia-Pacific and Europe, the two SMTP error strings, and Microsoft reviewing reports for root cause)
- IsDown — Exchange Online status and user reports (independent third-party tracker corroborating the 10:33 detection time on 2 June 2026 and showing the incident still flagged with impact into the following morning, roughly sixteen hours later)
- Microsoft 365 Service health — official status dashboard where service incidents such as EX1331830 are posted, updated and resolved (the authoritative source for live scope, cause and resolution)