Outlook.com and Hotmail Reject Emails With 550 Errors: What to Check in SPF, DKIM and DMARC

Here's what has been reported, what the error codes do and don't tell you, and what administrators can check right now.

What users are reporting​

Neowin rounded up reports from Microsoft's own Q&A forums and Reddit. The most common bounce reads "550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records." Some senders get 550 5.7.23 instead, which points specifically to an SPF validation failure. Reports came from several different businesses, which suggests this isn't one company's broken DNS zone.

The Microsoft Q&A threads show the range of people affected:

• A small business owner who uses a free Outlook.com address wrote that several established customers who previously emailed them successfully are now receiving this error: 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records.
• Another thread, posted November 6, reads simply that incoming emails are getting blocked with the same 5.7.1 rejection.
• A Microsoft 365 business user described sudden failures when sending to Outlook.com and Hotmail addresses, with 550 5.7.23 and the reference code AS9031519.
• A custom-domain Outlook.com user said messages to other users on the same domain were failing with the "lacks SPF/DKIM/DMARC Auth Records" text.
• One Q&A user who emailed 21 different Hotmail addresses had every message bounce.

The failures are also intermittent, which is odd. According to Neowin, one sender's mail through Zoho was rejected and then delivered when resent about 19 minutes later. The headers on the delivered copy showed SPF, DKIM and Microsoft's composite authentication (compauth) all passing. Another administrator said the same messages reached Gmail but bounced at Hotmail. Senders on Google and Zoho, not only Microsoft 365, also reported rejections when mailing personal Outlook.com accounts.

Section summary: The symptom is a hard rejection by Microsoft's consumer mail service, not mail landing in Junk. It hits senders on several platforms and doesn't happen consistently.

The timeline and the consumer-mail angle​

Email security vendor MailRoute has been tracking the rejections. It reports that the servers behind outlook.com, hotmail.com, live.com and msn.com addresses (*.olc.protection.outlook.com) started returning this rejection on November 5, 2026. MailRoute also saw the wording change: the bounce later carried an (AS9031519) suffix, and on the first day, the same rejection came back without the (AS9031519) code.

This is a consumer Outlook.com issue. The receiving side is Microsoft's consumer mail infrastructure, not your own tenant's Exchange Online Protection. That explains why Microsoft 365 admins see the 5.7.23 variant on outbound mail, while personal Outlook.com users see their inbound mail fail. It's the same rejection seen from opposite ends.

The emerging theory: missing DMARC records​

Neowin reported that one user fixed their bounces by publishing a DMARC record. The domain already had valid SPF and DKIM but no DMARC, and once the TXT record was added, Hotmail accepted the mail again. Neowin also points out that Microsoft 365 does not automatically create or publish DMARC records for custom domains, so many tenants never had one.

Third-party mail vendors have reached the same conclusion. MailRoute's analysis says the domains it has seen bounced mostly had working SPF, and many had DKIM too. What they were missing was the DMARC record that ties the two to the From address. Its explanation is that without a DMARC record, those passes have no policy to count toward, and Outlook.com now treats the message as unauthenticated.

That would be a real policy change. MailRoute notes that since May 2025, domains that send more than 5,000 messages a day to Outlook.com have had to pass SPF, DKIM and DMARC, or get 550 5.7.515 Access denied. Mail diagnostics site mxio says Microsoft has published no newer rule, and gives its practical reading: Microsoft now expects every domain that sends to Outlook.com to publish DMARC, not only bulk senders.

The new bounce is also harder to diagnose than the old one. MailRoute observes that a 5.7.515 bounce lists the SPF, DKIM and DMARC results. This one only says records are missing.

Why this doesn't settle the matter​

Treat the DMARC theory as a strong lead, not a confirmed cause:

• These are vendor observations, not Microsoft statements. MailRoute and mxio describe the mail they've examined. Microsoft hasn't published a rule change.
• It doesn't explain every report. Neowin found administrators who say all three records were already in place and still got rejections.
• It doesn't explain the intermittency. If a missing record were the only trigger, the same message wouldn't bounce once and get delivered 19 minutes later. A policy rollout across server pools, a backend fault, or both happening at once could explain it, but nobody outside Microsoft knows yet.

Whether Microsoft quietly started enforcing a stricter policy or has a filtering bug, admins have to work through the same checklist either way.

What the error codes actually mean​

Microsoft's guide to troubleshooting email authentication in Microsoft 365 is a good reference here:

Microsoft's article on the 5.7.23 error adds a detail that's easy to miss. If Microsoft 365 flags an outbound message as spam, it's routed through the High Risk Delivery Pool, and Microsoft says those messages won't pass SPF checks, so the destination will reject them. A Microsoft 365 sender seeing 5.7.23 should check outbound spam detection as well as DNS. If you conclude the spam verdict was wrong, Microsoft says to contact support.

Step-by-step: what to check today​

1. Confirm all three records exist. On Windows, nslookup -type=TXT yourdomain.com returns your SPF record. The DMARC record is at _dmarc.yourdomain.com. MailRoute suggests the Linux/macOS equivalent, dig +short TXT example.com. Microsoft's Remote Connectivity Analyzer can test SPF, DKIM and DMARC as well.

2. If DMARC is missing, publish a monitoring policy. A typical starting record is a TXT entry at _dmarc reading v=DMARC1; p=none; rua=mailto:[email][email protected][/email]. As MailRoute puts it, p=none is the safe starting point. It declares that your domain uses DMARC and asks receivers to send you reports, but it tells them to take no action on failures.

3. Check alignment, not just whether the records exist. DMARC passes only when SPF or DKIM passes for the domain in your From address. If neither lines up, a DMARC record alone won't help. In Microsoft 365, that means enabling DKIM signing for your custom domain instead of relying on the default onmicrosoft.com signature.

4. Clean up SPF. Microsoft's guidance lists the usual problems:

• Only one SPF TXT record is allowed per domain. Two records cause a permerror.
• Each include, a, mx, ptr and redirect mechanism counts toward the 10-lookup limit.
• Third-party senders such as CRMs, newsletter tools and scanners need their own include entries.
• Microsoft recommends an SPF TTL of at least 3,600 seconds to avoid DNS timeouts.

5. Read the headers of successful and failed messages. Look at spf=, dkim=, dmarc= and compauth= in the Authentication-Results header. If you see dmarc=bestguesspass, Microsoft 365 guessed at a pass because you have no DMARC record, which is exactly the gap that may now be getting you rejected.

6. Look at forwarders and gateways. Forwarding breaks SPF by design, and gateways that add disclaimers break DKIM. Microsoft's documented fix is trusted ARC sealers or Enhanced Filtering for Connectors.

7. Don't make it worse. Don't add a second SPF record, and don't rewrite DNS in a panic over one bounce.

Section summary: Publishing a p=none DMARC record and confirming DKIM alignment are the most promising fixes so far, and they're low-risk changes that most domains should have made already.

If you're an Outlook.com user, not an admin​

If people can't email your personal @outlook.com address, the fix isn't in your settings. One Q&A answer explains that you cannot add SPF, DKIM, or DMARC records to a personal @outlook.com address; the rejected sender or its email provider must authenticate the domain from which the incoming message was sent. The server name in the bounce identifies the Microsoft server that did the rejecting, and it does not mean your @outlook.com address lacks records. Send the bounce to the person whose mail failed and ask them to pass it to whoever runs their domain.

Escalation and status​

Microsoft hasn't acknowledged the problem or published an incident notice or root cause. Senders who can show their mail passed authentication should escalate with evidence. One Q&A response advises having the sender submit the full non-delivery report, timestamp, sending IP, From domain, and message headers through Outlook.com Sender Support.

The bigger picture​

Mailbox providers have been pushing toward mandatory authentication for years. Google and Yahoo tightened their sender rules in 2024, and Microsoft followed in 2025 with its bulk-sender rules for Outlook.com. If MailRoute and mxio are right, Microsoft has now applied a DMARC requirement to everyone who sends to consumer Outlook.com, without announcing it.

Requiring DMARC is reasonable. It's one of the cheapest defences against spoofing. The bad part is how it was done: no announcement, a bounce message that doesn't say what failed, and inconsistent rejections that leave admins with correct records unsure whether to blame their DNS or Microsoft. If you don't have a DMARC record yet, add one now.