Starting on the night of Friday 6 November 2026, US time, email administrators on the Mailop mailing list began reporting an unusual pattern: messages sent to Microsoft’s consumer mailboxes were being rejected outright when the sending domain published no DMARC record. Deliverability specialist Al Iverson reproduced the behavior in his own tests and documented the episode on Spam Resource, and the reports were independently confirmed by dmarcian, EasyDMARC and the French transactional email provider Sweego, which saw the rejections on its own transactional traffic.
What the bounces looked like
Senders received a permanent failure notice reading:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
Several details made this different from Microsoft’s documented bulk sender rules:
- The rejection hit mail sent to outlook.com, hotmail.com, live.com and msn.com addresses, but not to Microsoft 365 business mailboxes, which accepted the same messages in Iverson’s tests.
- Domains with valid, passing SPF and DKIM were rejected too. Only the missing DMARC record mattered.
- Small senders were affected. Microsoft’s published requirement covers senders of 5,000 or more messages per day and produces a different bounce, 550 5.7.515, which lists the individual SPF, DKIM and DMARC results. The new 5.7.1 bounce only says authentication records are missing.
- The rejections were intermittent. Some messages got through, and some senders saw their mail accepted on a retry, which made the problem easy to miss or misdiagnose.
Microsoft has not announced anything
As of 9 November 2026, Microsoft had published no postmaster notice, no blog post and no service health entry describing the behavior. A moderator on a Microsoft support forum thread wrote on 7 November that forum contributors could not confirm whether the reports had been escalated to the Outlook.com mail protection team, and suggested that intermittent rejections across senders on different providers pointed to something broader than a single misconfigured domain. Microsoft has acknowledged an ongoing issue as a service degradation under investigation, and The Register quotes the forum discussion as suggesting the behavior may have been unintended.
By midday US time on Monday 9 November, Iverson reported that his test messages were going through again and that other senders were seeing the same, so the immediate disruption appears to have ended. Whether it was a deliberate tightening that was rolled back or a filtering bug, Microsoft has not said.
Why senders should treat it as a warning anyway
The episode matters less for what Microsoft intended than for what it demonstrated. For roughly three days, one of the world’s largest mailbox providers rejected mail from unauthenticated domains at any volume, without a single official word of warning. Domains that had relied on “we are too small for the bulk sender rules” or “SPF and DKIM are enough” discovered that both assumptions can fail overnight.
The fix reported by senders on the Microsoft Q&A thread is the same one the industry has recommended for years: publish a DMARC record. Commenters there confirmed that adding a record, even one with a p=none policy, stopped the bounces. A p=none record costs nothing to publish, satisfies the check, and gives you aggregate reports showing who is sending mail as your domain, which is the foundation for moving toward enforcement later.
What to do now
Check every domain you send mail from, including parked domains and internal tools that send notifications, and make sure each one publishes a DMARC record. Confirm that SPF and DKIM are published and aligned with the visible From domain, because DMARC only passes when at least one of them aligns. Then monitor your aggregate reports before tightening policy. If you want authentication, DNS hygiene and deliverability handled by a platform that keeps DMARC in place from day one, sign up for free to Excello Mail.