Microsoft 365 Outage Resolved: Outlook, Teams & Copilot Cause and Email Checks (Nov. 2026)

Archived November 13, 3 p.m. JST update: Recovery was still in progress at that time

According to Microsoft’s notices at approximately 3:16 p.m. JST on November 13, both the Outlook/Exchange Online incident EX1550543 and the wider Microsoft 365 incident MO1550821 remained classified as service degradation. Some users and regions were seeing partial recovery, but Microsoft had not confirmed a complete restoration or announced a definitive time to full recovery.

Microsoft’s response: The company was investigating overloaded and unresponsive servers by testing traffic throttling, protocol adjustments and alternate routing. It was also reproducing traffic patterns in a restricted environment to isolate the cause and measure the effectiveness of possible remedies. Microsoft said it had found no indication that malicious activity caused the incident. The root cause had not yet been established.

At the time of those notifications, the next information updates were scheduled for 4:00 p.m. JST (MO1550821, the broader incident) and 4:30 p.m. JST (EX1550543, Outlook/Exchange Online). These were bulletin update times, not expected service restoration times. The times are retained here to accurately reproduce the November 13 report, and may now be in the past.

For changes after the reported times, use Microsoft’s public service status. Employees and school administrators should check Microsoft 365 admin center > Service health for the incident IDs and tenant-specific impact. A general public status page can look healthy even when individual tenant-level incident notices remain open.

Outlook email not arriving? Verification codes and two-step login may also fail

Microsoft’s notices warned that email delivery through Exchange Online could be delayed. In addition to Outlook itself failing to load, users might be unable to sign in to otherwise functioning services because a one-time passcode sent to their affected mailbox never arrives. On November 13, Otsuka Corporation’s customer notice said some customers using Microsoft-based email were experiencing delayed or missing authentication messages, affecting two-step sign-in to its customer portal and new Otsuka ID registrations.

• Can’t receive email: Confirm whether you use Outlook.com, a Microsoft 365 organizational mailbox or another email provider. Check your inbox, junk folder and any available quarantine, but if the mailbox will not open, start with the relevant service health notice.
• One-time code missing: Avoid requesting dozens of replacement codes in quick succession. Follow the service’s expiry and retry instructions. If you already enrolled an approved authenticator app or another permitted verification method, try it instead; do not bypass account security.
• A sent message has not reached its recipient: Review Drafts, Outbox and Sent Items, and where necessary confirm delivery with the recipient by phone or another company-approved channel. A message appearing in Sent Items does not prove it reached its destination. Repeated resends may cause duplicate delivery.
• Only the Outlook app appears broken: You can test Outlook on the web once. However, Microsoft’s incident also affected the web interface, so it is not a guaranteed workaround. Avoid deleting Outlook profiles or reinstalling Microsoft 365 Apps just because the cloud service is degraded.

Confirmed cases in Japan: Kyoto University, Hiroshima University and Otsuka Corporation

Several Japanese organizations published incident notices about email or associated Microsoft services. These are confirmed individual cases, not a measure of the total number of affected people in Japan.

Were all Teams and OneDrive functions down? Not necessarily. Microsoft’s broad notice said most core Teams chat and meeting functions were generally unaffected, while features depending on Exchange Online—such as calendars, meeting invitations and some Copilot operations—could fail. Direct access to files stored in SharePoint was generally described as available. Kyoto University’s operational notice nevertheless listed Teams and OneDrive among affected services. A product’s general service status and a particular organization’s actual experience need not be identical.

Source check: November 13, approximately 3:14–3:16 p.m. JST for MO1550821/EX1550543, plus the Japanese organizations’ primary announcements. Incident notifications are also reproduced in University of Pennsylvania’s public copy of Microsoft admin-center incident notifications.

November 13 update: Bank one-time codes not arriving—Rakuten Bank, Japan Post Bank and GMO Aozora Net Bank

The Microsoft 365 outage also affected banking procedures that depend on verification messages delivered to Outlook or other affected Microsoft-hosted inboxes. On November 13, Rakuten Bank, Japan Post Bank (Yucho Bank) and GMO Aozora Net Bank posted notices about related email-delivery problems. These announcements did not say the banks’ core banking systems were generally down. The affected customers were those unable to receive the necessary messages through their email service, not every account holder.

Rakuten Bank: What if the one-time key for a transfer does not arrive?

Rakuten Bank stated that customers who could not receive the email containing a one-time key might be unable to complete login or fund-transfer verification. For urgent transfers, it listed its customer support numbers as 0120-776-910 from landlines and 0570-064-924 from mobile phones (chargeable), with further options on Rakuten Bank’s November 13 notice. Check the official contact information before calling. A call does not in itself guarantee that a transfer can be completed.

Japan Post Bank: Some applications can use a different email address

In its notice updated at noon JST on November 13, Japan Post Bank said users could use an alternative address, such as a mobile carrier email, for specific services: opening an account or reissuing a passbook/card through the Yucho Procedures app, and online applications for JP BANK Card or Yucho Debit. It did not say that simply switching addresses would solve the Yucho Direct one-time password delivery problem. Consult Japan Post Bank’s November 13 notice (updated at noon) for precise coverage.

GMO Aozora Net Bank: Email tokens and debit-card alerts

GMO Aozora Net Bank warned that users receiving mail through Outlook might miss the email token required for certain account operations. It advised doing those operations once Microsoft 365 email recovered. When debit-card usage alerts did not arrive, it advised users to check the transaction history in online banking. See GMO Aozora Net Bank’s November 13 notice.

What not to do when bank authentication messages do not arrive

• Do not change bank passwords indiscriminately. A receiving-mail outage is not necessarily fixed by resetting credentials.
• Do not hammer the resend button. Multiple delayed codes can later arrive in confusing order; follow each service’s retry interval and expiry time.
• Beware of fake recovery links. Do not use SMS or emailed links claiming to restore the outage; open the bank’s official app or a saved official URL instead.
• For urgent transfers, avoid duplicate transactions. Check the existing transaction history and balance, then contact the bank’s official support channel as needed.

Why this happens technically: Bank authentication depends on a chain: the bank generates a token, sends an email through mail infrastructure, and the recipient reads and enters the token. Even if token generation at the bank works, the user cannot complete the authentication step when access to their mailbox or email delivery fails. This explains how a Microsoft 365 infrastructure problem can disrupt an otherwise separate banking application; it is not evidence of a breach of bank accounts.

Bank-source verification: November 13, 2026. See Rakuten Bank’s November 13 notice, Japan Post Bank’s November 13 notice (updated at noon), and GMO Aozora Net Bank’s November 13 notice. These reflect each institution’s notice as checked on the day; consult the banks for later changes.

November 13, 9:14 a.m. update: Limited regional recovery began

At about 8:58 a.m. JST, Microsoft said some affected servers had been returned to service and were stable, with limited recovery observed in certain regions. Traffic was also being moved through alternative routes. At 9:14 a.m., however, Microsoft had not declared a complete recovery; EX1550543 and MO1550821 still indicated degraded service.

Microsoft said it was optimizing its server recovery workflow and deploying protections intended to reduce traffic pressure at particular locations. If effective, these changes could be expanded. Recovery could occur in stages by region, service and user; apps might require time to reconnect even after backend capacity returned. This is a description of a staged recovery approach, not a promised restoration deadline.

If an application starts working again, verify whether pending messages were actually sent and whether files were saved before retrying to avoid duplication or overwriting. The next MO1550821 bulletin was scheduled for 9:30 a.m. JST at that time—not a promised fix. Source: University of Pennsylvania’s public copy of Microsoft admin-center incident notifications.

November 13, 7:10 a.m. update: Recovery efforts were not delivering the expected result

At about 7:03 a.m. JST, Microsoft said the recovery actions already taken had not produced the expected improvement. It reported that critical processes on some affected servers were overloaded, leaving them unresponsive and reducing available service capacity. This added a server-overload problem to earlier health-check failures.

Microsoft was testing the isolation of some affected infrastructure, restarting associated components and gradually returning traffic while checking service stability. It was also considering regional traffic isolation so that areas could be recovered separately. Full restoration remained unconfirmed at that point.

The broader incident notice also listed affected functionality in Microsoft Intune, Defender for Office 365, Power BI and the Microsoft 365 Apps admin center. For Power BI, it specifically mentioned PDF exports of reports with sensitivity labels; in the Microsoft 365 Apps admin center, Cloud Update, Cloud Policy and Inventory were among the named functions. The appearance of a product on the list did not mean every feature of that product was unavailable.

A separate incident, PP1550869, described intermittent failures in Power Platform flows, apps and connectors relying on Microsoft Graph, potentially including Copilot Studio connectors. The Japanese report did not establish that PP1550869 was directly caused by the broader Microsoft 365 incident.

The notifications available at this early stage scheduled follow-up bulletins for 8:00 a.m. (EX1550543) and 8:30 a.m. (MO1550821). Both were information updates, not recovery deadlines. Source: University of Pennsylvania’s public copy of Microsoft admin-center incident notifications.