EXPLAINER · MONDAY, NOVEMBER 9, 2026
Outlook.com 550 5.7.23 and 5.7.1 bounces explained: what Microsoft has confirmed, why a DMARC record helps, and how to check every domain you send from
Since about November 5, Outlook.com, Hotmail and Live addresses have refused some mail from ordinary senders with SPF and DMARC errors. We put Microsoft's statements in order, explain the three DNS records the bounce names, and give a tested script that checks every domain you send from.
In one minute
- Since about November 5, mail to Outlook.com, Hotmail.com and Live.com addresses has bounced for some senders with 550 5.7.23 or 550 5.7.1 'Message lacks SPF/DKIM/DMARC Auth Records'. Small, low-volume senders are hit, not only bulk mailers.
- On November 9 at 08:24 UTC a Microsoft moderator called it 'an ongoing Exchange service issue' classified as a service degradation, under investigation. No cause, no fix date, and no Microsoft 365 Service Health post, per users in the thread.
- Many senders say publishing a DMARC record (v=DMARC1; p=none) stopped the bounces. Others with SPF, DKIM and DMARC all passing still bounced, and some say a plain resend works about half the time.
- That mix points to a fault on Microsoft's side layered on a stricter check, but Microsoft has not said so. Treat the DMARC record as a cheap fix that is worth having anyway, not as proof of a new rule.
- Our script checks SPF, DMARC and common DKIM selectors for a list of domains in one pass. Run it over every client domain that sends mail.
What happened
On November 6, 2026 at 09:05 UTC a sender posted on Microsoft Q&A that mail to a hotmail.com address had started bouncing with no change on their side. The bounce read 550 5.7.23, with the text 'Message rejected: Message lacks SPF/DKIM/DMARC Auth Records'. Within a day the thread filled with the same report from IT staff, small businesses and people sending from their own domains.
MailRoute, an email security vendor, wrote on November 6 that its own outbound logs first showed these bounces on November 5, that only some messages from an affected domain were refused, and that most bounced domains had working SPF and many had DKIM, but no DMARC record. The Register reported on November 9 that small senders were hit and that Microsoft had not answered its questions.
The thread also shows the problem easing for some. One user wrote on November 9 at 15:20 UTC that mail to Hotmail, Live and Outlook had been delivering again for the past two to three hours. Microsoft has not confirmed a fix.
What Microsoft has said, in order
- November 6, 10:33 UTC: a Microsoft moderator answered that 550 5.7.23 'typically indicates that the sending IP address is not authorized by the domain's SPF record', and listed SPF, DKIM and DMARC checks for the sender to run. That frames it as the sender's problem.
- November 7: a volunteer moderator wrote that reports were rising and suspected 'an emerging issue on Microsoft's side', with no official confirmation.
- November 9, 08:24 UTC: the same Microsoft moderator wrote that there is 'an ongoing Exchange service issue' for mail to Outlook.com, Hotmail.com and Live.com, with NDRs citing 550 5.7.1 or 550 5.7.23, 'classified as a service degradation', and that engineering is investigating. It names no cause, no ETA, and does not mention DMARC.
Microsoft has published no announcement of a new sender rule in this window. The last one we could find is its 2025 rule for high-volume senders, which is a different error code (below). So the honest reading today is: Microsoft has a delivery fault it is investigating, and senders found a workaround that helps many of them.
The three records the bounce names, in plain words
Email has two sender addresses. The envelope sender (the MAIL FROM, used between servers) and the From address the reader sees. They do not have to match, which is how forged mail works. Three DNS records let a receiver check a message.
- SPF is a TXT record on your domain listing the servers allowed to send mail with your domain as the envelope sender. The receiver checks the connecting server's IP against it.
- DKIM is a signature. Your mail server signs each message with a private key, and publishes the public key in DNS under a selector, such as selector1._domainkey.yourdomain.com in Microsoft 365. The receiver checks the signature and reads which domain signed it (the d= value).
- DMARC is a TXT record at _dmarc.yourdomain.com. It tells receivers what to do when a message fails, and it adds one rule SPF and DKIM lack: alignment. Microsoft's docs put it simply: a message passes DMARC if SPF passes for a domain that matches the From domain, or DKIM passes with a d= that matches the From domain. If both fail, DMARC fails.
Alignment is where good-looking setups break. Microsoft's own table shows a From of user@contoso.com signed with d=contoso.onmicrosoft.com fails DMARC in both relaxed and strict mode. So a Microsoft 365 tenant that never turned on DKIM for its own domain is leaning on SPF alone for DMARC. A newsletter service that uses its own bounce domain and its own DKIM domain passes SPF and DKIM and still fails DMARC for your From address.
When a domain has no DMARC record at all, Microsoft's docs say its filters record dmarc=bestguesspass, meaning Microsoft guesses a pass. That is one plausible way a change could start hurting domains with no record, and it fits the many 'adding DMARC fixed it' reports. It is our hypothesis, not something Microsoft has said.
Three error codes that look alike
- 550 5.7.23: Microsoft's own explanation is that the sending IP is not authorized by the domain's SPF record, or SPF validation failed. In this incident it also hit senders whose headers show spf=pass, which is why people call the message misleading.
- 550 5.7.1 'Message lacks SPF/DKIM/DMARC Auth Records': the text in this week's bounces. MailRoute says a code in brackets, such as AS9031519, was added after the first day. The same 5.7.1 code is also what Microsoft returns when it rejects mail under a sender's own p=reject policy, so the code alone tells you little. Read the text.
- 550 5.7.515 'Access denied, sending domain does not meet the required authentication level': the 2025 rule. Microsoft's support page says it applies when you send 5,000 or more messages to Microsoft consumer addresses using the same From domain, and asks for SPF and DKIM to pass plus a DMARC record (its example is v=DMARC1; p=none) that aligns. If you see 5.7.515, you hit the bulk rule, not this incident.
Check every domain you send from
An MSP rarely has one domain. This script reads a file with one domain per line and prints the SPF record, the DMARC record and the first common DKIM selector that holds a real key. It only uses dig, so it runs on macOS and Linux. We ran it on November 9 against four domains: two with all three records, one with a DMARC record and no key on the common selectors, and example.com, whose selector1 record has an empty key and is correctly reported as no.
#!/bin/sh
# Usage: sh mailauth-check.sh domains.txt (one domain per line)
while read -r d; do
[ -z "$d" ] && continue
spf=$(dig +short TXT "$d" | tr -d '"' | grep -i '^v=spf1' | head -1)
dmarc=$(dig +short TXT "_dmarc.$d" | tr -d '"' | grep -i '^v=DMARC1' | head -1)
dkim=no
for s in selector1 selector2 google default k1; do
if dig +short TXT "$s._domainkey.$d" | tr -d "\" " | grep -q "p=[A-Za-z0-9+]"; then dkim="$s"; break; fi
done
printf '%s\n SPF: %s\n DMARC: %s\n DKIM: %s\n' "$d" "${spf:-MISSING}" "${dmarc:-MISSING}" "$dkim"
done < "$1"printf 'client-one.com\nclient-two.org\n' > domains.txt sh mailauth-check.sh domains.txt
Read the output like this. DMARC MISSING on a domain that sends to consumers is the first fix: publish v=DMARC1; p=none at _dmarc, which changes nothing for other receivers and is what Microsoft's own rollout guide starts with. DKIM no means none of selector1, selector2, google, default or k1 hold a key. Your provider may use another selector name, so check its docs before you assume DKIM is off. For Microsoft 365, turn on DKIM for each custom domain so the signature aligns with your From address.
If a domain passes all three and still bounces, the fault is not in your DNS. Collect fresh Network Message IDs and the bounce text, and open a Microsoft support request, which is what the Microsoft moderator asked for.
Who is affected
| Case | Status |
|---|---|
| Senders with no DMARC record, mailing Outlook.com, Hotmail.com, Live.com or MSN.com addresses | Most reports. Many say publishing v=DMARC1; p=none stopped the bounces. |
| Senders with SPF, DKIM and DMARC all passing | Some still bounced, and a resend sometimes worked. Points to the service fault Microsoft is investigating. |
| Mail to Microsoft 365 business tenants | Not reported in the threads we read. The reports are about Microsoft's consumer addresses. |
| Senders of 5,000 or more messages a day to Microsoft consumer addresses | Already under the 2025 rule, which bounces with 550 5.7.515 when SPF, DKIM and DMARC are not in place. |
What to do
- Run the script over every domain you or your clients send mail from.
- Publish v=DMARC1; p=none at _dmarc for any sending domain that has no DMARC record. Add a rua= address if you want reports.
- In Microsoft 365, turn on DKIM signing for each custom domain, so DMARC does not rest on SPF alone.
- If a fully configured domain still bounces, open a Microsoft support request with fresh Network Message IDs and the bounce text.
- Over the next weeks, read the DMARC reports and move toward p=quarantine, then p=reject, as Microsoft's rollout guide describes.
What is still unknown
- What changed on Microsoft's side. Microsoft calls it a service degradation and has named no cause.
- Whether a stricter check on domains with no DMARC record is intended and will stay. Microsoft has announced no such rule.
- How many senders or messages were affected. No one has published a count.
- Whether the problem is over. One user reported mail flowing again on November 9; Microsoft has not confirmed a fix.
- Why some senders with SPF, DKIM and DMARC all passing still bounced. Those reports come from users in the thread, not from Microsoft.
Sources
- Microsoft Q&A: SPF Validation Error, with a Microsoft moderator's service advisory (November 9, 2026) — the original report
- The Register: Outlook.com bounces legit emails (November 9, 2026)
- MailRoute: Outlook rejecting email without DMARC (November 6, 2026)
- Microsoft Learn: set up DMARC to validate email in Microsoft 365
- Microsoft Support: fix NDR error 550 5.7.515 in Outlook.com
Today's full edition: AI News Report · every headline, every morning.