Why does Gmail accept the same message that Microsoft rejects with 5.7.23?

Gmail accepts mail that passes either SPF or DKIM and uses the DMARC policy to decide the rest. A tenant producing 5.7.23 has a rule that rejects on SPF specifically, so DKIM passing does not help there.

Which domain does SPF actually check?

The domain of the envelope sender, the address in MAIL FROM, which appears as Return-Path in the delivered message. If that is a bounce subdomain run by your platform, the SPF record belongs on that subdomain.

How can I see the SPF result Microsoft computed?

Ask the recipient for a message that did arrive and read its Authentication-Results header, or send to a Microsoft 365 mailbox you control and read the header yourself with a header analyzer.

550 5.7.23 The message was rejected because of Sender Policy Framework violation

The recipient's Microsoft 365 tenant rejects mail that fails SPF, and yours did. Microsoft does not reject on SPF failure by default; this reply means the tenant has a mail flow rule or a strict anti-spoofing policy that turns an SPF fail into a hard bounce. The sending IP was not in the SPF record of the domain in MAIL FROM.

What the server replies

550 5.7.23 The message was rejected because of Sender Policy Framework violation -> 550 5.7.23 SPF validation failed

Sent by: Microsoft 365
Type: PermanentRetry fails
About: Authentication
Enhanced code: 5.7.23

Who sends it

Exchange Online Protection, after DATA, for tenants whose admin configured a rule on the SPF result. Enhanced code 5.7.23 is defined as "SPF validation failed" in RFC 7372.

Why it happens

A new sending service was added without updating the SPF record.
The envelope sender (Return-Path) domain is different from the From domain and has no SPF of its own.
The SPF record exceeds ten DNS lookups, which evaluates as a permanent error and is treated as fail by strict tenants.
The message was forwarded by an intermediate server that is not in your SPF.

How to fix it

Identify the envelope sender
SPF checks the domain in MAIL FROM, which is often a bounce address like bounces.example.com set by your sending platform. That domain, not the From header's, needs the SPF record.
Add the sending source
Append the provider's include or the server's ip4 to that domain's SPF TXT record and keep the total lookups under ten.
Sign with DKIM as well
A tenant that rejects on SPF alone is rare; most check DMARC, which also passes on an aligned DKIM signature. Signing protects you when forwarding breaks SPF.
Ask the recipient about forwarding
If they forward from another address into Microsoft 365, the forwarder's IP fails SPF and only SRS or DKIM can save it.

Check it yourself

These free tools show the records and connections behind this code for your own domain or server.

Related codes

Sources

Fewer bounces to look up.

Faivelo sends from authenticated, warmed infrastructure, turns permanent bounces into one clean event for your application and keeps the address out of future sends.

Send with Faivelo

Free tier included. No card needed.