Exchange Online outage (EX1253275) blocked mailbox access across Outlook clients
On 16 March 2026 an Exchange Online outage (EX1253275) cut mailbox access via OWA, Outlook and ActiveSync, alongside a Copilot web sign-in issue (MO1253428).
On 16 March 2026 Microsoft confirmed an Exchange Online outage that stopped some users from reaching their mailboxes and calendars through several clients at once. A separate incident affected Microsoft 365 Copilot web sign-in on the same day. Outages are not security incidents, but this one is a reasonable prompt to check how your apps and alerting handle a dependency on Microsoft 365 that partially fails.
What happened
At 06:42 UTC on 16 March Microsoft acknowledged incident EX1253275, saying some users had trouble accessing their Exchange Online mailbox through "one or more connection methods." The affected methods included Outlook on the web, Outlook desktop, Exchange ActiveSync and other Exchange Online protocols. Microsoft first said telemetry showed the problem had stopped, while users kept reporting failures. It later attributed the outage to "an underlying issue involving the supporting network infrastructure" and declared it mitigated in an update reported at 14:20 EDT. It promised a post-incident report with the full root cause.
Separately, under MO1253428, Microsoft investigated problems with Microsoft 365 Copilot web sign-in and web clients on office.com, m365.cloud.microsoft and copilot.cloud.microsoft. It said "a section of service infrastructure is not processing traffic efficiently" and made configuration changes. It suggested the Copilot desktop app, Copilot in Teams or Copilot in Office apps as workarounds. Office.com also briefly showed a generic error page.
This followed other recent Exchange Online access incidents, including an IMAP4 outage in January 2026 and a classic Outlook access outage in November 2025.
Who is affected
- Microsoft 365 users whose mailboxes sat on the affected infrastructure, across web, desktop and mobile ActiveSync clients.
- Applications that depend on Exchange Online: ticketing systems reading shared mailboxes, apps sending through SMTP AUTH or Microsoft Graph, calendar integrations.
- Copilot web users during the MO1253428 incident.
What it means for developers and engineering teams
Many internal systems quietly depend on Exchange Online: password-reset and alert emails, helpdesk tools polling a mailbox, approval flows triggered from email, calendar booking. When the mailbox layer partially fails, the usual result is silent backlogs instead of clear errors. Graph or IMAP calls time out, retries pile up, and nobody finds out until users complain.
There is also an observability lesson. Microsoft's early status said things looked healthy in its telemetry while users were still affected. Provider dashboards trail what users experience and are averaged across tenants. If email matters to a workflow, run your own synthetic check instead of relying only on the provider's status page.
Also consider what users do during an outage. When web and desktop clients fail at the same time, people switch to personal email, forward documents to private accounts or share files through unsanctioned channels to keep working. A short, pre-agreed fallback (a status page, a chat channel for urgent requests, guidance on what not to send through personal accounts) reduces both disruption and data-handling risk.
For SaaS products that integrate with customers' Microsoft 365 tenants, such as calendar sync, email ingestion or Graph-based add-ins, an upstream outage often shows up first as a wave of support tickets. Surface upstream status in your own status page or in-app banners so customers can tell your bug from Microsoft's.
What to do now
- Subscribe to Service Health through the Microsoft 365 admin center or the Graph
serviceAnnouncementAPI, and route EX and MO incidents into your on-call channel. - Add a synthetic mail probe: send and receive a test message on a schedule and alert on end-to-end latency, not just on API errors.
- Use bounded retries with backoff in mailbox-polling and mail-sending jobs, and send failures to a dead-letter queue you can replay.
- Keep a fallback path for critical transactional mail (password resets, security alerts) through a separate email provider.
- Read the post-incident report for EX1253275 in the admin center once Microsoft publishes it, and keep it for SLA claims.
Related on TechLogHub
- Deadhand, uptime and cron monitoring
- Resend vs SendGrid vs Postmark, options for a fallback transactional mail path