Why am I seeing Gmail SPF error messages and how do I fix it?
Published 23 May 2025
Updated 21 Oct 2026
13 min read
Summarize with
Updated on 25 Oct 2026: We clarified Gmail SPF setup, hard-fail errors, and the DNS checks needed to verify a fix.
Gmail shows SPF errors when the envelope sender domain does not pass Sender Policy Framework (SPF) authentication for the connecting IP address. When MAIL FROM is empty, SPF uses the HELO identity instead. The cause can be an unauthorized sending IP, a temporary DNS error, an invalid policy, a lookup-limit breach, forwarding, or a sender using a different return-path domain than the one you checked.
The fix is to test the same sending path Gmail sees, then repair the exact condition that produces the result. Do not stop after checking the top-level SPF TXT record. SPF evaluates mechanisms in order and follows DNS-querying terms such as include, mx, a, exists, ptr, and redirect. A timeout or SERVFAIL can produce temperror; malformed or multiple policies and lookup-limit breaches can produce permerror; an unauthorized IP can produce fail.
A Yahoo SPF pass does not prove Gmail is wrong. It proves Yahoo could evaluate SPF for that message at that time. Gmail can query different DNS resolvers, reach a different authoritative name server, or evaluate another delivery attempt with a different return-path or sending IP.
What the Gmail SPF error means
One common Gmail response is a 421 temporary SMTP error. It often looks like this:
Example Gmail SMTP responsetext
host alt1.gmail-smtp-in.l.google.com[64.233.171.26] said: 421-4.7.27 Your email has been rate limited because SPF authentication 421-4.7.27 didn't pass for this message.
The important parts are 421, 4.7.27, and SPF authentication didn't pass. A 421 response is temporary, so the sending server should queue the message and retry. Retrying alone will not fix the cause if SPF keeps failing. Gmail is telling you that the bulk mail stream has an SPF authentication problem that now affects acceptance.
Treat this as an authentication incident, not a generic deliverability complaint. First identify the exact domain Gmail evaluated for SPF. That domain comes from the envelope sender, also called the return-path or MAIL FROM domain, and it is not always the visible From header domain.
- Check result: Find whether Gmail saw SPF fail, softfail, neutral, none, permerror, or temperror.
- Check domain: Confirm the return-path domain, because that is the domain SPF authenticates.
- Check DNS: Trace every lookup behind the SPF record, especially include and mx mechanisms.
- Check timing: Repeat tests because intermittent authoritative DNS faults can create Gmail-only spikes.
Match the Gmail code before editing SPF
Read the complete SMTP reply before editing DNS. A 4.x enhanced status is a temporary deferral, while a 5.x status is a permanent rejection of that delivery attempt. Google's SMTP error reference lists several meanings for 5.7.26, so the accompanying text matters.
|
|
|
|---|---|---|
4.7.27 | SPF did not pass; Gmail rate limited the stream | Fix SPF, keep queued retries controlled |
5.7.27 | SPF did not pass; Gmail blocked the message | Do not retry unchanged; repair authentication |
4.7.26 or 5.7.26 | Unauthenticated mail or a DMARC-policy error; 5.7.26 also covers SPF hard fail | Read the full text; check SPF, DKIM, and DMARC |
4.7.32 or 5.7.32 | The visible From domain does not match authenticated SPF or DKIM | Make the return-path or DKIM domain match From |
Gmail authentication codes and the correct first response.
SPF pass and SPF alignment are different
SPF can pass for a return-path domain while DMARC alignment fails because that domain does not satisfy the domain-matching rules for the visible From header. Relaxed matching permits a shared organizational domain; strict matching requires the exact domain. For a 4.7.32 or 5.7.32 error, configure an aligned custom return-path or make aligned DKIM pass. Adding an SPF include to the visible From domain does not help if the sender still uses another domain in MAIL FROM.
Google's sender authentication requirements apply to personal Gmail accounts. All senders must pass SPF or DKIM. Bulk senders sending 5,000 or more messages per day must use both, publish DMARC with at least p=none, and satisfy DMARC domain matching for direct mail. A DKIM pass alone does not meet the bulk SPF requirement.
Why the same message can pass elsewhere
Mailbox providers do not share one SPF evaluator. Gmail, Yahoo, and corporate gateways each resolve DNS independently. When SPF evaluation reaches an mx mechanism, the receiver resolves the MX records and then the address records for those MX hostnames. A failure at that second step can turn a valid-looking SPF record into a temporary SPF failure.
This is why a message can show spf=pass at Yahoo while Gmail returns 421 4.7.27. For example, Yahoo's resolver can reach the needed DNS answer while Gmail's resolver encounters a timeout or SERVFAIL, or the providers can check at different times. A lookup-limit breach produces permerror, which is different from a temporary DNS failure. The SPF TXT string can stay the same while the full SPF evaluation changes.
Looks fine
- Top TXT: The SPF TXT record exists and has one v=spf1 policy.
- One receiver: Another mailbox provider reports SPF pass for a delivered copy.
- Same IP: The outbound server is included somewhere in the SPF path.
Still broken
- Deep lookup: A nested include, mx, a, redirect, or exists lookup fails.
- DNS path: One authoritative name server returns SERVFAIL or times out.
- Sender path: The return-path domain differs across message streams.
Flowchart showing Gmail checking the MAIL FROM domain, DNS lookups, and the SPF result.
Fast checks before editing DNS
Before changing your SPF record, capture a failed Gmail attempt and a successful message to another mailbox provider. For a delivered Gmail copy, open the message in a browser and select More beside Reply, then Show original. Inspect Gmail's Authentication-Results for spf=, smtp.mailfrom, dkim=, dmarc=, and header.from; use Received-SPF, Received, or SMTP logs for the connecting IP. Compare these with the failed attempt. Different values mean different sending paths.
Then validate the live SPF path. Suped's SPF checker is useful here because it expands the mechanisms and shows lookup errors that a simple TXT lookup hides. A broader domain health check helps when you also need to verify DMARC, DKIM, and DNS health around the same sending domain.
- Read bounce: Copy the full Gmail SMTP response, including the basic code, enhanced code, target MX host, and authentication results.
- Find MAIL FROM: Identify the envelope sender domain and connecting IP. If Gmail received IPv6, verify authorization for that IPv6 address; an ip4 mechanism cannot authorize it.
- Trace SPF: Expand include, mx, a, exists, and any existing ptr mechanisms, plus the redirect modifier, until the failing lookup or unauthorized IP is visible.
- Compare providers: Check whether Gmail alone fails, or whether other receivers report delayed mail.
- Check policy: Review Google's SPF notes when the error appears only at Gmail.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
If the SPF checker reports temperror, permerror, too many DNS lookups, multiple SPF records, or a missing sender IP, fix that before changing content, volume, or reputation controls. For a 4.7.32 or 5.7.32 error, shift the investigation to DMARC alignment instead of adding more SPF mechanisms.
Set up SPF for the service that sends your mail
Your SPF record authorizes outbound senders. Receiving mail at Gmail does not mean the sending domain needs Google's include. If another service sends your mail, use that service's documented SPF configuration. If it uses a custom return-path subdomain, configure that exact name; SPF does not inherit the parent domain's policy.
If Google Workspace is your only outbound sender for the evaluated domain, Google's SPF guidance gives this TXT value. In your authoritative DNS settings, use @ for the root domain or the exact return-path subdomain as appropriate:
SPF TXT value for Google Workspace as the only sendertext
v=spf1 include:_spf.google.com ~all
If an SPF policy already exists at that name, edit it rather than adding a second v=spf1 record. Keep authorization for other legitimate senders and add approved mechanisms before the final all term. Do not copy a multi-provider record unless every included service actually sends for that domain.
For a Gmail 550 5.7.26 reply that specifically mentions an SPF hard fail policy (-all), authorize the legitimate sending IP or correct the sending route. Changing -all to ~all changes an unauthorized result to softfail, not pass. Never use +all as a fix, because it authorizes every IP address.
Common causes and exact fixes
Most Gmail SPF errors fall into a small set of technical causes. Trace the actual SPF path and use the reported result to choose the fix; do not edit the record you expected Gmail to read without confirming smtp.mailfrom first.
|
|
|
|---|---|---|
Missing SPF record | None | Publish one v=spf1 TXT policy at the evaluated domain |
Multiple SPF records | Permerror | Merge authorized senders into one v=spf1 TXT policy |
Syntax fault | Permerror | Correct the invalid term |
Unlisted sender | Fail, softfail, or neutral | Authorize the exact source |
DNS temperror | SPF temperror; a DNS timeout or SERVFAIL | Repair authoritative DNS |
Lookup limit | Permerror | Remove unused nested lookups |
Broken mx | MX address lookup fails | Repair DNS or replace mx |
Forwarding | Forwarder IP is checked | Ask the forwarder to use SRS and preserve aligned DKIM |
Wrong return-path | Unexpected smtp.mailfrom | Correct the sender configuration |
Common Gmail SPF error causes and repair direction.
The fastest safe fix depends on the cause. If the sending IP is missing, add the correct include, ip4, or ip6 mechanism. If the evaluated policy exceeds the limit of ten DNS-querying terms, including nested terms, remove obsolete senders and avoid unnecessary nested mechanisms first. Use carefully maintained SPF flattening only when provider IP changes can be tracked, because stale flattened addresses can create new failures. If forwarding breaks SPF, keep aligned DKIM stable so DMARC can pass through DKIM.
The ten-term limit counts evaluated DNS-querying mechanisms and modifiers, not every individual DNS query. ip4, ip6, and all do not consume that allowance. RFC 7208 also recommends a separate limit of two void lookups, which return no usable answer; exceeding an enforced void limit produces permerror.
Illustrative SPF records with different authorization pathsdns
mx-path.example.com. TXT "v=spf1 mx include:_spf.sender.example -all" direct.example.com. TXT "v=spf1 ip4:203.0.113.8 include:_spf.sender.example -all"
The first example depends on MX and address resolution during SPF evaluation. The second authorizes a sender IP and an include directly. Direct authorization is easier to debug when inbound mail DNS and outbound mail DNS are managed by different teams. These are separate records on separate names, not two SPF records for one domain. Replace the documentation IP and example include target with your sender's approved values before publishing.
How the SPF mx mechanism causes DNS errors
An SPF record can look correct and still fail because of mx. The mx mechanism looks up the domain's MX hosts, then their A records for an IPv4 connection or AAAA records for an IPv6 connection. A timeout or SERVFAIL during these lookups can stop SPF evaluation even though the top-level SPF TXT record is present.
This is one possible cause of intermittent Gmail errors. A successful DNS answer with no matching address is not itself temperror; SPF continues to later mechanisms, subject to the separate void-lookup limit. RFC 7208 defines these processing rules. A missing AAAA record alone does not break SPF for an IPv4 connection.
DNS commands to trace the mx pathbash
dig TXT example.com +noall +comments +answer dig MX example.com +noall +comments +answer dig A mail.example.com +noall +comments +answer dig AAAA mail.example.com +noall +comments +answer dig +trace A mail.example.com # Replace this server with the authority for the MX hostname's zone: dig @ns1.example.net A mail.example.com +norecurse +noall +comments +answer
Use mx in SPF only when those MX hosts actually send outbound mail for the domain and their DNS is reliable. Inbound MX routing does not automatically describe your outbound senders.
When mx is the cause, repair the failing authoritative DNS. If replacing mx with stable outbound IPs or a maintained sender include, preserve authorization for every legitimate outbound sender. If the issue comes and goes, query each authoritative name server for the affected zone directly instead of relying on one cached recursive answer. Replace the example names above with the evaluated domain, its MX hostname, and that hostname's authoritative server; the comments output retains DNS status codes that +short hides.
Track SPF issues with Suped
Manual SPF tracing works for a one-off incident. It becomes hard when a team manages several domains and changing senders. Suped's DMARC platform groups reported authentication results by sending source so teams can compare SPF failures across domains.
Suped turns aggregate DMARC data into source-level authentication results and tracked issues. Use those results to identify affected senders and follow repair steps, then confirm Gmail rejections with SMTP logs. Aggregate reports are periodic summaries, so they do not replace the full bounce text or a live SPF evaluation.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's Hosted SPF supports sender authorization when the SPF policy changes often or the team that owns DNS is not the team that owns email. Teams can update authorized senders through Suped while keeping the published SPF policy and lookup usage controlled.
SPF triage thresholds
Use these thresholds to decide how urgent a Gmail SPF incident is.
Healthy
Pass
Gmail accepts mail and SPF passes consistently.
Investigate
Temperror
Some Gmail attempts show temporary SPF failures.
Fix now
421 4.7.27
Gmail rate limits mail because SPF does not pass.
Correct policy
Permerror
The SPF policy is invalid, exceeds DNS limits, or cannot complete.
How to prevent repeat Gmail SPF errors
Once the immediate Gmail error is fixed, remove the conditions that made the failure hard to spot. SPF should have one policy, controlled lookups, stable DNS, and a clear owner for every authorized sender.
- Publish one policy: Keep all authorized senders in one v=spf1 TXT record for each domain.
- Limit lookups: Keep the evaluated SPF path within the limit of ten DNS-querying terms and audit nested includes after sender changes.
- Avoid fragile mx: Prefer explicit outbound sender authorization when MX DNS is owned elsewhere.
- Monitor sources: Watch for new sending IPs and return-path domains before Gmail sees them at scale.
- Keep DKIM passing: Aligned DKIM gives DMARC another path to pass when forwarding breaks SPF.
- Document ownership: Assign each include, IP range, and DNS zone to a team that can repair it quickly.
After a DNS edit, verify every authoritative answer, then account for the old TTL and queued-message retries. Google's SPF troubleshooting guidance allows up to 48 hours for changes to take effect globally; actual cache expiry depends on TTLs. Send fresh tests through each affected sender to Gmail, confirm spf=pass in Show original, and check SMTP logs for resumed acceptance before closing the incident.
If your Gmail SPF errors involve forwarded mail, review forwarding failures separately because SPF is tied to the connecting IP. If the symptoms come and go with no sender change, the DNS issue pattern is the more likely path.
Views from the trenches
Best practices
Trace every SPF mechanism before editing DNS, because the visible TXT is only the start.
Compare Gmail failures with a passing provider to find sender, timing, and DNS differences.
Keep outbound authorization separate from MX routing when DNS ownership is split.
Common pitfalls
Assuming one provider's SPF pass proves Gmail is wrong wastes valuable incident time.
Using mx in SPF hides extra DNS dependencies that fail under resolver or zone trouble.
Debugging without the real domain and sending IP leaves too many causes unresolved.
Expert tips
Check every authoritative name server directly when SPF failures appear intermittent.
Treat Gmail 421 SPF errors as authentication incidents before changing send volume.
Keep DKIM healthy so forwarded mail can still satisfy DMARC when SPF breaks in transit.
Marketer view
Marketer from Email Geeks says exact domains and IPs are needed to explain Gmail SPF behavior, because a generic SPF pass at another provider does not show what Gmail evaluated.
2024-04-25 - Email Geeks
Marketer view
Marketer from Email Geeks says SPF tracing exposed a temporary failure tied to an mx mechanism, so troubleshooting should follow each DNS lookup behind the record.
2024-04-25 - Email Geeks
Frequently asked questions
No. It means SPF did not pass when Gmail evaluated the message. The top-level record can look valid while a nested include, mx lookup, DNS timeout, lookup-limit breach, or sender mismatch prevents a pass.
A 4.7.27 result is a temporary SPF-related deferral, so the sending server should retry after the cause is fixed. A 5.7.27 result is a permanent rejection of that delivery attempt, so retrying the same unchanged message will not solve it.
Each provider resolves DNS independently and can check a different delivery attempt. A temporary DNS failure, cached answer, different sending IP, or different return-path domain can make Gmail fail while Yahoo passes.
Remove it when it adds fragile DNS dependencies or when inbound MX hosts are not the systems that send outbound mail. Use stable direct IPs or maintained includes for clearer authorization.
Yes. SPF checks the connecting IP, so forwarding often breaks SPF because the forwarder is not listed in the original sender's SPF record. SRS can restore an SPF pass for the rewritten return-path, and aligned DKIM can let DMARC pass when SPF does not. An SRS rewrite usually changes the SPF domain, so its SPF pass alone does not restore DMARC matching with the original From domain.
Use the reported SPF result to choose the fix: repair DNS for temperror, correct syntax or DNS-limit problems for permerror, or authorize the legitimate sender for fail. If Gmail reports 4.7.32 or 5.7.32, fix DMARC domain matching through SPF or DKIM instead of adding unrelated SPF mechanisms.
