Microsoft's root cause for EX1545193, checked against sender logs
Overview
Microsoft blames a spam-rule update for the Outlook.com rejections of November 2026 and dates them from 6 November. Sender logs start a day earlier and show a rule that refused domains with no DMARC record.
Microsoft published one sentence of root cause for incident EX1545193, in which Outlook.com, Hotmail and Live refused legitimate mail in early November 2026:
A recent update to the spam enforcement rules caused email messages to be incorrectly marked and blocked, which led to impact.
We checked the notice (opens in a new tab) that carries that sentence against the logs and tests that mail operators published during the incident. MailRoute’s outbound logs (opens in a new tab) show the rejections on 5 November, a day before the start time Microsoft gives. Microsoft tells admins their users got an NDR for an SPF violation. The server’s reply said the message “lacks SPF/DKIM/DMARC Auth Records”, and in the tests operators ran, mail was refused when the sender’s domain had no DMARC record, with SPF and DKIM passing. Microsoft filed the incident under Exchange Online, yet senders on Zoho, Mailgun, Fastmail and Postfix were refused in the same way.
Checked 10 November 2026.
What Microsoft published
The notice sits in the Microsoft 365 admin center under Health, Service health, and reading it takes an admin role (opens in a new tab). We read the copy that the University of Pennsylvania republishes from its own tenant every 15 minutes and keeps for 30 days. It has two entries. The first is dated Monday 9 November at 05:24 UTC, and the second, on Tuesday 10 November at 05:36 UTC, calls itself “the final update for the event”.
| Field | What the notice says |
|---|---|
| Title | “Some users may be intermittently unable to send email messages to Outlook.com, Hotmail.com, or Live.com email addresses” |
| Service | Exchange Online, classified as an incident |
| Start | “Friday, November 6, 2026, at 6:00 PM UTC” |
| End | “Monday, November 9, 2026, at 11:02 AM UTC” |
| Symptom | “Users may have received a Non-Delivery Report (NDR) reporting 550 5.7.1 or 550 5.7.23 due to Service Provider Foundation (SPF) violation.” |
| Fix | “We’ve fully rolled back this update and confirmed that mail flow has been restored and impact is resolved.” |
| Next steps | “We’re reviewing our update procedures and improving our mail detection logic to lower the false positive rate and ensure that legitimate email messages aren’t inaccurately blocked.” |
The expansion of SPF in the symptom line is Microsoft’s. Outside the admin center, the only word from the company that we found is a moderator’s summary of the notice on its Q&A forum. The Register (opens in a new tab) wrote on 9 November that it had asked Microsoft for more information and had no reply.
The rejections began a day before the stated start
| When (UTC) | What happened |
|---|---|
| 5 Nov | MailRoute first sees the bounce in its outbound logs |
| 6 Nov, 09:05 | A sender reports the bounce on Microsoft’s Q&A forum (opens in a new tab) |
| 6 Nov, 18:00 | The incident starts, according to the notice |
| 7 Nov, about 00:00 | Operators begin comparing notes on the mailop list (opens in a new tab) |
| 9 Nov, 05:24 | First entry in the notice |
| 9 Nov, about 10:30 | one.com sees the refusals stop (opens in a new tab) |
| 9 Nov, 11:02 | The incident ends, according to the notice |
| 10 Nov, 05:36 | Final entry, with the root cause |
The forum question sits on Microsoft’s own site and carries Microsoft’s own timestamp. A minute later the asker pasted the NDR:
Microsoft Q&A, question 6063210, captured 10 November 2026 at 17:53 UTC with the browser clock set to UTC.
That question is almost nine hours older than the notice’s start time. Later replies from Outlook.com end with a tag, (AS9031519). The bounce in this NDR has none, and MailRoute says the same of its first day. A sample published by LazyAdmin (opens in a new tab) carries the tag and a server timestamp of 09:39 UTC on 6 November. Two versions of the reply were in circulation before the hour at which Microsoft says the incident began.
The end of the window holds up. one.com’s 10:30 is half an hour from Microsoft’s 11:02, and DMARKOFF’s 16 test mailboxes, which had all refused its mail on 7 November, all accepted it at 15:09 UTC on 9 November.
Between the forum question and the first entry in the notice lie 68 hours. That entry asks affected customers for “fresh Network Message IDs, fresh logs, and examples” to help Microsoft find out “why impact persists”, and it schedules the next update for Wednesday 11 November. The end time Microsoft gives is about five and a half hours after it.
The rule refused domains with no DMARC record
The notice puts the bounce down to an SPF violation. Five operators tested or counted the refusals while the rule was live, and their results point at DMARC.
| Who and when | What they sent or counted | What Outlook.com did |
|---|---|---|
| DMARKOFF (opens in a new tab), 7 Nov, 21:22 UTC | Mailgun, SPF and DKIM passing and aligned, no DMARC record at the subdomain or its parent | Refused at 16 of 16 Outlook.com and Hotmail mailboxes |
| DMARKOFF, 7 and 8 Nov | The same mail with a record at the subdomain or only at the parent, p=none included |
Refused 0 of 112 |
| Al Iverson (opens in a new tab), 7 Nov, 19:52 UTC | His own low-volume domains with the DMARC record deleted, sent from Postfix | Refused by outlook-com.olc.protection.outlook.com. A Microsoft 365 tenant accepted the same mail |
| EasyDMARC (opens in a new tab), 8 Nov, 14:01 UTC | Zoho Mail, SPF and DKIM passing and aligned, no DMARC record | Refused by live-com.olc.protection.outlook.com |
| Dan Malm, one.com (opens in a new tab), 8 Nov, 09:40 UTC | Two groups of customer domains with no DMARC record | Only the group whose DNS answers NXDOMAIN for _dmarc was affected, he wrote. The group answering NOERROR with no data was not |
| Jarland Donnell, MXroute (opens in a new tab), 9 Nov, 02:45 UTC | One rotated mail log | 367 sender domains refused, 286 of which answered NXDOMAIN for _dmarc when he checked |
mailop list archive, message 27578, captured 10 November 2026 at 18:37 UTC.
Our reading of those six rows is that the rule looked up the sender’s DMARC record, at the From domain and at its parent, and refused the message when DNS answered that no such name exists, even when SPF and DKIM passed.
Microsoft has published nothing about the rule’s logic, so this stays an inference from other people’s tests.
Some reports sit outside that reading. MXroute’s other 81 domains did not answer NXDOMAIN when Donnell looked. Some of them may have added a record after their mail bounced, but his message does not say. DMARKOFF and EasyDMARC both mention forum reports of refusals with all three records in place, but neither reproduced one.
Exchange Online was one sending platform among many
The notice lists the incident under Exchange Online and speaks of users who could not send. Microsoft’s consumer service ran the servers that refused the mail: outlook-com.olc.protection.outlook.com in Iverson’s Postfix log, live-com.olc.protection.outlook.com in EasyDMARC’s bounce. We looked up the MX records on 10 November, and outlook.com, hotmail.com, live.com and msn.com each point at a host of that form.
Senders on many platforms met those servers. The table above has mail from Mailgun, Postfix and Zoho. On the mailop list, Fastmail (opens in a new tab) reported the same refusals for customers with their own domains and MailRoute (opens in a new tab) for its customers. Mail addressed to Microsoft 365 tenants went through: Iverson’s did, and so did DMARKOFF’s to five Microsoft 365 mailboxes. Only senders on Exchange Online had a notice to read.
The NDR in the screenshot above is what an Exchange Online user received: a headline of “SPF validation error”, status code 550 5.7.23, and advice to add spf.protection.outlook.com to the SPF record. Outlook.com’s reply appears only under Error Details, after an arrow. Microsoft’s NDR reference (opens in a new tab) lists 5.7.23 as “The message was rejected because of Sender Policy Framework violation”. Senders on other platforms received the bare 550 5.7.1 sentence. The SPF wording in the notice matches the text Exchange Online added around it.
What the notice leaves open
The notice does not say which rule it was, or whether it was meant to ship. Microsoft’s published requirement (opens in a new tab) covers domains that send more than 5,000 messages a day, and the announcement of it (opens in a new tab) gives the rejection as “550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.” November’s refusals carried status 5.7.1 and a different sentence, and they reached senders far below that volume: one mailop member wrote (opens in a new tab) that he sends about 20 messages a week to Microsoft’s services. A bulk-sender rule applied to everyone and a new rule released early would both fit “incorrectly marked and blocked”.
The notice gives no count of messages, tenants or domains. MXroute alone found 367 sender domains in one log.
Nothing in it covers the mail that was refused. A 550 is a permanent failure, and RFC 5321 (opens in a new tab) says a client “SHOULD NOT repeat the exact request”, so a sending server gives up at the first answer. Iverson’s Postfix logged status=bounced within a second. The rollback delivered none of that mail.
Microsoft’s service description (opens in a new tab) promises more for some incidents. Where there was “broad and noticeable impact across a large number of organizations”, it says, “a preliminary post-incident review (PIR) will be delivered via your Service health within 48 hours of incident resolution, followed by a final PIR within five business days”, and the report includes a “Detailed timeline of impact and resolution measures”. Other incidents get a closure summary. Forty-eight hours after the stated end is 11:02 UTC on 11 November, and the entry of 10 November already calls itself final. If a review appears, we will add it to this post.
If you send mail to Outlook.com
Search your mail logs from 5 November for the sentence, because the early replies lacked the (AS9031519) tag:
grep -F 'Message lacks SPF/DKIM/DMARC Auth Records' /var/log/mail.logWhatever that finds has to be sent again. Then look up the DMARC record of the domain in your From address. This is the answer for a domain that has one:
dig +short TXT _dmarc.example.org"v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"In DMARKOFF’s test a record with p=none was enough, at the domain itself or at its parent. Microsoft has required one from senders above 5,000 messages a day since May 2025.
Sources
- Microsoft’s Incident Reports for PennO365 (opens in a new tab), University of Pennsylvania, extract of 10 November 2026. Microsoft 365 Service Health incident EX1545193, entries of 9 and 10 November 2026: every quotation from the notice, its times and its fields.
- SPF Validation Error (opens in a new tab), Microsoft Q&A question 6063210, asked 6 November 2026 at 09:05 UTC: the first bounce on Microsoft’s own site and the text of the Exchange Online NDR.
- Outlook.com Rejected Mail From Domains Without DMARC (opens in a new tab), MailRoute, 6 November 2026, updated 10 November: bounces in its outbound logs from 5 November, and the first day’s reply without the code.
- Resolved: Microsoft Rejecting Mail Lacking DMARC (opens in a new tab), Spam Resource, Al Iverson, 10 November 2026: his test of 7 November, the Postfix log line and the Microsoft 365 tenant that accepted.
- Outlook.com Now Rejects Mail Without DMARC: We Tested the New 550 5.7.1 (opens in a new tab), DMARKOFF, 8 November 2026, updated 10 November: 16 of 16 refused, 0 of 112 refused with a record, the parent-domain and
p=nonecases, the Microsoft 365 mailboxes and the repeat on 9 November. - Microsoft Briefly Rejected Mail From Domains Without DMARC. Here’s What We Know. (opens in a new tab), EasyDMARC, 9 November 2026, modified 10 November: the Zoho Mail test of 8 November and its bounce.
- Microsoft requiring DMARC now or just us? (opens in a new tab), mailop mailing list, 6 to 10 November 2026, messages 27567, 27569, 27572, 27573, 27575, 27578 and 27583: reports from MXroute, MailRoute, Fastmail and one.com, the NXDOMAIN observation, the domain counts and the time the refusals stopped.
- Outlook.com Rejects Email – Message lacks SPF/DKIM/DMARC Auth Records (AS9031519) Fixed (opens in a new tab), LazyAdmin, Rudy Mens, updated 10 November 2026: a reply with the code, stamped 2026-11-06T09:39:53.095Z.
- Service health and continuity (opens in a new tab), Office 365 platform service description, Microsoft Learn, updated 22 July 2026: when Microsoft issues a post-incident review and what it contains.
- How to check Microsoft 365 service health (opens in a new tab), Microsoft Learn, updated 30 October 2026: the admin roles that can read Service health.
- Email nondelivery reports (NDRs) and SMTP errors in Exchange Online (opens in a new tab), Microsoft Learn, updated 25 August 2026: the meaning of status code 5.7.23.
- Strengthening Email Ecosystem: Outlook’s New Requirements for High‐Volume Senders (opens in a new tab), Microsoft Defender for Office 365 Blog, updated 30 April 2025, and the Outlook.com postmaster announcements (opens in a new tab): the rule for domains above 5,000 messages a day and its 5.7.515 rejection.
- RFC 5321, Simple Mail Transfer Protocol (opens in a new tab), IETF, October 2008, section 4.2.1: a 5yz reply is permanent and the client should not repeat the request.
- Outlook.com bounces legit emails as Microsoft’s authentication crackdown goes sideways (opens in a new tab), The Register, 9 November 2026: its request to Microsoft for comment.
