Outlook.com quietly rejects mail from domains without DMARC

Silent rejections began November 5

Since November 5, 2026, Microsoft's consumer mail platforms — Outlook.com, Hotmail, Live and MSN — have been refusing part of the inbound mail sent from domains that publish no DMARC record. The change was first documented by MailRoute, an email filtering provider that spotted the bounces in its own outbound logs, in a post that surfaced on the Hacker News front page.

Blocked senders receive a bounce reading "550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records", in some messages followed by the code AS9031519. According to MailRoute, the wording overstates the problem: most of the affected domains it examined had working SPF, and many also had DKIM signatures. The one thing they all lacked was a DMARC record tying those mechanisms to the visible From address.

How this differs from Microsoft's published rules

Microsoft already enforces authentication for bulk senders. Since May 2025, domains delivering more than 5,000 messages a day to Outlook.com must pass SPF, DKIM and DMARC, or face a 550 5.7.515 rejection. That rule targets high-volume marketing traffic, and small senders generally assumed it did not apply to them.

MailRoute identifies three ways the new behavior breaks from that policy. It hits low-volume senders, so even a short reply from a small office can bounce. It was never announced — as of November 6 the company says Microsoft had published no postmaster notice, blog post or service-health entry about it. And the bounce does not say which check failed, whereas the 5.7.515 rejection lists SPF, DKIM and DMARC results individually.

Partial blocking makes the problem easy to miss

Microsoft refuses only some of the mail from an affected domain, the report notes: one message to a Hotmail address delivers, the next bounces, and a resend may go through. That intermittence is what makes the issue insidious. The sender sees a bounce full of acronyms, assumes a glitch and moves on, while the recipient never learns a message was sent at all.

For organizations that reach people at personal addresses — patients, applicants, customers, parents, members — the losses are invisible: invoices that never arrive, appointment confirmations that vanish, replies that read as being ignored.

The fix is one DNS record

Checking whether a domain is exposed takes seconds: run dig +short TXT _dmarc.example.com and see whether anything comes back. No output means no DMARC record, which is the condition this rejection targets.

The remedy is a TXT record named _dmarc with the value v=DMARC1; p=none. A p=none policy tells receivers to take no action on authentication failures and to send aggregate reports, so publishing it does not change how Gmail, Yahoo or any other provider treats the domain's mail.

There is one condition. DMARC passes only if SPF or DKIM aligns with the domain in the From header. MailRoute points to Microsoft 365 as a common trap: the service signs with its own onmicrosoft.com domain until DKIM is enabled for the sender's own domain, and that default signature does not count toward DMARC.

Why it matters

This is the pattern every major mailbox provider has followed: authentication requirements start with bulk senders, arrive with an announced deadline, then quietly become the baseline for everyone. DMARC at p=none is now effectively the floor for reaching Microsoft's consumer mailboxes, not a best practice. That shift also has a security payoff — spoofed domains are the starting point for much phishing and business email compromise, and a domain that authenticates is far harder to impersonate. Any operator whose mail reaches outlook.com, hotmail.com, live.com or msn.com addresses should check for a DMARC record and publish one now, since the failure mode is silent and the fix takes minutes.