Nobody announced it. No postmaster notice, no service-health entry, no blog post from Microsoft. Since November 5, however, Outlook's consumer mail servers have been rejecting email from domains that don't publish a DMARC record in DNS — and the unusual thing is that the impact doesn't stop at bulk senders. A single message from a small office can bounce.
Here's what happens: if your domain doesn't have a DNS TXT record with the DMARC policy configured, some of your emails sent to outlook.com, hotmail.com, live.com, and msn.com start bouncing back with the error:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS91519)
The AS91519 code changes per message — it's an internal Microsoft server identifier that processed the rejection — but the error message itself is consistent and direct. On the first day, some senders received the same notice without the code in parentheses; the absence of the identifier made the message look even more generic and, somewhat more alarming, as if something were gravely broken rather than merely missing a configuration.
The point that worries email administrators most is not that the block exists, but that it's inconsistent. Outlook doesn't reject all email from a domain without DMARC — it rejects some. One email goes through, another bounces, a re-send may work. For those who don't monitor transport logs, this means clients, vendors, or applicants may be trying to reach out and not knowing the email never arrived. The person on the other side never knows a message was sent.
"Domains with valid SPF, DMARC, and DKIM are also being rejected. It only happens with a small percentage of emails (probably depends on which Microsoft server your message is routed to)," one user wrote on Microsoft's forums, cited by Windows Latest. Another reported that half of the clients who had contacted them since November 5 received a rejection message.
The situation is especially disconcerting because many of these domains have SPF and DKIM configured correctly. What's missing, in the vast majority of cases, is the DMARC record that ties these two mechanisms to the sender's identity. Without it, even if the email passes the authorized IP check (SPF) and has a valid cryptographic signature (DKIM), Outlook can no longer confirm that the message actually belongs to the domain declared in the "From" field.
The record that fixes the problem is a single line in the domain's DNS:
Name: _dmarc Value: v=DMARC1; p=none
The p=none policy is the safe starting point. It declares that the domain uses DMARC and asks receivers to send reports, but tells them to take no action against messages that fail verification. Nothing about how Gmail, Yahoo, or any other provider treats your email changes. The record can be added in minutes through most registrars.
But what did Microsoft actually change?
The short answer is: nobody knows for sure. As of November 6, there was no official announcement. What is known is that Microsoft's published rules have always required SPF, DKIM, and DMARC for senders who send more than 5,000 messages per day to consumer services — the so-called "bulk sender" rule. That rule, updated in May 2025, was clearly aimed at marketing departments and mass-mailing suppliers. Most small businesses correctly assumed it didn't apply to them.
What has changed now is that the requirement seems to have fallen on all senders, regardless of volume. Administrators on the Mailop, Fastmail, and MailRoute lists reported rejections for clients with valid SPF and DKIM aligned to the "From" domain but without DMARC. The Spam Resource tested the scenario on November 7: emails to outlook.com were rejected with code 550 5.7.1, while the same email sent to a corporate Microsoft 365 domain was accepted without issue.
This confirms that the change does not affect Microsoft 365 (the enterprise service), only the consumer domains — the ones regular users use for personal email. The filter is running on a different layer of the system, which explains why domains with proper enterprise configuration don't suffer, but an email from a small domain to an individual Hotmail account gets blocked.
Why do so many domains still not have DMARC?
The answer is that DMARC has always been seen as something for large senders. If you don't send 5,000 emails a day, you didn't need to worry. The result is that hundreds of thousands of domains — many of them small businesses, personal websites, charities, and public agencies — never configured the policy. A survey by DmarcDkim.com of 982 exhibitors at it's.BB (a German IT trade show) showed that only 364 let recipients reject spoofing from their address — meaning about 63% of exhibitors had no DMARC protection, even though they were technology companies.
The history of DMARC evolution among major providers shows that Microsoft's change is not isolated. In May 2025, Outlook.com began requiring full authentication for high-volume senders. In November 2025, Gmail announced it was "strengthening enforcement" with temporary and permanent rejections. Now, in November 2026, Outlook is extending the requirement to all senders.
Each provider follows the same pattern: first the spam filter, then the high-volume requirement, then the universal requirement. DMARC with p=none, which today is the floor for receiving email on Outlook, is also the first step toward p=reject — which tells receivers to refuse messages that spoof the domain. When that happens, the situation will be even more dramatic, because many domains that are now at p=none are not prepared for p=reject.
What this means for email infrastructure
Email is the oldest protocol on the internet that still works with the same simplicity as 1982. But that simplicity was its undoing: without native authentication, email was the first digital service to be widely exploited by scammers, and DMARC was the first practical solution to the problem. What Microsoft did today was make authentication mandatory on at least one of the world's largest email providers — and, importantly, without advance notice.
The lack of an announcement might seem like just a corporate communication failure, but the practical effect is a real-world test at scale: how many domains break when DMARC becomes a requirement, not a recommendation? The answer will tell the world whether the global email infrastructure is ready for an era without spoofing.
Administrators who already configured DMARC likely felt nothing but relief — the filter was already in place. For the rest, the learning curve is short: add a TXT record, verify that SPF and DKIM pass for the "From" domain, and monitor the reports that start arriving. The difference is that this time, Microsoft won't wait.
The question that remains is how many other lost emails exist today in domains that thought they had the basics configured — and how many more will be rejected before DMARC stops being the floor and becomes the wall.
Sources: MailRoute, Spam Resource, Windows Latest
✓ Independent sources cross-checked and verified before publishing
