Since 5 November 2026, mail administrators have reported that Outlook.com, Hotmail.com and Live.com are rejecting messages from domains with no DMARC record, including domains sending a handful of messages a day, nowhere near any published threshold.
The bounce looks like this:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)If you manage client domains, you may already have tickets open about it. This article separates what Microsoft has published from what is being observed, because the two do not match, and the difference changes what you should tell a client.
What Microsoft actually published
In April 2025, Microsoft announced authentication requirements for its consumer mail service: outlook.com, hotmail.com and live.com. The requirements are specific:
- Who: domains sending more than 5,000 emails per day to those consumer addresses.
- SPF: must pass for the sending domain.
- DKIM: must pass.
- DMARC: at least
p=none, aligned with SPF or DKIM, preferably both. - In force from: 5 May 2025.
- Rejection code:
550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level.
Microsoft’s own FAQ addresses smaller senders directly, and the wording matters:
“Do I still need to do this if I send fewer than 5,000 emails/day? While enforcement first targets large senders, all senders benefit from these best practices.”
“Enforcement first targets large senders” is a statement about sequencing. It is not a published rule for everyone else, and as of today Microsoft has not announced one.
Why the error code matters
This is the detail most coverage is skipping, and it is the one worth knowing.
The documented rejection for the 5,000-a-day rule is 550 5.7.515. The rejections reported since 5 November carry 550 5.7.1 with the reference AS9031519: a different status code, and a reference that does not appear in Microsoft’s published documentation.
So the honest reading is this. Microsoft’s published policy applies to senders above 5,000 messages a day and rejects with 5.7.515. The behaviour reported since 5 November affects low-volume domains and rejects with a different code that is not documented anywhere.
Microsoft has not confirmed that this is a policy change. It may be an intentional expansion that has not been announced, a tightening of an unrelated filter, or something temporary. Treat it as observed behaviour, not as a published requirement.
That distinction is not pedantry. If you tell a client “Microsoft now requires DMARC” and the behaviour reverts next week, you have spent credibility you will want later. If you tell them “Outlook is currently rejecting mail from domains with no DMARC record, here is the bounce, and here is the fix”, you are accurate either way.
What is reported to resolve it
Publishing a DMARC record. Several reports describe domains that already had valid, passing SPF and DKIM and were still rejected until a DMARC record existed.
That is consistent with the error text, which names all three mechanisms, and it is worth acting on regardless of what Microsoft eventually says. A domain with SPF and DKIM but no DMARC record has published no policy at all: receivers have nothing to apply.
Why this lands hard on MSPs
Two reasons, and the second is the uncomfortable one.
First, your clients’ low-volume domains were never in scope before. The 5,000-a-day threshold excluded almost every small business. A dental practice, an accountancy firm, a small manufacturer: none of them come close. If the reported behaviour holds, the floor has effectively dropped to zero, and every client domain that sends to an Outlook.com, Hotmail or Live address is exposed.
Second, it probably includes your own domain. In our August 2026 survey of 8,724 UK MSP domains, 52.5% were unprotected: no DMARC record at all, or a p=none policy that blocks nothing. A further 43.2% collected no aggregate reports, so they would have no way of seeing a delivery problem develop.
Those figures describe the MSPs’ own company domains, not their clients’ estates. Which means: before you audit a client, check whether your own invoices are reaching Outlook inboxes this week.
What to do
1. Check whether a DMARC record exists for every domain you manage. That is a single DNS lookup per domain, and the DMARC Checker will do it one at a time; if you manage more than a handful, a multi-tenant view is faster.
2. Publish a record where one is missing. The safe starting point:
v=DMARC1; p=none; rua=mailto:[email protected]That satisfies the stated requirement and, more importantly, starts the reports flowing.
3. Do not stop at p=none. This is where the news framing misleads. A p=none record tells receivers to do nothing. It satisfies an authentication check; it does not protect the domain from being spoofed. Publish p=none and close the ticket, and you have fixed a deliverability symptom while leaving the actual exposure untouched.
4. Move to enforcement on the evidence. Read the aggregate reports until every legitimate sender passes with alignment, then move to p=quarantine, hold, then p=reject. Each step is one DNS change and all-or-nothing: RFC 9989 removed the pct tag, so there is no percentage ramp. Our guide to moving from monitoring to enforcement safely sets out the evidence gates.
Microsoft agrees on the destination. Its own FAQ says:
“Does publishing a strict DMARC policy (p=reject) offer better security? Absolutely, once your legitimate sources are aligned, p=reject is the most effective at thwarting domain spoofing. We advise moving gradually (none → quarantine → reject) to avoid unintended mail loss.”
Two details worth knowing
Safe Senders will not rescue you. Microsoft states plainly that the Safe Sender list is not honoured for this enforcement. Telling a client’s contact to allowlist the address does not work.
Microsoft sends aggregate reports but not failure reports. From the same FAQ: “We send RUA to the addresses specified in your DMARC record… We don’t have plans to send RUF.” So a rua= address is what gives you visibility into Outlook delivery. A ruf= address will stay empty as far as Microsoft is concerned.
The short version
Microsoft’s published rule still says 5,000 messages a day and rejects with 5.7.515. What is being reported since 5 November is a different code, at any volume, and is not documented anywhere. Publish DMARC on every domain you manage, not because a requirement obliges you to, but because mail is being rejected today, and because a domain with no policy was never defensible anyway.
Then keep going past p=none, which is the step the headlines leave out.