550 5.7.23 high
550 5.7.23 SPF Validation Failed (Exchange Online NDR)
The receiving server rejected the message because the sending domain's SPF check returned fail; the sender IP isn't authorized.
What you see
550 5.7.23 The message wasn't delivered because the sender's domain doesn't pass SPF. 550 5.7.23 SPF validation failed. Remote Server returned '550 5.7.23 ...'
What’s actually happening
Mail to an Exchange Online / Microsoft 365 recipient bounces with 550 5.7.23 and a non-delivery report. The receiving side did an SPF lookup on your domain and the IP that connected wasn't in your record, so it returned fail and the inbound message got dropped. It commonly surfaces after mail passes through a forwarder or relay that changes the connecting IP without updating SPF. The bounce is the recipient's server reporting the sender failed SPF.
Common causes
- The sending IP isn't listed in the domain's SPF record (a missing include, ip4/ip6, or a/mx mechanism)
- A forwarding service or relay rewrote the path so the connecting IP no longer matches SPF, breaking the chain
- The SPF record ends with -all (hard fail) while a legitimate sender is still missing from it
- More than 10 DNS lookups in the SPF record, causing a permerror that some receivers treat as fail
- A new sending platform (CRM, ESP, ticketing system) was added but its include: was never added to SPF
How to fix it
- Read the bounce for the exact sending IPThe NDR names the IP that failed SPF. Confirm whether it's actually yours (your mail server, ESP, or relay) before touching DNS — fixing the wrong record won't clear the bounce.
- Add the sender to your SPF recordEdit the domain's TXT SPF record to authorize the source: add the provider's include: (e.g. include:_spf.google.com), or the specific ip4:/ip6: block. Keep exactly one SPF TXT record per domain — multiple records are invalid.
- Stay under the 10-lookup limitCount DNS lookups across all include/a/mx/redirect mechanisms. Over 10 causes a permerror. Flatten nested includes or drop unused providers to get back under the cap.
- Fix broken forwarding with SRSIf a forwarder breaks SPF, enable Sender Rewriting Scheme (SRS) on it so the envelope sender aligns with an authorized domain, or relay outbound through an authenticated path that passes SPF.
- Verify, then add DKIM and DMARCAfter updating SPF, recheck with an SPF validator (MXToolbox, dig txt) and resend. Add DKIM signing and a DMARC policy so a single mechanism failure doesn't sink delivery.
Stop it recurring
Keep one SPF record listing every legitimate sender, stay under 10 DNS lookups, and re-check it whenever you add a sending platform.
Related errors