550 5.7.27 Gmail: message blocked, SPF did not pass

What Gmail says

This message was blocked because it didn't pass SPF authentication. Gmail requires bulk email senders to authenticate their email with SPF. Authentication results: SPF with ip-address = did not pass
To set up SPF for your sending domains, visit Set up SPF (https://knowledge.workspace.google.com/admin/security/set-up-spf). To learn more about Gmail requirements for bulk email senders, visit Email sender guidelines (https://support.google.com/mail/answer/81126).

Source: Google, Gmail SMTP errors and codes, section 550 5.7.27, fetched 2026-10-08.

What it means, in plain words

SPF for your envelope sender domain did not pass for the IP that delivered the message: that IP is not in the record, or the record could not be evaluated. Google's text addresses bulk email senders.

Check your own domain

dig +short TXT yourdomain.com | grep v=spf1

Count the lookups in the record (each include, a, mx, redirect and exists is one). Ten is the RFC 7208 limit; past it the record returns permerror, which also fails SPF. The SPF checker counts them for you.

The fix

Add the sending service's SPF include (its documented value, not a guess) to the one SPF record on the domain.
One SPF record only. Two records are a permerror.
Keep the lookup count at ten or fewer.
If the sending service uses its own envelope domain (a bounce subdomain), the SPF record that matters is on that subdomain, not on your apex.

This error is live on your domain right now. If you need it gone today, the Humerly Emergency Fix is the direct route: your DNS, every change on your approval, verified before we call it done. Details and the price are on the Emergency Fix page.

Request the fix

What this page covers: the authentication records the receiver checked and how to correct them. It does not predict where a message lands once accepted; authentication and inbox placement are separate questions.

FAQ

My SPF record is correct. Why did it fail?

SPF is checked against the envelope sender domain (Return-Path), which is often a subdomain set by the sending service. Check that domain, not only your apex.

Does ~all instead of -all avoid this error?

No. The error reports that the check did not pass. The qualifier changes how a failure is labelled, not whether the IP is authorised.

Is 5.7.27 permanent?

It is a 550, a permanent rejection of that message. Fix the record and send again.