The short version

The rejections from Outlook.com, Hotmail and Live that we wrote about in Why is Outlook.com rejecting our email? weren’t a new policy. Microsoft has confirmed they came from a faulty update to its spam enforcement rules, which it has rolled back. Mail flow is restored and you don’t need to change anything because of it.

What hasn’t changed: a domain with no DMARC record is still one bad rule change away from the same bounce, and still falls short of the published rules at Microsoft, Google and Yahoo. If you found out this week that you don’t have one, keep the fix.

What Microsoft said

Microsoft published the incident to Microsoft 365 administrators as EX1545193, “Some users may be intermittently unable to send email messages to Outlook.com, Hotmail.com, or Live.com email addresses”. Its final update, on 10 November 2026, says:

  • Root cause: “A recent update to the spam enforcement rules caused email messages to be incorrectly marked and blocked.”
  • Fix: the update was fully rolled back, and Microsoft confirmed mail flow had been restored.
  • Window: from 4:00 AM on Saturday 7 November to 9:02 PM on Monday 9 November 2026, AEST (18:00 UTC on 6 November to 11:02 UTC on 9 November).
  • Bounces: affected senders could see 550 5.7.1 or 550 5.7.23 in the non-delivery report.
  • Next steps: Microsoft is reviewing its update procedures and improving its detection logic to lower the false-positive rate.

The notice expands SPF as “Service Provider Foundation”. It means Sender Policy Framework, the record that lists the servers allowed to send for your domain. 5.7.23 is Microsoft’s SPF-failure bounce; see reading a DMARC bounce for the others.

What we got wrong

Our first post said to treat the rejections as “the new baseline rather than a glitch to wait out”. At the time Microsoft had said nothing, the bounces were reproducible, and the domains being refused had one thing in common: no DMARC record. That read turned out to be wrong. It was a glitch, and it’s over.

Microsoft’s notice doesn’t say why domains without DMARC were hit hardest. A spam rule that leans on authentication results will catch the domains with the weakest authentication first, which fits what senders saw, but that’s our inference, not Microsoft’s explanation.

What to do now

  1. If you’re still seeing the bounce, it isn’t this incident. Keep the full non-delivery report and check the domain with the Domain Checker: a 5.7.23 after 9 November points at your SPF record, not at Microsoft.
  2. If you published DMARC this week, keep it. Nothing about the rollback makes the record unnecessary. A p=none record changes nothing about how your mail is handled; it only declares that the domain uses DMARC and asks receivers for reports.
  3. If you didn’t, publish one anyway. The fault is fixed, but the reason to have DMARC was never this incident.

Why DMARC still matters

  • It’s already required for volume. Since 5 May 2025, Microsoft has required domains sending more than 5,000 messages a day to Outlook.com to publish DMARC. Google and Yahoo set the same bar in 2024. The sender rules post has the details.
  • Receivers lean on it more every year. This week was a mistake, but it was a mistake in the direction everything is moving, and the next rule change will weigh authentication results too.
  • It stops people sending as you. Only at p=quarantine or p=reject, and only once you know every legitimate sender is aligned. The rollout from p=none to p=reject takes about 60 days.

Why monitoring matters

The hardest part of this week for most senders wasn’t the fix. It was not knowing whether the problem was theirs. A bounce that names SPF looks like your mistake whether it is or not.

That’s what DMARC aggregate reports answer. Outlook.com sends a daily report for each domain with an rua address, listing every source that sent as it and whether SPF, DKIM and DMARC passed. If the report for the day of the bounce says your mail was aligned and passing, the problem is on the receiving side, and you can stop changing records and wait for the receiver’s fix with evidence in hand. Without reports, you’re guessing.

Reading those reports by hand doesn’t scale past a day or two of XML. DMARCLoop reads them for you, re-checks your SPF, DKIM and DMARC records every day, and emails you when a sender starts failing or a record breaks, so you hear about it before your customers’ bounces do.

You can start on the free plan, with no card. Add your domain, point your rua at DMARCLoop, and most receivers send their first report within a day or two. See plans for what’s included, or run your domain through the Domain Checker first to see where it stands.