Microsoft 365 Went Down Overnight. 17.6% of Indonesian co.id Domains Get Their Mail Through It

Last updated 13 Nov 2026, 09:30 WIB. The incident is still open. I will update this post when Microsoft closes it and publishes a post-incident report. In Indonesia this Microsoft 365 outage started at 23:17 WIB on Thursday 12 November and was still open when offices opened on Friday. Outlook, Exchange Online and the Microsoft 365 features that depend on Exchange were affected. I wanted to answer two questions: what Microsoft has actually said so far, and how many Indonesian organisations receive their email through Exchange Online. For the second one I checked the MX records of the same 4,573 .id domains I used in my DMARC study last month. TL;DR The outage began at 23:17 WIB on Thursday. At 09:14 WIB on Friday Microsoft was still restoring capacity region by region. Microsoft says some of its servers stopped responding and dropped out, and the rest could not carry the extra load. It has not published a root cause and has reported no sign of an attack. About 1 in 11 popular .id domains that receive email use Microsoft 365 for it. Among company domains (co.id) it is about 1 in 6. Government domains (go.id) mostly run their own mail servers. Mail sent to an affected organisation is normally queued and retried by the sender's server, so it arrives late rather than disappearing. For anything urgent, call. What Microsoft has said, in WIB Microsoft tracks the outage as two incidents: EX1550543 for Exchange Online and MO1550821 for the wider Microsoft 365 impact. Because admins may not be able to open the admin center, Microsoft also posts it on the public status.cloud.microsoft page shown above. The timeline below comes from those posts, as collected by StatusStack and read from the status page itself. WIB UTC What Microsoft said Thu 23:17 16:17 EX1550543 opens: possible mailbox access issue Thu 23:55 16:55 Affected: Outlook on the web, MAPI, Exchange ActiveSync, REST Fri 01:07 18:07 The issue may affect users in any region, not only the Americas Fri 01:26 18:26 MO1550821 opens: users may be unable to connect to multiple Microsoft 365 services Fri 02:06 19:06 All deployments and configuration changes paused Fri 02:18 19:18 The load comes from a "large number of servers being unexpectedly unavailable", not from more traffic Fri 02:43 19:43 Affected servers are failing automated health checks Fri 05:00 22:00 Actions so far "have not provided the anticipated relief"; a core process is overwhelmed Fri 05:57 22:57 Some servers back in service and stable; limited recovery in some regions Fri 06:59 23:59 Returned servers can become unresponsive again once they receive traffic; some traffic types limited Fri 08:50 01:50 A process that establishes secure connections is overwhelmed; a recent network change is being rolled back Fri 09:14 02:14 Capacity being added to support traffic in regions coming back online The most specific explanation so far is in the 08:50 WIB post: "a process on the affected servers responsible for establishing secure connections becomes overwhelmed, causing the servers to stop processing requests." The same post says Microsoft has "begun reverting a recent network configuration change that correlates with the start of impact" and is watching whether that helps. At 02:57 WIB it had said it had "not identified any recent changes that correlate with start of impact", so the explanation is still changing. SecurityWeek notes that Microsoft has disclosed no evidence of a cyberattack. ABC News reports that New York City's emergency management office warned residents that email to city agencies could be delayed. The list of affected products is long because many of them read mail, calendar or contacts from Exchange: Teams calendar and meeting scheduling, Copilot access to work data, Defender for Office 365 Safe Links, Graph API calls for mail and calendar, Purview, Planner, To Do, Intune and Universal Print. Microsoft says core Teams chat and meetings "remain largely functional", and files stored directly in SharePoint stay reachable. Why restarting the servers did not end it Read in order, Microsoft's posts describe a feedback loop. Servers fail a health check and are taken out of rotation. Their traffic moves to the servers that are left, which then do more work each, so more of them fail the same check. A restarted server rejoins a pool that is still overloaded and falls over again "once they receive traffic". Google's SRE book describes this pattern in Addressing Cascading Failures, and Microsoft's response follows the same steps: stop changes, limit some kinds of traffic, bring capacity back gradually, and roll back recent changes. I don't know how Exchange Online balances load internally, and Microsoft has not said what triggered the first failures. The loop itself is something you can guard against in your own systems, and common load balancers already have settings for it: Limit how much capacity health checks can remove. Envoy's outlier detection ejects failing hosts but by default never more than 10% of a cluster (max_ejection_percent). If health checks mark too many hosts unhealthy anyway, Envoy's panic threshold (50% by default) sends traffic to all hosts again. Fail open when the whole fleet looks unhealthy. An AWS Application Load Balancer routes to all targets when a target group has only unhealthy targets. A check that says every server is down is usually wrong about at least some of them. Bring hosts back slowly. A restarted host has cold caches and no open connections, so it should not take a full share of traffic in its first seconds. Envoy calls this slow start. Shed load before the expensive step. Here the overloaded part sets up secure connections. A TLS handshake costs much more CPU than a request on an open connection, and when a fleet has to reconnect every client at once it pays that cost all together. Turning some new connections away early costs less than letting every server stall on them. How many .id domains receive mail through Microsoft 365 I used the same domain set as the DMARC study: the 4,573 domains under go.id, ac.id, co.id, or.id, sch.id, web.id, my.id, biz.id and plain .id in the Tranco GQ32K list. A Python script (dnspython) asked 1.1.1.1 and 8.8.8.8 for each domain's MX record, alternating between them, with up to 4 attempts and a cap of 45 queries per second. It ran on 13 November from 09:04 to 09:06 WIB. 84 domains do not exist, 50 failed every attempt, and 3,499 have a working MX. Each domain is classified by its lowest-preference MX host, where mail goes first: *.mail.protection.outlook.com is Microsoft 365, *.google.com and googlemail.com are Google Workspace. The last column reuses the 25 October scan and counts domains whose SPF record includes spf.protection.outlook.com, meaning they send mail through Microsoft 365. Group With MX Microsoft 365 Google Workspace Own server or hosting Other SPF allows M365 go.id 452 15 (3.3%) 20 (4.4%) 404 (89.4%) 13 (2.9%) 24 (5.3%) ac.id 932 50 (5.4%) 535 (57.4%) 109 (11.7%) 238 (25.5%) 75 (8.0%) co.id 892 157 (17.6%) 178 (20.0%) 467 (52.4%) 90 (10.1%) 199 (22.3%) or.id 43 5 (11.6%) 16 (37.2%) 21 (48.8%) 1 (2.3%) 6 (14.0%) sch.id 111 5 (4.5%) 46 (41.4%) 58 (52.3%) 2 (1.8%) 6 (5.4%) .id (plain) 979 73 (7.5%) 266 (27.2%) 511 (52.2%) 129 (13.2%) 97 (9.9%) All 9 groups 3,499 305 (8.7%) 1,063 (30.4%) 1,646 (47.0%) 485 (13.9%) 407 (11.6%) The "All" row also includes web.id, my.id and biz.id (90 domains with MX, none on Microsoft 365). Google receives mail for about 3.5 times as many of these domains as Microsoft does (1,063 against 305). In ac.id the gap is wider, 57.4% against 5.4%, possibly because Google Workspace for Education Fundamentals is free for qualifying schools and universities. co.id is where Microsoft 365 matters most. 157 company domains point their MX straight at Exchange Online, and 199 authorise Microsoft 365 to send for them. The two groups overlap but are not identical, since some companies receive mail elsewhere and send through Microsoft, or the other way round. go.id barely depends on it. 89.4% of go.id domains run their own mail server or a shared one, and 67 of them use the shared government mail service at mail.go.id. Some Microsoft 365 users are hidden behind filtering gateways such as Proofpoint, Mimecast or Trend Micro. 51 domains route inbound mail through one, and 19 of those also authorise Microsoft 365 in SPF, so their mailboxes are probably in Exchange Online. That makes 305 a lower bound. One more oddity: 236 ac.id domains use Cloudflare Email Routing, but nearly all of them belong to a single university group that registers a domain per faculty and unit, so that column says little about Indonesian universities in general. There are limits to what MX shows. It only tells you where inbound mail lands. An organisation can receive mail through Google and still run Teams, SharePoint and Copilot on Microsoft 365, and those users were affected too. Tranco ranks popular domains, so this is a sample of visible organisations and not all of Indonesia. And DNS is a snapshot from one morning. What happens to mail sent to an affected domain Most reports were about people reaching their mailboxes through Outlook on the web, Outlook desktop and phones. Microsoft also says "email delivery may be delayed". When a receiving server does not accept a message, the sending server keeps it in a queue and retries. RFC 5321 says the give-up time "generally needs to be at least 4-5 days", and most mail servers use something close to that. A message sent to a co.id company on Exchange Online last night is most likely waiting in a queue and will arrive late. I would not promise that nothing is lost, though. Some senders give up sooner, and many send a "delivery delayed" warning after a few hours that people read as a failure. If something was urgent, check for bounces once service is back and resend. What admins can do while it is still open You can follow the incident without the admin center. The status page reads a JSON endpoint that works without signing in. It is undocumented and may change, but it worked this morning: import html, json, re, urllib.request URL = "https://status.cloud.microsoft/api/posts/mac" post = json.load(urllib.request.urlopen(URL, timeout=20)) text = re.sub(r"]+>", " ", html.unescape(post.get("Message", ""))) print(post.get("LastUpdatedTime"), "|", post.get("Title")) print(text[text.find("Current status"):][:600]) Run it from cron and post to your team chat when LastUpdatedTime changes. The supported route is the Microsoft Graph service health API, which needs an app registration with ServiceHealth.Read.All and depends on Graph staying up. Leave your MX records alone. A new mail provider needs mailboxes, routing and expired DNS TTLs before it helps, and you would have to move back afterwards. Senders already queue and retry. Tell people another way to reach you. NYC Emergency Management did this on social media and pointed residents to 311 and 911. For a company it could be a WhatsApp broadcast or a short notice on the website with a phone number. It is also worth checking whether your incident contact list exists anywhere other than Outlook.