5.7.23 means Exchange Online evaluated SPF for the envelope sender and the sending IP was not authorized — or the record could not be evaluated at all. The domain to fix is the Return-Path domain of the rejected message, which is not always the visible From domain.
Most common causes
- The actual sending IP is not authorized by the envelope domain’s SPF record
- An include or redirect dependency no longer resolves as expected
- The SPF policy exceeds evaluation limits or returns an error
- The application is using a different envelope-sender domain than the one being reviewed
What to verify next
- Run the SPF Dependency Graph for the envelope-sender domain
- Identify the actual outbound IP from SMTP or header evidence
- Check recursive includes, void lookups and duplicate SPF records
- Retest the exact sending path after correcting authorization
Identify the envelope domain and the IP
SPF is evaluated against the MAIL FROM domain and the connecting IP. The NDR usually names both. If the envelope domain belongs to a sending platform rather than to you, that platform’s SPF is what failed and there is nothing in your zone to change.
If the envelope domain is yours, the IP that connected is not in your SPF record — or the record produced PermError because it exceeds the ten-lookup limit or contains a syntax error, which Microsoft reports under the same code.
The three usual causes
A platform or server that sends for the domain was never added to SPF. A record that grew past ten DNS lookups as vendors were added, so evaluation fails for every sender. Two SPF records published at once, which is an error condition rather than a merge.
Run the SPF Dependency Graph for the envelope domain to see the resolved tree, the lookup count and any void lookups. Then check whether the connecting IP falls inside any authorized mechanism.
- Confirm the envelope domain from the NDR, not the From address.
- PermError from lookup pressure looks identical to an unauthorized IP.
- Multiple SPF records are an error.
Fix without breaking other senders
Add the missing source or remove stale includes to recover lookup budget, then simulate the proposed record before publishing. After propagation, send through the same path and read Authentication-Results for spf=pass on the envelope domain.
Because SPF alignment breaks under forwarding, ensure DKIM is also configured so DMARC has a durable path.
Best diagnostic path
Mail Failure Doctor
Classify the complete rejection and preserve provider-specific diagnostic context.
Open analysis → Live analysisSPF Dependency Graph
Resolve recursive authorization paths, lookup pressure and the effective sender policy.
Open analysis → Live analysisEmail Infrastructure Digital Twin
Map the domain’s public mail infrastructure and provider relationships before remediation.
Open analysis →Known limits
- The check reflects DNS at the time Microsoft evaluated the message; later changes do not explain the historical rejection.
- Receivers may cache SPF results briefly; allow the TTL to elapse before retesting.
Common questions
My SPF checker says everything passes.
It checked your domain; Microsoft checked the envelope sender of the actual message. Read Return-Path in a delivered header.
What if the IP belongs to a platform?
Then the platform’s bounce domain and SPF are involved. Configure a custom bounce domain under your domain, or report the failure to the platform.
Does ~all versus -all matter here?
Exchange Online rejects on hard fail and treats soft fail less severely, but both indicate the source is unauthorized. Fix the authorization.
Why the exact message matters
The same status family can be triggered by different conditions, and providers frequently add diagnostic text that narrows the issue. Use the complete rejection text rather than treating the numeric code as a complete diagnosis.
Provider reference
For the provider-defined meaning and current requirements, review Microsoft Exchange Online NDR reference.