What the rejection tells you
Gmail uses 5.7.26 when a message does not meet its sender-authentication expectations. The most useful evidence is the complete bounce because Gmail can include the observed authentication result or policy context. Do not assume the existence of an SPF TXT record means the specific message passed SPF.
Check the real envelope and signing identities
Third-party sending platforms frequently use their own bounce domain until custom domain authentication is completed. That can make SPF pass for the provider while failing DMARC alignment with your visible From domain. DKIM has the same distinction: a valid signature from a provider domain is not automatically aligned with the brand domain.
Verify current DNS without erasing the historical clue
Run public SPF and DMARC checks after reading the bounce. If the domain is currently healthy, consider whether the rejection happened before a recent change. If the domain is unhealthy, resolve the dependency chain instead of adding records blindly. Multiple or oversized SPF configurations can create new failure modes.
Retest with a real delivered header
After correcting the sender configuration, send a fresh message through the same service and inspect the resulting Authentication-Results. A reliable fix is demonstrated by the receiver observing the intended SPF/DKIM results and DMARC alignment, not merely by a vendor control panel displaying a green status.
Verify the evidence
Use the live analysis that matches this workflow instead of relying on a generic status check.