On November 7, 2026, Neowin reported Sender Policy Framework (SPF) validation errors blocking Outlook email, even when senders said their DNS records were correct. In the Microsoft Q&A threads, the bounces are mostly messages sent to Outlook.com and Hotmail addresses, rejected with “550 5.7.23” and sometimes followed by “550 5.7.1” text, reported by senders and Microsoft 365 admins.
If one of your messages bounced, save the full bounce notice (NDR) first: its diagnostic text tells you which domain and which check failed. Microsoft hasn’t publicly confirmed a service-wide defect as of this writing.
What Happened: Outlook SPF Validation Errors Bouncing Mail
Neowin’s report describes intermittent rejections, with some cases involving outgoing mail and others involving incoming mail.
Microsoft Q&A threads confirm cases tied to Microsoft 365 domains; additional reports mention Google Workspace and Zoho, though those haven’t been independently verified. Many affected senders said their SPF, DKIM, and DMARC records looked valid.
Microsoft Q&A threads from the same days show the same pattern. One is titled “SPF validation error”. Another reads “Message was rejected because of Sender Policy Framework”. A third covers incoming mail blocked for missing SPF/DKIM/DMARC.
What the 550 5.7.1 and 550 5.7.23 codes mean
These are SMTP rejection codes, but they don’t mean the same thing. Microsoft Q&A identifies 550 5.7.23 specifically as an SPF validation failure: the recipient system checked the sender’s SPF record and rejected the message before delivery.
550 5.7.1 is a broader policy rejection that can point to missing SPF, DKIM, or DMARC authentication, or another policy violation. The exact diagnostic text in the NDR determines which check actually failed, so don’t assume both codes mean “SPF failed.”
SPF (Sender Policy Framework) is a DNS TXT record that lists which servers may send mail for a domain. When that check fails, the message bounces back to the sender.
What’s still unverified
As of this writing, Microsoft hasn’t posted an incident ID, a status-page entry, or a root-cause statement in the sources we reviewed. It also hasn’t given a start time or a fix date in those sources.
The available evidence is community reports, a Neowin write-up and a handful of anecdotal fixes. It doesn’t establish a verified service-wide event, its scale or regions, or any change to how Outlook.com evaluates SPF; the suggestion that Microsoft changed an enforcement rule is speculation from Q&A participants, not a confirmed finding.
Who this affects
- Personal Outlook.com users: You can’t edit Outlook.com’s SPF/DKIM/DMARC records, and you can’t edit the sender’s records either.
- Small businesses on a custom domain: If your domain sends through Microsoft 365, Google Workspace, or Zoho, its DNS records are what this check reads. Whoever manages that DNS (you, your registrar, a hosting company or an MSP) has to make any change, and the domain that matters is the envelope-sender (Return-Path) domain shown in the NDR, which isn’t always the visible From address.
- Office IT admins: You can trace the specific rejected message and audit the records.
Safe Senders lists and junk-mail settings won’t help. Microsoft Q&A guidance notes those settings only apply after a message is accepted. An SMTP rejection happens before that point.
How It Stacks Up
There’s no evidence that switching providers would resolve this issue.
Reports mention Microsoft 365, Google Workspace, and Zoho-hosted domains, but the available sources don’t offer a verified provider-by-provider comparison.
| Sending setup | Reported as affected? | Does switching help? | Source |
|---|---|---|---|
| Microsoft 365 custom domain | Yes | N/A | Neowin, Nov 7, 2026 |
| Google Workspace / Gmail | Reported, unverified | Not established | Neowin, Nov 7, 2026 |
| Zoho Mail | Reported, unverified | Not established | Neowin, Nov 7, 2026 |
| SPF record checker tools | N/A | Confirms your own config only | Microsoft Learn SPF setup guide |
Rolling back Outlook or Office won’t help either. No source ties these rejections to a Windows build or an Office client version, and the check runs on Microsoft’s mail servers.
Microsoft’s SPF setup documentation lists the common self-inflicted causes:
- More than one
v=spf1TXT record on the same domain. - Missing
include:spf.protection.outlook.comfor Microsoft 365 custom domains. - An SPF record that needs more than 10 DNS lookups, which fails permanently.
- Missing or misaligned DKIM or DMARC. This doesn’t make a valid SPF record fail on its own, but if DMARC enforcement is set to
p=rejectorp=quarantineand the message fails DMARC alignment, Microsoft’s mail servers can still reject it even when SPF itself passed.
The Reaction
On X, posts summarized in our gathered search data came mostly from news and tech accounts such as @NeowinFeed and @windowsforum. Some of them claim Microsoft appears to be rejecting mail from domains with no DMARC record. The most common advice is to add a basic DMARC TXT record with p=none. One post shared a single case where adding a missing DMARC record fixed Outlook delivery right away.
That theory fits the “valid SPF, still bounced” pattern, but nobody has confirmed it. Microsoft hasn’t, and one success story doesn’t prove a rule change. The upside is that a p=none DMARC record only monitors mail and doesn’t tell receivers to reject anything. It’s a cheap step for an admin, but it isn’t a guaranteed fix.
Our Take
Verdict: Work around it. There’s nothing to install or pause, and the worry level is moderate. This is a delivery-reliability problem.
Nothing in the sources we reviewed points to a breach or account compromise, though we don’t have enough security telemetry to rule that out entirely.
If you’re a personal Outlook.com user, forward the full bounce notice to the sender. Their email admin is the only person who can fix the records.
If you run the domain, work through these checks in order:
- Save the complete non-delivery report (NDR) you received, including the full “Diagnostic information for administrators” section. That’s the primary evidence for why the recipient system rejected the message: it includes the envelope-sender domain, timestamp, sending IP, and the exact SMTP error text.
- From the NDR, identify the envelope-sender (Return-Path) domain and the sending IP. That’s the domain whose SPF record the recipient checked.
- Run
nslookup -type=txtagainst that domain and confirm there’s exactly onev=spf1record. - Confirm the sending IP or service appears in that record, and keep the lookup count under 10.
- If you’re troubleshooting outbound mail from your own Microsoft 365 tenant, open Exchange admin center > Mail flow > Message trace, then search by sender, recipient, and date for the message in question. Message trace shows how your tenant processed the outbound message, but it may not surface the recipient’s full authentication failure reason; for that, rely on the NDR’s diagnostic text.
- Separately, check that DKIM is enabled and that a DMARC record exists at
_dmarcon your domain. That’s good practice, but it isn’t a confirmed fix for these 5.7.23 SPF rejections.
A public SPF checker may not reproduce the recipient’s evaluation, because the result depends on the actual envelope-sender domain, sending IP, DNS responses and any forwarding along the way. But if the NDR shows SPF failing for a domain and IP your record clearly authorizes, that’s reasonable evidence to include in a support request; it isn’t proof of a Microsoft defect on its own. Message trace needs an Exchange Online organization and the right admin role, so a free Outlook.com account can’t use it.
Wrapping Up
Your domain’s own DNS is the most likely place to find something fixable. Duplicate SPF records, a missing sending service and too many DNS lookups are well-documented SPF faults, so audit those before you blame Microsoft. Some admins report that adding a DMARC record helped, but that’s anecdotal.
If your records are clean and bounces still come and go, treat it as a possible Microsoft-side issue and escalate with your NDR and trace results. After any DNS change, allow for the old record’s TTL to expire before testing. Then send a few test messages to an Outlook.com address and check the delivered message’s authentication results header (or any new NDR) for the SPF result; a single successful send doesn’t by itself show which check passed.