Between November 5 and 9, 2026, an incident occurred in which some emails from domains that did not publish DMARC records were rejected by Microsoft’s consumer email services, including Outlook.com, Hotmail, Live, and MSN. Because the issue arose without an official announcement from Microsoft, it caused confusion among many users and businesses.

Outlook.com Rejected Mail From Domains Without DMARC | MailRoute
https://mailroute.net/blog/outlook-rejecting-email-without-dmarc

This issue particularly affected small-scale senders and companies that routinely sent emails to Outlook.com users. Microsoft’s sender rules normally target high-volume senders, but this time, it was notable that small senders outside the scope of those rules were also affected. The main error messages received by senders were as follows:

• "550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)"
• "550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records" (No code)

The above errors suggest a lack of SPF, DKIM, and DMARC authentication records. In reality, however, there were many cases in which SPF and DKIM were working but only the DMARC record was missing. A more serious problem was that only some emails from affected domains were intermittently rejected, meaning that senders might not notice the issue and could leave it unaddressed.

According to Microsoft, the issue was caused by an update to spam-prevention rules that unintentionally blocked emails. Microsoft rolled back the update and announced that the issue was resolved at 11:02 UTC on November 9, 2026.


The fundamental solution to this issue is to add a DMARC record to the domain. Specifically, adding the following TXT record to the DNS enabled emails to be sent normally:

• Name: _dmarc
• Value: v=DMARC1; p=none

“p=none” declares that DMARC is being used and requests reports, but does not request any action in the event of an authentication failure, making it a safe setting. Adding “p=none” does not affect how other recipients handle the email. One important point is that, for DMARC to function properly, either SPF or DKIM must be valid for the domain of the email’s “From” address. If neither matches the domain, the DMARC record alone cannot solve the problem.


If you are using MailRoute’s outbound relay, SPF and DKIM are configured appropriately by MailRoute.In this case, simply adding a DMARC record will resolve the issue. Even if you do not use MailRoute, adding a DMARC record is effective, but you must ensure that email delivery services such as Microsoft 365 are correctly configured for SPF or DKIM for your domain. For example, in Microsoft 365, emails are signed using Microsoft’s “onmicrosoft.com” domain until DKIM is enabled, so they do not count toward DMARC authentication.

This incident is said to have been a “mistake” during a spam rule update rather than Microsoft making DMARC a de facto requirement. Nevertheless, publishing a DMARC record is important from a security perspective, regardless of this incident. Domain spoofing is a major technique used in phishing scams and business email compromise, so major email services such as Microsoft, Google, and Yahoo require DMARC from bulk senders. Therefore, declaring that you use DMARC by setting “p=none” not only enables email delivery to Outlook.com but also serves as a first step toward setting “p=reject,” which instructs recipients to reject unauthenticated email. Taking this opportunity to consider configuring a DMARC record will help strengthen email security and ensure reliable sending.