Since November 5, 2026, Outlook.com, Hotmail, Live and MSN addresses have been rejecting some mail from domains that publish no DMARC record, according to email security company MailRoute. Microsoft has not confirmed this. If you send email to customers, patients or job applicants who use personal Microsoft addresses, some of those messages may never arrive.
The likely fix is one DNS record, and you can check whether your domain is exposed in a few seconds.
The bounce message to look for
MailRoute reports that rejected messages come back with this text:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
On the first day, per MailRoute, the same bounce arrived without the (AS9031519) code. MailRoute says it first saw these bounces in its own outbound logs on November 5, and that other admins reported them the same day.
Two details make this easy to miss:
- It's intermittent. Only some messages bounce, and a resend may go through. One delivered message does not prove your domain is safe.
- SPF and DKIM alone may not be enough. MailRoute says most affected domains it saw had working SPF, and many had DKIM too. What they lacked was DMARC.
This is not limited to Microsoft 365 senders. WindowsForum reports that senders on Google and Zoho also see rejections.
What is confirmed and what isn't
Nothing here comes from Microsoft. As of November 6, MailRoute said Microsoft had published no postmaster notice, blog post or service-health entry. WindowsForum also says Microsoft has not confirmed a policy change or a cause.
The DMARC explanation comes from vendors reading their bounce logs. MailRoute sells email security products, and much of the other coverage, including WindowsForum's, leans on MailRoute's analysis rather than independent evidence.
The picture may also be messier than "no DMARC, no delivery."
How to check if your domain has DMARC
On macOS or Linux, run this in a terminal, replacing example.com with the domain in your From address:
dig +short TXT _dmarc.example.com
If you get no output, you have no DMARC record, per MailRoute. If you get a line starting with v=DMARC1, a record exists.
Windows doesn't usually include dig, but nslookup does the same lookup. Open Command Prompt or PowerShell and run:
nslookup -type=TXT _dmarc.example.com
If the reply contains a line starting with v=DMARC1, a record exists. If it doesn't, you have no DMARC record.
How to add a minimal DMARC record
In your DNS provider's dashboard:
- Create a new TXT record.
- Set the name (or host) to
_dmarc. - Set the value to
v=DMARC1; p=none. - Save, then rerun the
digornslookupcommand to confirm it shows up.
p=none asks receivers to take no action on failures and to send reports. MailRoute says it does not change how other receivers treat your mail, which makes it a low-risk first step even if Microsoft's actual cause turns out to be broader.
One catch: DMARC only passes if SPF or DKIM passes for the domain in your From address. This is called alignment. If you use Microsoft 365, MailRoute notes that it signs mail with its own onmicrosoft.com domain until you turn on DKIM for your own domain, and that signature doesn't count toward DMARC. So enable DKIM for your domain in Microsoft 365 as well.
The sources behind this article don't spell out the Microsoft 365 admin menus or the DKIM DNS records to create, so this article can't give verified steps for that part. Use Microsoft's own DKIM setup instructions for your tenant, and copy the DNS records it generates for your domain exactly rather than building them by hand.
How this differs from Microsoft's bulk-sender rule
There is an older, separate requirement. MailRoute says that since May 2025, domains sending more than 5,000 messages a day to Outlook.com must pass SPF, DKIM and DMARC, or get 550 5.7.515 Access denied. The new bounces, if MailRoute is right, reach small senders well below that volume and use a different error code.
If you're the one not receiving mail
Owners of @outlook.com or @hotmail.com addresses can't fix this from their side. The Microsoft Learn reply points out that Microsoft manages outlook.com's own records, and the change has to be made by the sending domain. The most useful thing you can do is tell the sender to add a DMARC record.
What to watch next
Watch for any Microsoft postmaster notice or service-health entry about these 5.7.1 bounces. That statement would settle whether missing DMARC is the cause, a contributing factor, or a sign of a wider SPF problem.
