On 10 November 2026, Microsoft closed the book on one of the most talked about deliverability incidents of the year. In its Microsoft 365 Service Health portal, under incident EX1545193 titled “Some users may be intermittently unable to send email messages to Outlook.com, Hotmail.com, or Live.com email addresses”, the company confirmed the cause: “A recent update to the spam enforcement rules caused email messages to be incorrectly marked and blocked, which led to impact.”
In other words, the wave of rejections that hit senders from 5 to 9 November was not a quiet expansion of Microsoft’s DMARC requirements to small senders. It was a faulty rule update that has been fully rolled back.
The official timeline
Microsoft dates the impact from 18:00 UTC on 6 November to 11:02 UTC on 9 November. During that window, Outlook.com, Hotmail, Live and MSN refused part of the mail sent from domains that publish no DMARC record, returning the bounce 550 5.7.1 “Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)”. On 9 November at 05:24 UTC Microsoft asked anyone still affected for fresh Network Message IDs and example messages in .eml format, and at 05:36 UTC on 10 November it closed the incident, saying the rule update was fully rolled back and that it is reviewing its update procedures and improving detection to cut false positives.
The independent evidence backs the sender side of the story. MailRoute logged the first refusals on 5 November, before Microsoft’s stated start time, and EasyDMARC reproduced the rejection with a test domain that had passing, aligned SPF and DKIM but no DMARC record. DMARKOFF seed testing found that publishing even a minimal p=none DMARC record at the parent domain was enough for all 16 of its Outlook.com and Hotmail test mailboxes to accept a message they had refused without one.
What senders should do now
Three practical conclusions follow from the incident.
First, resend anything that bounced. A permanent 550 rejection is never retried by the sending server, so invoices, quotes and customer replies refused during those days were simply never delivered, and the recipient has no idea they were sent.
Second, if you published a DMARC record in a panic last week, keep it. At p=none it changes nothing about how mailbox providers treat your mail, it satisfies the bulk sender rules that Google and Yahoo have enforced since February 2024 and that Microsoft has applied to Outlook.com high volume senders since May 2025, and it gives you aggregate reports showing who sends mail as your domain. That visibility is the first step toward p=reject, where receivers refuse forgeries of your domain outright.
Third, treat the whole episode as a free stress test. Microsoft says the fault was unintended, but for three days its infrastructure did reject unauthenticated domains at any volume, and the domains that had DMARC published were the ones that got through. The cheapest insurance against the next enforcement change, intended or not, is to have the record already in place, with SPF and DKIM correctly aligned, on every domain you send from, including parked domains and internal notification tools.
If you would rather have authentication and DNS hygiene handled for you on every sending domain, sign up for free to Excello Mail.