Quick answer
Gmail 5.7.27 means Gmail blocked the message because SPF authentication did not pass for that message. The related 4.7.27 code is the temporary rate-limit variant. Check the visible sending setup, the envelope sender domain, the actual sending IP, and the SPF record. A domain-level SPF record can look valid while a specific message still fails if the real sender is not authorized or SPF evaluation hits an error.
Gmail 5.7.27 is an SPF-specific authentication failure
Google's sender guidelines FAQ maps 5.7.27 to messages blocked because SPF authentication did not pass. The temporary variant is 4.7.27; the permanent rejection variant is 5.7.27. Both point to the same diagnostic path: Gmail evaluated SPF for the message and did not get a passing result.
Do not treat 5.7.27 as a generic spam complaint. Start with SPF and the real sending path. After SPF passes, check DKIM and DMARC alignment because modern Gmail sender requirements evaluate authentication as a combined baseline, not as one isolated DNS record.
Check the envelope domain, not only the visible From domain
SPF authenticates the SMTP identity used during delivery, often called the envelope sender, return-path, or bounce domain. It does not directly authenticate the visible From header that recipients see.
That distinction is why SPF debugging can be confusing. The visible From address might be news@example.com, while SPF is evaluated against a return-path domain controlled by an ESP. That SPF result can pass or fail independently of what users see.
DMARC connects those worlds by requiring alignment between the visible From domain and either SPF or DKIM. For a 5.7.27 bounce, first fix SPF for the message. Then confirm that SPF alignment or DKIM alignment can satisfy DMARC.
Check whether the real sending IP is authorized
SPF is defined in RFC 7208. It lets a domain publish which hosts are authorized to send mail for that domain's SPF identity.
The SPF record must authorize the actual sending IP or provider. If you send through Google Workspace, Microsoft 365, SendGrid, Mailgun, Postmark, a CRM, or a newsletter platform, the relevant provider must be represented correctly in the SPF record for the domain Gmail evaluated.
Do not add your website IP, MX host, or office IP unless that system actually sends outbound mail for the failing stream. MX records route inbound mail; they do not automatically authorize outbound mail.
Check for multiple records, syntax errors, and lookup-limit failures
SPF can fail even when a domain appears to have "an SPF record." Common causes include multiple SPF TXT records at the same name, broken syntax, missing includes, invalid mechanisms, or SPF evaluation exceeding the DNS lookup limit.
SPF includes, redirects, a, mx, ptr, and exists mechanisms can trigger DNS lookups. The SPF specification limits evaluation to 10 DNS lookups. When the sender record crosses that boundary, receivers can return a permanent error rather than a clean pass.
If several teams or vendors added their own SPF records over time, merge authorized senders into one SPF record. Do not publish one SPF TXT record per provider.
Check a real Gmail header or bounce when the public record looks right
A public SPF checker can inspect the record and catch structural problems. It cannot always prove why a specific Gmail delivery attempt failed unless you know the evaluated domain and sending IP.
The bounce text may include the IP Gmail evaluated. A delivered test message may show SPF results in Gmail's original message headers. Use those details to compare the real sending IP against the record.
If the record looks valid but Gmail still returns 5.7.27, the likely issue is that you checked the wrong domain, the actual stream uses a different provider, DNS propagation has not reached Gmail's resolver path, or the record depends on an include chain that fails during evaluation.
Fix SPF without breaking DMARC alignment
SPF passing is not the end of the authentication workflow. DMARC, defined in RFC 7489, requires aligned SPF or aligned DKIM for the visible From domain.
If you fix SPF by authorizing a provider-owned return-path domain that does not align with the From domain, Gmail may stop returning the SPF-specific error but the message can still fail DMARC. Where possible, configure the ESP's custom return-path or DKIM signing so the authenticated domain aligns with your From domain.
The safest fix is to follow the sending provider's SPF instructions, then verify the result with a real Gmail header.
How to fix Gmail 5.7.27
- Keep the full bounce text and the sending platform name.
- Identify the envelope sender or return-path domain if available.
- Check the SPF record for that domain.
- Confirm the real sending IP or provider is authorized.
- Remove duplicate SPF TXT records and fix syntax errors.
- Reduce SPF lookup count if evaluation exceeds the limit.
- Send a controlled Gmail test and inspect the SPF result in headers.
- Confirm DMARC alignment after SPF passes.
What this does not prove
Fixing Gmail 5.7.27 proves only that you addressed an SPF authentication failure path. It does not prove DKIM passes, DMARC aligns, Gmail reputation is healthy, or the next accepted message will land in the inbox.
Relaymetry can inspect the public SPF record and explain likely record-level failures. It cannot know the exact SPF result for a specific message unless the evaluated domain and sending IP are available from a bounce, header, or user-provided context.