Hotmail spent a weekend refusing mail from domains without DMARC

12 November 2026 · Carl Heaton · Security Infrastructure

If your business emails customers, applicants, or suppliers who use Hotmail or Outlook.com addresses, some of what you sent between 5 and 9 November may never have arrived. The person you wrote to was not told. Whoever sent it got a bounce full of acronyms that looked like a glitch.

From Friday evening, 6 November, to Monday morning, 9 November, Microsoft's free email service refused a share of the mail sent from business domains. Independent tests found the trigger was a missing DMARC record, a short public setting that says how your email should be checked. Microsoft has since said the cause was a faulty update to its spam rules, and it has rolled the update back. Mail is flowing again.

That leaves two jobs. Resend anything important that bounced, and publish the record anyway, because it takes minutes and costs nothing.

What happened

Microsoft logged the problem as incident EX1545193 in the Microsoft 365 admin centre. Its final update gives the cause plainly: "A recent update to the spam enforcement rules caused email messages to be incorrectly marked and blocked, which led to impact." It puts the start at 6pm UK time on 6 November and the end at 11:02am on 9 November. Only Microsoft 365 administrators can read it, but there is a public copy. A Microsoft spokesperson later told The Register it had fixed "an issue that may have prevented some email messages from reaching Outlook.com, Hotmail and Live addresses".

Some senders saw it sooner. Email security firm MailRoute logged its first refusals on 5 November, a day before Microsoft's start time.

Three things made it easy to miss. It hit small senders, not just the bulk marketers Microsoft's published rules are aimed at: a one-line reply from a small office could be refused. It was intermittent, so one message went through and the next bounced. And nobody announced it.

What the bounce looked like

The bounce came back to the sender with a line like this:

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

Microsoft's notice says some senders got 550 5.7.23 instead, which mentions SPF. Despite the wording, MailRoute says most of the refused domains it saw had working SPF, and many had DKIM too. What they lacked was DMARC. Testing firm DMARKOFF sent a message to 16 Outlook.com and Hotmail mailboxes from a domain with no DMARC record during the fault, and all 16 refused it. With even the most basic DMARC record in place, all 16 accepted the same message.

A 550 is a permanent refusal. Mail turned away like this is not retried, so it was never delivered.

The three records, briefly

We explained these in who is allowed to send email as you. All three are short text entries in DNS, the public address book for your domain:

SPF (Sender Policy Framework) lists the servers allowed to send mail for your domain.
DKIM (DomainKeys Identified Mail) puts a digital signature on each message.
DMARC (Domain-based Message Authentication, Reporting and Conformance) checks that SPF or DKIM matches the address in the From line, and tells receiving servers what to do with mail that fails.

What to do this week

Find the bounces and resend. Ask everyone who emails customers to search their inbox for "Message lacks SPF/DKIM/DMARC" and "5.7.23" from 5 November onwards. Start with the accounts, bookings, and sales mailboxes. Resend the invoices, quotes, and confirmations that matter.

Check whether you have a DMARC record. The National Cyber Security Centre's free email security check will tell you. On a Windows PC you can also type nslookup -type=txt _dmarc.yourdomain.co.uk into a command prompt. A line starting v=DMARC1 means you have one.

If you have none, add a starter record. Create a TXT record named _dmarc with the value v=DMARC1; p=none. The p=none part means "take no action on failures, just note them", so it changes nothing about how other mail services treat you. In DMARKOFF's tests it was enough to get through during the fault, and a record on your main domain also covered its subdomains.

Make sure SPF or DKIM passes for your own domain. A DMARC record only passes if one of them matches your From address. A common gap: Microsoft 365 signs mail with its own onmicrosoft.com address until someone turns on DKIM for your domain, and that signature does not count. Check the other services that send as you too, such as the accounts package and the newsletter tool.

Plan the next step. p=none is the start, not the finish. Add a reporting address, read the reports, then move to "quarantine" and "reject" once all your genuine mail passes. That is what stops other people sending email as you.

If bounces carry on after 9 November, this fault is not the cause. Check SPF and DKIM for whichever service sent the message. If you have Microsoft 365, your administrator can report it to Microsoft with the message IDs, which is what Microsoft asked affected customers to do during this incident.

The questions for your IT provider

If someone else looks after your email, two questions cover it:

Did any of our email to Hotmail or Outlook.com addresses bounce between 5 and 9 November, and has it been resent?
Do we have a DMARC record, does every service that sends as us pass SPF or DKIM, and when do we move to "reject"?

If the answer to the second is "we don't need DMARC, we're not a bulk sender", that weekend is the reply.

Why keep a record nobody demands

Microsoft calls that weekend a fault, not a new rule. Its published sender rules have required SPF, DKIM, and DMARC since 5 May 2025, but only for domains sending more than 5,000 messages a day to Outlook.com. Google's email sender guidelines have asked the same of senders above 5,000 a day to Gmail since February 2024.

That weekend showed what happens when a big mailbox provider's filter leans on those records, even by mistake. In the tests, domains with a basic DMARC record carried on as normal. Domains without one had mail refused with no warning. Whether or not that happens again on purpose, the record is free and it is the first step to stopping criminals sending email in your name.

How Steelwise can help

Finding everything that sends email in your name, and getting from no record to "reject" without losing genuine mail on the way, is a small, well-defined piece of infrastructure advisory work. Get in touch if you would like help with it.