I read SMTP error codes before I read the sentence underneath them, because the sentence is written by whoever is rejecting you and it is often a guess. Last week Outlook.com gave the rest of us a reminder of why that habit exists: since November 5, its consumer mail servers have been rejecting mail from domains that publish no DMARC record, with a bounce that says the authentication records are missing. On November 9, a Microsoft moderator in the company’s own support forum said the whole thing is an ongoing Exchange service issue, classified as a service degradation.
Those two statements cannot both be literally true. And the space between them is where a lot of engineering time is currently being burned.
📮 What the servers are actually doing
The bounce looks like this, and the trailing code differs per message:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)On November 5, the first day, the same text arrived without the (AS9031519) suffix. Many senders see it wrapped inside an SPF-shaped NDR instead, with 550 5.7.23 and the generic “SPF validation error” body, and the 5.7.1 line buried in the diagnostic details.
The rejecting hosts sit behind *.olc.protection.outlook.com, where olc is Outlook Consumer. That matches the reports: outlook.com, hotmail.com, live.com, msn.com and their country variants are affected, while business mailboxes on Exchange Online with custom domains have been delivering normally. MailRoute recorded the first bounces in its own outbound logs on November 5, and Neil Jenkins, Fastmail’s chief product officer, reported customers with their own domains hitting the same thing on the mailop list.
The published rule it resembles is not this one. Microsoft announced stricter Outlook.com sender requirements on April 2, 2025, and since May 5, 2025 domains sending more than 5,000 messages a day have needed SPF and DKIM passing, a DMARC record at p=none or stronger, and aligned SPF or DKIM. That rule has its own code, 550 5.7.515 Access denied, and it lists the actual authentication results. The November 2026 rejection is 5.7.1, names no threshold, and tells you nothing about what passed or failed. The published Outlook.com postmaster requirements still list only the 5,000-per-day threshold.
It is also intermittent. Some messages from an affected domain land, others bounce, and a resend minutes later can go through. One admin in the Microsoft thread put the resend success rate at roughly 50/50. Another described a Zoho-hosted sender rejected at 15:50 and delivered at 16:09.
🧾 The code names a check that never ran
Here is the part that makes this more than an outage story. DMARC does not work the way the bounce text implies.
RFC 7489 is explicit in section 6.6.2. The receiver extracts the domain from the 5322.From header, then queries DNS for a DMARC policy record, and then: “Continue if one is found, or terminate DMARC evaluation otherwise.” No record means there is nothing to evaluate, so there is no DMARC result to fail. A domain with no _dmarc TXT record cannot produce dmarc=fail, because the mechanism never starts.
Which means Message lacks SPF/DKIM/DMARC Auth Records is not reporting an authentication failure. It is reporting that a DNS lookup for a policy object came back empty, and then describing that as three failed checks. On a domain where SPF and DKIM are passing, that sentence is simply false. EasyDMARC tested it on November 8 with a domain on Zoho Mail, SPF passing and aligned, DKIM passing and aligned, no DMARC record, and got the rejection from a live.com address on the first try. SPF and DKIM were fine. The message said they were missing.
The identifier AS9031519 is not documented anywhere by Microsoft. The 5.7.515 support article does not mention it, and EasyDMARC’s November 8 check of the Outlook.com sender pages and the known-issues list came back empty. So the only machine-readable part of the bounce is an undocumented code, and the human-readable part asserts something the server did not establish.
There is a fair counter-argument, and I want to state it before dismissing the people making it. A domain without DMARC is a domain whose owner has not declared an authentication policy, and every mailbox provider is drifting toward treating that absence as a signal. Microsoft has been publishing that direction for eighteen months. If you are sending transactional mail in 2026 and you have never published _dmarc, you have a gap, and this incident found it. What the counter-argument does not explain is the reports in the same Microsoft thread from domains with SPF, DKIM and DMARC all in place for years, whose headers show spf=pass, dkim=pass and dmarc=pass, still getting the same bounce now and then. A missing record cannot explain those. Microsoft’s moderators have not offered a mechanism that covers both groups.
⏱️ A transient fault delivered as a permanent error
The intermittency is not a detail. It is what turns a three-day filter bug into lost mail.
550 is a permanent failure. The sending MTA is not supposed to retry it, and most queues do not. So a message that would have gone through fine four minutes later is dropped at the first attempt, logged as a hard bounce, and in a well-behaved system it goes to a suppression list. If your password reset, invoice, invitation or appointment confirmation went to a hotmail.com address last week, there is a decent chance the user simply never got it, and your metrics call that a deliberate rejection rather than a temporary glitch.
This is also why testing is so misleading here. A single successful send tells you almost nothing, because success and failure are not correlated with anything you control.
Your alerting probably groups 5.7.1 as a sender authentication problem, which is a configuration category, so the ticket goes to whoever owns DNS. That person checks SPF, checks DKIM, both correct, and loses an afternoon on alignment edge cases for a recipient-side fault.
🩹 Why p=none appears to fix it, and why that will get misfiled
Publishing a DMARC record does stop the bounces for a lot of domains. Multiple admins in the Microsoft thread reported delivery resuming once the record went live, and hosts are telling customers the same thing. The minimum is a TXT record at _dmarc with v=DMARC1; p=none.
I would publish it. I would also be careful about what I conclude afterward.
If the record’s presence is what changes the code path, then the record is a workaround keyed to a bug, not a fix for a misconfiguration. The two cases look identical from the outside: you add a record, bounces stop. Only one of them means your setup was broken. And EasyDMARC makes the sharper point, that a bare p=none with no rua= is the empty version of the statement. You have satisfied the lookup and you receive no aggregate reports, so you learn nothing about who else sends as your domain, which sources fail alignment, or whether anyone is spoofing you.
There is one diagnostic upside, though. If you publish a valid record with reporting enabled and the AS9031519 bounces continue, you now have evidence that your side is fine and the reject is happening above you. That is worth having in a support case before anyone proposes paying a consultant.
🛠️ What I would do this week
Check every domain you send from, not just the main one. dig +short TXT _dmarc.example.com and look for a line starting with v=DMARC1. Do it for marketing subdomains, the helpdesk, the applicant tracking system, and whatever the finance team set up in 2023 and forgot.
Then check alignment rather than presence. A record that exists but never passes is the same as no record with extra steps. The common trap is Microsoft 365 signing outbound mail with onmicrosoft.com until you explicitly enable DKIM for your custom domain, which passes DKIM and aligns with nothing.
Publish p=none with a real rua=mailto: address. Move to quarantine and then reject once the reports are clean and you know every sender. That path takes weeks, so start before the next incident.
On the receiving side, alert per recipient domain. Aggregate bounce rate hides this completely, because Outlook consumer addresses are a small share of most lists. A rule like “any 5xx mentioning AS9031519, or any rejection from *.olc.protection.outlook.com, grouped by destination domain, page at more than N in an hour” catches the next version of this in minutes instead of days.
And keep the message around when you see a 5xx from a consumer provider during a known incident. Manual requeue after the provider fixes it is cheap. Recovering a suppressed address whose owner never received the reset link is not.
🧠 Final Thoughts
The missing DNS record is the small part of this story. The expensive part is that a bounce asserted a fact the receiving server never checked, and every diagnostic path in our industry starts from that sentence: the NDR says authentication, so the on-call engineer debugs authentication. Microsoft’s own moderator now says it is a service degradation, and the bounce still says the same thing it said on November 5.
Error text is an interface, and interfaces that lie cost more than interfaces that are terse. If I were writing the response, I would rather see 550 5.7.1 sender policy lookup failed than a sentence naming three protocols the server never evaluated. Until then, the useful habit is the boring one: believe the code, verify the claim, and never trust a single test message to a Hotmail address.
Thanks for reading.