# Why does Gmail report an SPF error?

> Diagnose why Gmail reports an SPF error, including the exact SPF identity Gmail checked, common causes, safe repairs, and validation steps.

Gmail reports an SPF error when the sending IP does not match the SPF policy for the envelope sender it checked, or when Gmail cannot evaluate that policy cleanly. The important detail is the exact identity Gmail evaluated, usually the `smtp.mailfrom` domain in `Authentication-Results`. Fix the route that sent the message. Do not blindly edit the visible From domain's SPF record until you know the real MAIL FROM domain, connecting IP, result, and SMTP code.

## Quick takeaways

- SPF checks the SMTP envelope identity and connecting IP. That domain is often different from the visible From address.
- Gmail can show SPF failure in headers, sender details, or SMTP rejections such as `550 5.7.26` and `550 5.7.27`.
- The most common fix is to authorize the actual sending service on the correct MAIL FROM domain, not to add random includes to every SPF record.
- Multiple SPF records, syntax mistakes, DNS lookup limits, and temporary DNS failures can create `permerror` or `temperror` instead of a simple fail.
- Forwarding can break SPF because Gmail receives the message from the forwarder, not the original sender.
- SPF pass alone does not guarantee DMARC pass. DMARC also needs alignment with the visible From domain, or an aligned DKIM pass.

![Diagnostic flow for a Gmail SPF error, starting with the delivered header, then checking the evaluated domain, connecting IP, SPF result, and repair path](/images/editorial/why-does-gmail-report-an-spf-error/gmail-spf-error-diagnostic.svg)

*Start with the identity Gmail evaluated, then choose the smallest repair. [Open the full-size Gmail SPF diagnostic map](/images/editorial/why-does-gmail-report-an-spf-error/gmail-spf-error-diagnostic.svg).*

## What Gmail is checking when it reports SPF

SPF is defined in [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208) as a check of whether the SMTP client IP is authorized by the domain used in the SMTP MAIL FROM identity. If the reverse-path is empty, SPF can use the HELO identity instead. That is why the visible From address in the email client is not enough evidence by itself.

Gmail exposes the result in different places depending on where the failure appears:

- a delivered message's `Authentication-Results` header, commonly with `spf=fail`, `spf=softfail`, `spf=neutral`, `spf=temperror`, or `spf=permerror`
- Gmail's sender details, where Google says authenticated mail can show **Mailed by** for SPF and **Signed by** for DKIM
- an SMTP rejection or deferral returned to the sending service

Google's [message authentication help](https://support.google.com/mail/answer/180707) also notes that forwarded mail and mailing lists can cause legitimate authentication failures. That does not mean forwarding is always the cause. It means you need the original route and the route Gmail actually received.

The related guide on [reading Authentication-Results in Gmail headers](/learning/how-do-you-read-authentication-results-in-gmail-headers) is the best companion when you already have the original message source.

## The exact Gmail result changes the repair

Do not treat every SPF error as the same problem. RFC 7208 defines several results, and Gmail's own troubleshooting guidance separates missing records, failed authorization, permanent policy errors, and temporary DNS errors.

Use the result this way:

- **`none`:** Gmail did not find an SPF policy for the evaluated identity, or the DNS path did not return one.
- **`neutral`:** the domain published SPF, but the policy does not assert whether the IP is authorized.
- **`softfail`:** the policy says the IP is probably not authorized.
- **`fail`:** the policy says the IP is not authorized.
- **`temperror`:** Gmail hit a temporary DNS problem while evaluating SPF.
- **`permerror`:** the SPF record cannot be interpreted correctly, commonly because of syntax, duplicate SPF records, or too many DNS lookups.

Google's current [SPF troubleshooting guide](https://knowledge.workspace.google.com/admin/security/troubleshoot-spf-issues) tells administrators to use the `spf=` result in `Authentication-Results` and then resolve the specific class of failure. That is safer than changing policy based on a screenshot or a bounce summary.

## Common causes of Gmail SPF errors

### The actual sending service is missing from SPF

This is the ordinary case. A CRM, help desk, billing system, marketing platform, or internal relay sent mail using a MAIL FROM domain that does not authorize that service's outbound IPs. Gmail checks the connecting IP against that domain's SPF record and returns a failure.

Before adding an include, confirm the route:

- the sending platform that produced the message
- the exact MAIL FROM or return-path domain
- the connecting IP Gmail saw
- the provider's current SPF instructions for that sending mode
- whether the domain uses a custom bounce or return-path domain

Google's [SPF setup guide](https://knowledge.workspace.google.com/admin/security/set-up-spf) says administrators should identify every service that sends mail for the domain and authorize those services in the SPF record. It also warns that each domain and subdomain has its own SPF record.

### SPF was published on the wrong hostname

A visible From domain of `example.com` can coexist with a return path such as `bounce.example.com`, `mail.example.net`, or a provider-owned domain. If Gmail evaluated `smtp.mailfrom=bounce.example.com`, then changing the root `example.com` SPF record may not affect the failing message at all.

This is especially common with platforms that use a branded return path, custom bounce domain, or subdomain delegation. Check the delivered `Authentication-Results` and `Return-Path` before editing DNS.

### More than one SPF record exists

RFC 7208 says SPF records are DNS TXT records and that multiple SPF records for the same owner name cause a permanent error. In practice, this often happens when a team adds a second `v=spf1` TXT record instead of merging mechanisms into the existing one.

The repair is to publish one valid SPF record at the evaluated hostname. Keep only one `v=spf1` policy for that name, and remove old duplicates after confirming no other sender still depends on them.

### The record exceeds SPF lookup limits

SPF evaluation has a DNS lookup limit. RFC 7208 sets a limit of 10 DNS-querying mechanisms and modifiers, including nested lookups. A record with several `include:` mechanisms can exceed the limit after all included records are expanded.

When Gmail reports `permerror`, count the DNS-causing terms for the exact evaluated domain. Remove unused sending services, use provider-supported flattening only with operational ownership, or split mail streams across appropriate subdomains when that matches the sender design.

Do not flatten SPF by copying random IPs from provider records into DNS once and forgetting them. Many SaaS providers change their infrastructure, and stale copied IPs can create a quieter failure later.

### DNS temporarily failed

`temperror` points to a transient DNS problem, not necessarily a wrong sender. Check authoritative DNS health, DNSSEC issues where relevant, resolver consistency, and recent zone changes.

Google says SPF changes can take up to 48 hours to propagate. If the domain was just changed, compare results from multiple public resolvers and the authoritative nameservers before assuming Gmail is using a stale value forever.

### Forwarding changed the connecting IP

SPF is path-sensitive. If a mailbox provider or forwarding service resends the message to Gmail without preserving authorization through another mechanism, Gmail may see the forwarder's IP as the connecting IP. The original sender's SPF can fail even when the original hop was legitimate.

DKIM often survives forwarding better than SPF because it signs message content and a domain identity rather than authorizing one SMTP client IP. ARC can help preserve authentication context across intermediaries, but ARC does not make SPF pass for the final hop.

The guide on [why SPF and DKIM can pass while Gmail still warns](/learning/can-spf-and-dkim-pass-while-gmail-still-shows-a-warning) covers the broader point: authentication results are evidence, not a complete safety or placement verdict.

## Diagnose the error from the original message

### 1. Preserve the original evidence

Use the delivered message source or the sending platform's original SMTP response. A forwarded copy is not enough because forwarding can change the path, wrap headers, or add new authentication results.

Record:

- Gmail account type, personal Gmail or Google Workspace
- UTC timestamp
- exact SMTP response, if the message was rejected or deferred
- full `Authentication-Results` header
- visible From, Sender, Reply-To, and Return-Path
- `smtp.mailfrom`, `smtp.helo`, SPF result, and connecting IP
- every DKIM `d=` domain and DMARC result
- sending platform, campaign, stream, and route

If Gmail rejected the message, Google's [SMTP error reference](https://support.google.com/mail/answer/3726730) lists current SPF-related codes, including `451 4.7.24`, `550 5.7.24`, `421 4.7.27`, `550 5.7.26`, and `550 5.7.27`.

### 2. Identify the SPF domain Gmail evaluated

Find the `smtp.mailfrom` property in `Authentication-Results`. If the reverse-path was empty, inspect the HELO result. The [Authentication-Results standard, RFC 8601](https://www.rfc-editor.org/rfc/rfc8601), defines receiver-added authentication results and properties such as `smtp.mailfrom` and `smtp.helo`.

Only trust `Authentication-Results` added by the receiver you are diagnosing or by a trusted internal hop. Older or upstream headers can describe a different hop.

### 3. Match the connecting IP to the intended sender

Compare the IP Gmail saw with the provider and product route that should have sent the message. If the IP belongs to the wrong provider, the fix is not an SPF include. It may be a compromised account, a misrouted application, an old SMTP relay, or a forwarding path.

If the IP belongs to the right provider, verify that the provider's current instructions authorize that route for the evaluated MAIL FROM domain. Some providers have separate records for shared domains, dedicated IPs, branded return paths, and regional infrastructure.

### 4. Query the exact SPF record

Query the evaluated hostname, not the domain you expected. Confirm that it returns one TXT record beginning with `v=spf1`.

Check:

- there is exactly one SPF record for that hostname
- the syntax is valid
- every include or redirect still belongs to an active sender
- the record does not exceed SPF's DNS lookup limit after expansion
- the terminal mechanism matches your enforcement intent, such as `~all` or `-all`

Use a resolver check as evidence, then validate with a real delivered message. The free [SPF checker](/tools/spf) is useful for inspecting a public SPF record, but the delivered header still decides which hostname and IP Gmail actually evaluated.

### 5. Repair the narrowest failing route

Make the smallest change that fits the evidence:

- add the current provider-approved SPF mechanism to the evaluated MAIL FROM domain
- move the application to the already authorized sending route
- fix duplicate records or syntax that causes `permerror`
- remove unused includes to stay under the DNS lookup limit
- correct DNS hosting or delegation problems that cause `temperror`
- enable aligned DKIM for the stream when forwarding or DMARC alignment makes SPF fragile

Avoid broad edits that authorize a platform for domains or subdomains it does not actually use. SPF is an allowlist for mail infrastructure, so every extra mechanism is part of the domain's abuse surface.

## How SPF errors affect DMARC

DMARC does not simply ask whether SPF passed somewhere. The current DMARC standard, [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), evaluates whether a passing SPF or DKIM identity aligns with the visible From domain.

That means:

- SPF can fail and DMARC can still pass if aligned DKIM passes.
- SPF can pass and DMARC can still fail if the SPF domain does not align with the visible From domain and DKIM does not provide an aligned pass.
- Publishing DMARC does not repair SPF. It gives receivers policy and reporting instructions for authenticated domain identity.

For Mailchimp specifically, the article on [Mailchimp DMARC alignment and SPF](/learning/why-does-mailchimp-dmarc-alignment-not-require-adding-mailchimp-to-spf) explains why DKIM alignment can be the better repair than forcing SPF to align through the visible From domain.

## Validate the repair

After DNS changes are visible, send through the same production route that failed. Do not validate with a different product, subdomain, IP pool, or message stream.

Confirm:

- the evaluated SPF hostname now returns one valid SPF record
- the sending IP is authorized by that record
- Gmail's delivered header shows the expected `spf=` result for the expected `smtp.mailfrom`
- DMARC passes through aligned SPF or aligned DKIM when the message uses your visible From domain
- the same Gmail SMTP code no longer appears in the sending logs
- DMARC aggregate reports show the corrected source over the next reporting window

Google's SPF troubleshooting guide says a third-party sender missing from SPF is a common cause of failure, and it also notes that SPF changes can take 24 to 48 hours to take effect. Keep timestamps so you can separate propagation delay from a failed repair.

## Palisade helps connect SPF errors to real senders

Palisade cannot edit DNS for you, change Gmail's filtering decisions, approve a sender Gmail rejected, repair a forwarding service, or guarantee inbox placement.

Palisade can analyze DMARC aggregate reports for domains you control. That helps an IT team or MSP identify which services are sending as the domain, compare SPF and DKIM authentication with the visible From domain, and see whether an unfamiliar or failing route is recurring across receivers.

Use the free [Email Security Score](/tools/email-security-score) to inspect public SPF and DMARC posture. If this SPF error exposed a broader sender-inventory problem, [start a Palisade account](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=gmail_spf_errors&utm_content=why_does_gmail_report_an_spf_error) after you preserve the original Gmail evidence.

## Frequently asked questions

### Does Gmail check SPF against the From address?

Not usually. SPF checks the SMTP MAIL FROM domain, often visible as the return path, against the connecting IP. DMARC is the layer that compares SPF or DKIM identity with the visible From domain.

### Why does Gmail say SPF failed when my root domain has SPF?

Gmail may have evaluated a subdomain or provider-owned MAIL FROM domain, not the root domain. Check `smtp.mailfrom` and `Return-Path` in the original message before editing DNS.

### Can I fix a Gmail SPF error by adding Google's SPF include?

Only if Google Workspace is the actual sender for the evaluated MAIL FROM domain. Adding `include:_spf.google.com` does not authorize Microsoft, Mailchimp, a CRM, a help desk, or a forwarding service.

### Does SPF fail mean the message is phishing?

No. SPF failure means the connecting IP was not authorized by the evaluated SPF policy, or the policy could not be evaluated. It can come from a malicious sender, a misconfigured legitimate service, or forwarding.

### How long should I wait after changing SPF?

Google says SPF changes can take up to 48 hours, and its troubleshooting guide mentions 24 to 48 hours for changes to take effect. Verify DNS from authoritative and public resolvers, then retest the same sending route.

### Can DKIM fix a Gmail SPF error?

DKIM does not make SPF pass. It can help DMARC pass when DKIM uses a domain aligned with the visible From address, especially when SPF is fragile because of forwarding or third-party return paths.