Microsoft 365 outage: the email Exchange Online rejected every night reached the inbox

Summary#

During the global Microsoft 365 outage of 12 and 13 November 2026 (incidents EX1550543 and MO1550821), a server in our lab delivered an email to an Exchange Online mailbox that the platform had been rejecting every time for months.

The email is the nightly backup report from a Proxmox VE hypervisor. It leaves straight from a residential connection, with no authenticated relay, no SPF, no DKIM and a sender in a .local domain that doesn't exist on the Internet. Exchange Online Protection (EOP) had rejected it 104 times in a row since 1 August with the same error: the source IP is listed by Spamhaus. In the early hours of 13 November, in the middle of the incident, the same message was accepted, given a spam confidence level of 1 (SCL 1) and delivered to the inbox.

The message headers and the server logs indicate that, while the platform was degraded, connection-level IP reputation filtering failed open: with no answer available, the email was let through instead of rejected. This article documents what we observed, what we can't confirm, and what Microsoft 365 administrators should review.

The email that never arrives#

The server sends a report every night when the backups finish. Proxmox VE hands it to Postfix, which has no relay configured (empty relayhost), so Postfix looks up the recipient domain's MX and delivers the message directly to EOP on port 25.

That delivery has everything a mail filter should reject:

• A residential source IP, with the ISP's generic reverse DNS (aXX-XXX-XXX-XXX.cpe.<isp>), the kind Spamhaus lists as addresses that shouldn't send email directly.
• A root@<host>.local sender: a domain that doesn't exist in DNS, so it can't have SPF, DKIM or DMARC.
• An unsigned message.

EOP rejected it during the SMTP conversation, at the recipient stage (RCPT TO), before accepting any content:

postfix/smtp: to=<[email protected]>, relay=<tenant>.mail.protection.outlook.com[52.101.x.x]:25,
  delay=0.53, delays=0.02/0.01/0.37/0.13, dsn=5.7.1, status=bounced
  (host said: 550 5.7.1 Service unavailable, Client host [residential IP] blocked using Spamhaus.
   ... AS(1450) [ZR1PEPF0000E45F.eurprd04.prod.outlook.com 2026-11-12T03:29:54.527Z]
   (in reply to RCPT TO command))

There are two rejections per night, not one. After the first, Postfix generates a non-delivery report for root, Proxmox forwards it to the same external address, and EOP rejects it again. The system logs, which start on 1 August, show 104 identical Spamhaus rejections and no deliveries up to 12 November.

The night of 13 November#

Microsoft's incident started on the afternoon of 12 November (UTC) and affected Exchange Online, Outlook, Teams, SharePoint and Defender XDR, among other services. According to Microsoft, a large number of servers became unavailable, the remaining ones had to absorb the load, the affected machines were failing automated health checks, and the process that establishes secure connections was overwhelmed. During recovery, Microsoft extended to 48 hours the time it holds email waiting for delivery.

At 03:29 UTC on 13 November, about nine hours into the incident, Proxmox sent the usual report. This time, Postfix logged this:

03:29:28 postfix/smtp: connect to <tenant>.mail.protection.outlook.com[2a01:111:f403:…]:25: Network is unreachable
03:29:44 postfix/smtp: to=<[email protected]>, relay=<tenant>.mail.protection.outlook.com[52.101.x.x]:25,
  delay=16, delays=0.02/0.01/0.37/16, dsn=2.6.0, status=sent
  (250 2.6.0 <…@<host>.local> [InternalId=…, Hostname=AS8P194MB1896.EURP194.PROD.OUTLOOK.COM]
   78553 bytes in 0.202, 379.010 KB/sec Queued mail for delivery)

The fourth value of delays is the transmission phase, which covers MAIL FROM, RCPT TO and DATA. That's exactly the phase where EOP normally rejects this email.

The connection was set up as fast as on any other night, but the part of the dialogue where the rejection is decided took about 120 times longer. The headers confirm it from Microsoft's side: the EOP front-end server received the message at 03:29:28 and didn't pass it to the next hop until 03:29:43. The missing 15 seconds were spent inside EOP.

What the headers say#

The delivered message carries EOP's anti-spam verdict. These are the relevant headers, with the IP and domain anonymised:

Authentication-Results: mx.microsoft.com 1; dkim=none (message not signed)
 header.d=none;dmarc=none action=none header.from=<host>.local;
X-MS-Exchange-Organization-SCL: 1
X-Forefront-Antispam-Report: CIP:<residential IP>;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;
 H:<host>.local;PTR:;CAT:NONE;…;DIR:INB;
X-Microsoft-Antispam-Mailbox-Delivery: ucf:0;jmr:0;auth:0;dest:I;…

• IPV:NLI: according to Microsoft's documentation, the source IP wasn't found on any IP reputation list. It's the same IP that EOP had rejected the night before, and rejected again later that same day, precisely because it's listed by Spamhaus.
• Empty CTRY: and PTR:: these are the source IP's country and reverse DNS. The IP has a valid PTR record, but the field is empty. We have no email accepted from this IP under normal conditions to compare against, so we note it as a hint rather than as evidence.
• SFV:NSPM and SCL:1: the content filter classified the message as not spam.
• dest:I: the message was delivered to the inbox, not to junk email.
• No SPF or compauth result: Authentication-Results only reports DKIM and DMARC. In the format Microsoft documents, this header also includes the SPF result and composite authentication (compauth), which EOP uses to detect spoofing when the sender domain doesn't publish DMARC.

The decisive data point is IPV:NLI: the reputation check on the source IP returned no listing, and the message went on as if the IP were clean.

Follow-up check#

On 13 November at 15:36 UTC we repeated the SMTP conversation from the same IP against the domain's MX servers, stopping at RCPT TO without sending any message. The result was back to the usual one:

550 5.7.1 Service unavailable, Client host [residential IP] blocked using Spamhaus. ... AS(1450)

One of the front-end servers also answered 421 4.3.2 The maximum number of concurrent server connections has exceeded a limit: the platform still lacked capacity, but IP reputation blocking was being enforced again.

At 15:43 UTC we repeated it against all four MX servers, twice each: all eight attempts were rejected in about 0.05 seconds. So the filter wasn't switched off for the whole incident. We know it failed at least at 03:29 UTC on 13 November and was working again in the afternoon, with the incident still open, but not how long that gap lasted or whether there were others. That's why all email received during the incident should be reviewed, not just the email from one particular hour.

Interpretation: a filter that fails open#

Microsoft hasn't published its post-incident report yet, so we can't confirm which component failed. What we observed fits this scenario:

1. The EOP front-end server accepted the connection normally.
2. At RCPT TO, the reputation lookup for the source IP didn't answer in time, or the component that resolves it was degraded or had been switched off as a mitigation.
3. With no answer, EOP treated the IP as not listed (IPV:NLI) instead of deferring the message with a temporary 4xx error.
4. The rest of the chain (SPF, spoofing, content) was applied partially or not at all, and an unauthenticated email from a residential IP reached the inbox with SCL 1.

We can't fully rule out that the failure was in the Spamhaus lookup rather than in EOP, but for the recipient the result is the same: the control stopped being applied and the system kept accepting email.

Failing open isn't necessarily a design flaw. For a mail service the size of Exchange Online, rejecting all inbound email whenever a dependency is slow to answer would be an outage in itself. But it's a decision with security consequences, and customers should know it exists.

Why it matters#

IP reputation lists are the first barrier against spam and phishing sent by botnets, which come mostly from compromised home devices on residential IPs. Those are exactly the IPs Spamhaus classifies as unfit to send email directly, and exactly the kind of IP our email was sent from.

If that barrier drops during an incident, all the email that's normally cut off at the connection reaches the next filters, which in our case were degraded as well. On top of that:

• Microsoft 365 outages are public and tracked in real time. An attacker can time a campaign to coincide with a degradation window.
• Users are more exposed during an outage. They're expecting support emails, service restoration notices or delayed forwarded messages, all perfect pretexts for phishing.
• Queued email is delivered all at once. With a retention window extended to 48 hours, messages arrive in bulk when the incident ends, and a malicious one can go unnoticed among them.

Recommendations#

For Microsoft 365 administrators#

• Review the email received during the incident. In Microsoft Defender XDR, an advanced hunting query on EmailEvents finds unauthenticated email delivered during the incident window and groups it by source IP:

EmailEvents
| where Timestamp between (datetime(2026-11-12T12:00:00Z) .. datetime(2026-11-14T12:00:00Z))
| where EmailDirection == "Inbound" and DeliveryAction == "Delivered"
| extend Auth = parse_json(AuthenticationDetails)
| where tostring(Auth.DMARC) != "pass" and tostring(Auth.SPF) != "pass"
| summarize Messages = count(), Recipients = dcount(RecipientEmailAddress)
    by SenderIPv4, SenderFromDomain
| order by Messages desc

• Publish DMARC with p=quarantine or p=reject on your own domains. With p=none, protection against spoofing of your own domain relies entirely on EOP's heuristics, which are exactly what was affected.
• Don't rely on a single layer. Transport rules, alerts on unauthenticated delivered email and user training keep working when a dependency of the connection filter fails.
• Warn users during and after an outage to be extra careful with the email they're expecting, especially if it asks for credentials or urgent action.

For anyone sending alerts from a lab or self-hosted server#

Our report getting through was a failure on the recipient's side, not a success of the sending configuration. The right setup is:

• Send through an authenticated relay, for example with a Proxmox VE SMTP notification target pointing to a service mailbox or a transactional email provider, on port 587 with STARTTLS.
• Use a sender in a real domain with correct SPF, DKIM and DMARC.
• Check for non-delivery report loops. If root's mail is forwarded to the same external address that's rejecting the messages, every failure produces a second attempt that will fail too.

Limitations#

• This is a single observation, from a single source to a single tenant. We don't know whether the behaviour affected the whole platform or only part of the front-end servers.
• We couldn't query Spamhaus at the exact time of delivery. We do know that EOP rejected the IP citing Spamhaus the day before and again a few hours later.
• The fail-open explanation is an inference from the logs and headers. We'll update this article if Microsoft's report provides more detail.

References#

• Microsoft 365 Outage Disrupts Outlook, Exchange Online and Teams (SecurityWeek)
• November 13, 2026 – Microsoft 365 Outage (MO1550821), mirror of Microsoft's updates (THERS)
• Microsoft 365 service status
• Anti-spam message headers in Microsoft 365 (Microsoft Learn)
• EmailEvents table in advanced hunting (Microsoft Learn)
• Spamhaus Policy Block List (PBL)