550 5.7.23: SPF validation failed
The receiver checked your domain's SPF record and the sending server wasn't authorized, so the message was rejected under its policy.
What 550 5.7.23 means
RFC 7372 registered X.7.23, "SPF validation failed": the message completed an SPF check that produced a "fail" result, contrary to local policy. It replaces the generic 5.7.1 for this case, as described in section 8.4 of RFC 7208 (SPF). A related code, X.7.24, "SPF validation error", is used when evaluating SPF produced an error rather than a clean result.
An SPF fail means the IP address that delivered the message isn't covered by the SPF record of the envelope sender's domain, and the record ends in a hard fail ("-all"). The usual reason is a new sending service, a website, CRM or scanner, that was never added to the record.
Microsoft documents 550 5.7.23 too. It says this bounce most likely means an SPF configuration problem, and tells admins to verify the domain's SPF record, include any on-premises IPs that send for the domain, and check whether the message went out through Microsoft's High Risk Delivery Pool, since messages sent that way won't pass SPF.
Likely causes
- A service that sends as your domain isn't listed in your SPF record.
- The SPF record has a typo or a broken include.
- The message was forwarded, so it arrived from a server your SPF record doesn't list.
- An outbound message was routed through a high-risk sending pool after being flagged as spam.
How to fix it
If you sent the message
- Check your SPF record and confirm every service that sends as your domain is included.
- Keep the record under SPF's 10 DNS-lookup limit.
- Set up DKIM as well, so forwarded mail can still pass DMARC.
If you're the recipient or their admin
- If mail forwarded into your domain fails SPF, accept it through a trusted forwarder or ARC instead of loosening SPF checks.
Frequently asked questions
How do I find which server failed SPF?
The bounce or the recipient's Authentication-Results header shows the connecting IP address. Compare it with the services listed in your SPF record; an SPF checker shows the full list of addresses the record allows.
Should I change -all to ~all to stop 5.7.23 bounces?
That hides the problem rather than fixing it, and some receivers treat softfail as suspicious anyway. Add the missing sender to your SPF record and set up DKIM instead.
Sources
- RFC 7372: Email Authentication Status Codes
- IANA: SMTP Enhanced Status Codes registry
- Fix NDR error "550 5.7.23" in Exchange Online (Microsoft Learn)
Provider messages are quoted as the provider publishes them. Servers can change their wording, so the bounce you received may differ slightly.
Related codes
Related guides
SPF record syntax and examples
SPF record syntax explained: mechanisms, qualifiers and modifiers, with copy-ready examples for Microsoft 365, Google Workspace, subdomains and parked domains.
9 min read SPF, DKIM & DMARCHow to fix SPF PermError: too many DNS lookups
Why SPF breaks at 10 DNS lookups, how to count them, and step-by-step fixes for Microsoft 365 and Google Workspace domains with many senders.
8 min read SPF, DKIM & DMARCWhy email forwarding breaks SPF and DMARC, and how ARC helps
Why forwarding and mailing lists break SPF and sometimes DKIM, how that fails DMARC, and how SRS, ARC and trusted ARC sealers in Microsoft 365 help fix it.
9 min read SPF, DKIM & DMARCWhy does DMARC fail? Causes and fixes for dmarc=fail
Troubleshoot dmarc=fail: alignment vs pass, third-party senders, forwarding, subdomains, DKIM d= and SPF MAIL FROM mismatches, with a causes-to-fixes table.
9 min read