550 5.7.27: Blocked because SPF did not pass
550 5.7.27 from Gmail means the message was blocked because it did not pass SPF. The sending server is not allowed by your SPF record. The standard meaning of the code is different, so read the text.
- Bounce type
- Hard bounce (permanent)
- Usually caused on
- Your sending side
- Terlido report label
- Blocked by the provider
What the standard says
RFC 5321 defines 550 as "mailbox unavailable", which includes refusals for policy reasons. RFC 7505 defines X.7.27 as "Sender address has null MX": the domain in the sender address publishes that it accepts no mail. Gmail uses 5.7.27 for a different purpose, an SPF failure, so the text is the guide.
What the mailbox providers say
- Gmail (550 5.7.27): “This message was blocked because it didn't pass SPF authentication...” Source
Common causes
- The sending server or service is not listed in your SPF record.
- The SPF record is missing from DNS for the domain used in the envelope sender.
- The record has more DNS lookups than SPF allows, so the check fails.
- A forwarding step changed the sending IP, so the original SPF record no longer matches.
- Under the RFC 7505 meaning, the sender's domain publishes a null MX and cannot be used as a sender.
- A domain used for the envelope sender that has no SPF record because it is a separate bounce or tracking domain.
How to fix it
- Add the sending service to the SPF record for your domain.
- Reduce the number of lookups in the record so it stays inside the limit.
- Check that the domain in the envelope sender has its own SPF record.
- Make DKIM and DMARC work as well, so mail does not rely on SPF alone.
- Check which domain your sending tool uses for the envelope sender, and publish SPF for that domain too.
- If the bounce text matches the null MX meaning, stop using that domain as a sender address.
Is it a deliverability problem?
Yes. An SPF failure puts your domain at risk with every receiver that checks it. Gmail asks for authentication from bulk senders, and a repeated SPF fail shows up as a blocked message like this one. Because the standard meaning and the Gmail use differ, reading the text saves time. If it talks about SPF, work on SPF. If it talks about a null MX, the sender's domain was set up to take no mail and is the wrong address to send from.
How Terlido handles it
When a bounce message for this code arrives in a connected mailbox, Terlido reads the status code. An enhanced code that starts with 5 is a hard bounce. In the campaign Reports tab this one is grouped as "Blocked by the provider".
On a hard bounce Terlido adds the address to the workspace blocklist with the reason "hard bounce", so no campaign emails it again. The lead stops in that campaign as bounced, its lead score goes down by 15, and the bounce counts toward the campaign's bounce rate.
Once a campaign has at least 20 sends, it pauses itself when hard bounces divided by sends goes over the campaign's maximum bounce rate. The default is 5%. If the cause was on your side and you fixed it, you can remove the entry on the Blocklist page of your account settings and try again.
Terlido treats every 5.x.x code as a hard bounce, so it blocklists the recipient even when the real cause is your own sending setup. After you fix the sending side, remove the entry from the blocklist if you want to contact that person again.
Check the domain behind the bounce
The free domain checker runs live SPF, DKIM, DMARC, MX and blocklist lookups and explains each result in plain English.
Free tools that help
- SPF checkerInspect a published SPF record and its recursive DNS lookup budget.
- SPF lookup limit checkerTrace SPF DNS lookups against the 10-lookup limit.
- DMARC alignment checkerCompare header domains under relaxed or strict alignment.
Related error codes
- 550 5.7.23: SPF validation failed
- 550 5.7.26: Blocked because the sender is unauthenticated
- 421 4.7.26: Rate limited because mail is unauthenticated