Security Operations

Microsoft admits spam rule change blocked legit mail to Outlook.com

A faulty Microsoft spam rule bounced legitimate mail to Outlook.com and Hotmail, mostly from domains without DMARC. What UK organisations should do now.

Warning graphic illustrating legitimate email bounced by Outlook.com

Microsoft has admitted that a faulty update to its spam rules caused Outlook.com, Hotmail and Live to reject legitimate email for several days, and it has now rolled the change back. Most of the blocked mail came from domains with no DMARC record, and because none of it was retried, plenty of UK organisations may still not realise their messages never arrived.

What happened

From Thursday 5 November, mail administrators started seeing hard bounces from Microsoft’s consumer email service. The message was blunt: 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records, with a reference code, AS9031519, added a day later. Senders on Microsoft 365, Google Workspace, Zoho and on-premises Exchange were all hit when writing to outlook.com, hotmail.com, live.com and msn.com addresses.

For several days Microsoft said nothing in public. The mailop operators’ list, Microsoft’s own Q&A forum and the trade press filled up with reports, and a number of email security vendors told customers that Microsoft had quietly started requiring DMARC from every sender. On 9 November a forum moderator said the problem had been classed as a service degradation and was under investigation.

The answer came in Microsoft 365 Service Health, which only tenant administrators can see. Incident EX1545193 says an update to Microsoft’s spam enforcement rules caused messages to be wrongly marked and blocked. Microsoft dates the impact from 18:00 UTC on 6 November to 11:02 UTC on 9 November, and it closed the incident early on 10 November once the update had been fully reversed. On 11 November a Microsoft spokesperson told The Register that the issue was fixed and that the company was “continuing to monitor” mail flow. Microsoft says it is reviewing how it ships rule updates and tuning its detection to cut false positives.

The technical picture

The interesting part is what the faulty rule keyed on. EasyDMARC sent test mail from a Zoho-hosted domain whose SPF and DKIM both passed and aligned with the From address, but which published no DMARC record. A live.com mailbox refused it. Seed testing by DMARKOFF found the same thing: once a bare p=none record existed, even one sitting on the parent domain, every one of its 16 Microsoft consumer test inboxes took mail it had previously refused.

So the rule seems to have treated a missing DMARC record as enough reason to block mail that was otherwise properly authenticated. That goes well beyond anything Microsoft has published. Its written requirements, enforced since May 2025 with a different code (550 5.7.515), only require SPF, DKIM and DMARC from domains sending more than 5,000 messages a day.

Some details still don’t add up. MailRoute’s relay logged refusals on 5 November, a day before Microsoft’s stated start time, and those early bounces lacked the AS9031519 code. A smaller group of senders with SPF, DKIM and DMARC all in place were also rejected, sometimes with 550 5.7.23. Microsoft’s notice blames both rejection codes on SPF, although most affected domains had working SPF, and it never mentions DMARC. Until Microsoft publishes a fuller post-incident review, the most defensible conclusion is that a spam rule went wrong, and that the lack of a DMARC record was the strongest factor in what it blocked.

Business tenants on custom domains seem to have been unaffected as recipients; the damage fell on mail to consumer addresses, where many UK small firms and public services reach their customers.

Timeline of the Outlook.com email rejection incident from 5 to 10 November 2026

Why it matters for UK organisations

The most immediate problem is silent loss. A 5xx response is permanent, so Outlook.com did not queue or retry anything. An invoice or a password reset sent in that window may simply have vanished. The sender got a bounce that might have landed in an unmonitored mailbox, and the recipient never knew the message existed.

The second problem is visibility. Microsoft put the authoritative explanation behind the Service Health dashboard. Organisations that send through a hosting provider or a marketing platform, rather than their own tenant, had no way to read it.

The third point is the uncomfortable one. Huge numbers of UK domains still publish no DMARC record at all, often because email was set up years ago by a supplier and never revisited. For three or four days, a Microsoft mistake showed every one of them what it feels like when a major mailbox provider treats that gap as a red flag. That is where Google, Yahoo and Microsoft are all heading anyway, whether by policy or by accident.

Expert view

In my experience, email authentication is a control everyone assumes someone else has dealt with. When we test external estates, missing or broken DMARC on secondary and legacy domains comes up again and again, and it rarely gets fixed because nothing appears to break. This incident shows that something can break without warning.

I would be careful with the quick fix that was going round last week. Publishing v=DMARC1; p=none with no reporting address stopped the bounces, but it tells you nothing and protects nothing. A DMARC record with no aggregate reporting is a badge, not a control. The value comes from the reports: they show you every platform sending as your domain, which ones fail alignment and who is spoofing you. Only a policy of quarantine or reject actually stops forged mail.

There is also an operational lesson for SOC and IT teams. Mail flow is rarely monitored the way endpoints or firewalls are. A sudden rise in non-delivery reports to a single receiving provider is a detectable signal, and it should raise an alert, not wait for a helpdesk ticket three days later.

Microsoft also deserves criticism. Silently changing one of the world’s largest consumer mail services, then explaining it only in an admin-only portal, is poor practice.

What to do now

  1. Find and resend lost mail. Search outbound logs and bounce mailboxes for AS9031519, 550 5.7.1 and 550 5.7.23 rejections to Microsoft consumer domains between 5 and 9 November, and resend anything that matters.
  2. Publish DMARC on every domain you own. Start at p=none with a rua reporting address you actually read. Give parked and non-sending domains p=reject straight away.
  3. Fix alignment properly. Make sure Microsoft 365, Google Workspace, your CRM, helpdesk and marketing tools sign DKIM with your own domain, not the provider’s, and keep SPF under its ten-lookup limit.
  4. Move to enforcement. Once reports show your legitimate mail passing consistently, step up to quarantine and then reject. This is part of secure configuration in Cyber Essentials terms, even if the scheme does not name DMARC.
  5. Monitor mail flow. Alert on spikes in non-delivery reports per destination, and make sure someone with admin rights checks Microsoft 365 Service Health during any email disruption.
  6. Check your suppliers. If a hosting company or agency sends mail as your domain, ask them how they caught and handled this incident.

Bottom line

Microsoft caused this outage, and it has reversed the change. But the domains that suffered most were the ones without DMARC, and that weakness has not gone away. Treat the last week as a free rehearsal: recover the mail you lost, then get proper DMARC in place before a mailbox provider makes it compulsory for real.

Sources

Related Posts