Your November Bounce Data Is Contaminated

If your outbound numbers fell off a cliff last week and the bounces came back from Outlook.com, Hotmail, Live or MSN addresses, do not start rebuilding your sending infrastructure. A meaningful share of those Outlook DMARC rejections were Microsoft's own fault, and Microsoft has now said so.

The sequence is short and worth getting exactly right, because the dates decide what you can trust. Mail operators began logging hard rejections from Microsoft consumer addresses on November 5, 2026. The bounce carried a 550 5.7.1 status and the text "Message rejected: Message lacks SPF/DKIM/DMARC Auth Records", followed by the reference AS9031519. Some senders also saw 550 5.7.23.

The obvious reading was that Microsoft had quietly tightened its authentication requirements. That reading was wrong, and the error message is why everybody got it wrong. The common factor across the rejected domains was not a broken SPF record. It was no DMARC record at all, on domains whose SPF and DKIM checks were passing fine.

Then it got stranger. Administrators with correctly configured SPF, DKIM and DMARC reported rejections too, and the same domain would get one message through and have the next one bounced. Intermittent failure on a static DNS configuration is not a policy. It is a fault, which is what The Register reported on November 9 before Microsoft confirmed it.

What Actually Happened To Outlook Mail On November 5

Microsoft began rejecting inbound mail to Outlook.com, Hotmail, Live and MSN addresses on November 5, 2026, returning an authentication error to senders whose domains had published no DMARC record, and the rejection was a hard 550 rather than a deferral or a quiet move to the junk folder.

A hard rejection is the part that matters operationally. A message filtered into junk still counts as delivered by most sending platforms, so it degrades your results quietly. A 550 is a bounce, and bounces are what every sequencer, every warmup tool and every deliverability dashboard treats as the loudest possible signal that something is wrong with you.

Read the first two rows against the last five. The published rule has been in force since May 2025 and it covers domains sending more than 5,000 messages a day to consumer mailboxes. Violations of that rule return a different code, 550 5.7.515. The November bounces did not match the published rule, which is the detail that told operators early that this was not an announced tightening.

Microsoft published no postmaster notice, no service health entry and no blog post while the rejections were happening. The first official acknowledgement was a moderator comment on a community forum. For a change that was bouncing transactional mail, that is a communications failure on its own, separate from the technical one. We walked through the published Microsoft rules and what they actually require when the bulk sender crackdown first landed, and none of what shipped in November was in them.

Why The Outlook DMARC Rejections Hit Senders Under The Threshold

Microsoft's published requirement covers domains sending more than 5,000 messages a day to consumer mailboxes, but the November rejections caught senders nowhere near that volume, including domains where a single one line email was bounced.

That is the mechanical reason outbound teams should care more than most. A cold email program is usually built on a fleet of low volume sending domains, each deliberately kept far below any bulk threshold. The whole architecture assumes that per domain volume is the thing that keeps you out of bulk sender enforcement. An enforcement rule that fires on a missing DNS record instead of on volume does not care how carefully you split your sends.

Check your own fleet honestly here. Sending domains get spun up in batches, and DMARC is the record that most often gets skipped, because SPF and DKIM are required to send at all while DMARC is only required to be believed. A newly provisioned domain with SPF and DKIM configured and no DMARC record is the exact profile that bounced in November. We made the case for publishing DMARC on every sending domain rather than only the primary when we looked at what DMARCbis changes for sending domains, and this week is the expensive version of that argument.

“An enforcement rule that fires on a missing DNS record rather than on volume does not care how carefully you split your sends.”

There is a second population in these reports that is harder to explain, and honesty requires flagging it rather than smoothing it over. Some administrators with correct and aligned SPF, DKIM and DMARC still saw rejections, and it is not established whether those share a cause with the missing record cases. Neil Jenkins, chief product officer at Fastmail, reported cases on the mailop operators list involving customers' own domains. Treat the missing record explanation as well evidenced and the rest as open.

How To Tell Outlook DMARC Rejections From A Real Reputation Problem

Separating Microsoft's fault from a genuine sender reputation problem comes down to three things: the exact bounce code, the recipient domain, and the date window. Authentication rejections name a missing record, reputation blocks name volume, complaints or listings.

The distinction between a 4xx and a 5xx is where most teams lose money in a week like this, because the panic response to both looks the same. A 5xx carrying an authentication string is a configuration verdict. A 4xx is a traffic condition. Our breakdown of how hard and soft bounces should drive different decisions applies without modification here, and it is the filter to run before anyone proposes burning a domain.

Then isolate by recipient domain, which is the single most useful cut available this month. The November fault was confined to Microsoft consumer mail. If your bounce rate rose on outlook.com, hotmail.com, live.com and msn.com while gmail.com and your recipients' corporate Microsoft 365 tenants held steady, you are looking at the incident and not at your reputation. If the rise is across every recipient domain, the incident is not your explanation and you have a real problem to go find.

The numbers in that example are arithmetic rather than measurement, and the point is the shape, not the values. A blended bounce rate is an average across receivers, so a fault at one large receiver can dominate it while every other signal stays flat. That is why receiver level reporting matters more than a single headline figure, and why we keep pushing teams toward per receiver monitoring rather than blended dashboards.

The Rollout Was Botched, The Direction Was Not

Microsoft's handling of the November change was poor: no advance notice, no postmaster bulletin, and an error message that named SPF when a missing DMARC record was the actual trigger. The direction of travel it revealed, however, is not in question.

Frank Dickson of Dickson Research, quoted in Computerworld's coverage, put the criticism and the conclusion in the same breath. On the handling: "Doing it without notice, with an error message that points at the wrong problem, makes a mess." On where this goes: "the rollout was botched, but the destination is not in doubt." Both halves are right, and outbound teams tend to only hear the first one.

The destination is DMARC as a precondition for delivery rather than a best practice, applied to all senders rather than to high volume senders. Gmail and Yahoo moved the floor in 2024. Microsoft published its consumer rules in April 2025 and enforced them from May. Every published step since has widened the population covered and narrowed the tolerance. A fault that applied the strictest reading to everybody for six days is a preview, even though it was an accident.

Repair Your Bounce Data Before You Touch Your Records

Any deliverability decision made on November 5 to 11 bounce data from Microsoft consumer domains rests on contaminated input, so the first job is quarantining that window in your reporting, not rewriting DNS under pressure.

Sequence the work in that order for a reason. DNS changes made during the incident were made on a false diagnosis, and some of them will have introduced real problems that the incident was masking. Publishing a DMARC record is safe and correct and you should do it today. Rewriting SPF, rotating sending domains, pausing warmup pools or cutting daily volume are not safe, and if any of those happened last week they deserve a second look now that the cause is known.

There is a broader lesson that outlasts this incident, and it is about what your deliverability numbers actually measure. A bounce rate is a claim about your sending practice, computed from data generated entirely by receivers you do not control and cannot audit. Most of the time that works. In a week where one receiver changes behaviour without notice, every number downstream becomes a statement about that receiver instead, and nothing in the dashboard tells you which kind of week you are in.

The teams that handled this one well were not the ones with better tooling. They were the ones who split bounces by recipient domain as a matter of routine, so the anomaly showed up as a Microsoft shaped spike on day one rather than as a general collapse in sender reputation. That cut costs nothing to build and it is the difference between a quiet note in a weekly report and a fortnight spent rebuilding infrastructure that was never broken. The same discipline protects B2B programs whose recipient mix is concentrated in a handful of mailbox providers.

See where you are cited today

A free snapshot audit of your rankings and AI citations before we ever talk.