What causes SPF verification failures for emails forwarded to Gmail?
Updated on 14 Oct 2026: We clarified Gmail forwarding authentication and corrected the SPF troubleshooting examples.
SPF verification fails for forwarded emails to Gmail because SPF checks the server that connects to Gmail against the domain in the SMTP envelope sender, rather than the visible From address. A normal forward changes the connecting server. If the envelope sender still belongs to the original sender, Gmail sees the forwarder's IP sending for a domain that did not authorize it.
Ordinary forwarding often prevents an SPF pass because the original sender's record does not authorize the forwarding IP. Sender Rewriting Scheme (SRS) changes the envelope sender to a domain the forwarder controls. SPF then passes if that domain has a valid record authorizing the connecting IP. A -all policy returns an SPF fail for an unauthorized IP, but Gmail combines that result with other authentication and policy signals when deciding whether to reject, filter, or deliver the message.
- Main cause: the message reaches Gmail from a forwarding server that the original domain did not list in SPF.
- Best fix: use SRS at the forwarder, keep the forwarder's SPF accurate, and preserve DKIM where possible.
- Best evidence: read the delivery status notice, the Authentication-Results header, provider logs, and the message route together.
Why forwarding breaks SPF
SPF is tied to the SMTP transaction. Gmail checks the connecting IP and asks whether the domain in the envelope sender authorized that IP. When mail is sent directly, that usually works: the sender's mail server connects to Gmail, and the sender's SPF record contains that server.
Email forwarding flow with SRS rewriting the envelope sender before Gmail checks SPF.
Forwarding adds a new hop. The forwarding server connects to Gmail, but the original sender's domain can still be in the envelope sender. That produces a mismatch. SRS solves that specific problem by rewriting the envelope sender into a return path owned by the forwarder while preserving enough information to send bounces back correctly. Gmail performs its own authentication check on the forwarded transaction, so an SPF pass recorded before the forward does not automatically carry over.
Forwarding without SRStext
Original MAIL FROM: user@sender.example Forwarder connects from: 203.0.113.25 Gmail SPF question: can sender.example use 203.0.113.25? SPF result if sender.example uses -all: fail
Forwarding with SRS (illustrative hash and timestamp)text
Rewritten MAIL FROM: SRS0=HASH=TT=sender.example=user@forwarder.example Forwarder connects from: 203.0.113.25 Gmail SPF question: can forwarder.example use 203.0.113.25? Expected result: SPF pass, if the forwarder SPF record is correct
Which domain SPF checks
When a bounce says "the domain" failed SPF, read that as the SPF domain used in the SMTP envelope sender unless the delivery notice gives stronger evidence. That domain can be the original sender or the forwarding service after SRS rewriting. For messages with a null envelope sender, including many bounces, SPF uses the SMTP HELO/EHLO domain instead. This exception is defined in SPF's MAIL FROM rules.
- Envelope domain: this is the domain SPF evaluates.
- Header From: this is what users usually see in the mailbox UI.
- DKIM domain: this can still pass if forwarding did not alter signed content.
How to identify the server that rejected the email
A Gmail-branded delivery failure does not always mean the final Gmail mailbox made the SPF decision. Gmail can send the delivery status notice because a Google-hosted sender tried to send the message. The actual rejection can come from the receiving domain's MX, the forwarding service, or Gmail after the forwarder relays the mail onward.
|
|
|
|---|---|---|
Remote-MTA | Remote delivery host | Identify the hop reported in the failure |
Diagnostic-Code | SMTP reply | Read the exact rejection text |
Received | Route taken | Trace each handoff |
Authentication-Results | Recorded authentication results | Confirm the receiver and domain checked |
Use these fields to separate the reporter from the rejecting system.
For the broader authentication path, the related forwarding and DMARC explanation covers the domain-matching rules that let a surviving DKIM signature satisfy DMARC.
Delivery status cluestext
Reporting-MTA: dns; mail.google.com Final-Recipient: rfc822; user@forwarder.example Action: failed Status: 5.7.1 Remote-MTA: dns; mx2.forwarder.example Diagnostic-Code: smtp; 550 5.7.1 SPF verification failed
Reporter
The reporter is the system that sends the bounce notice to the sender. Gmail often has this role when the original sender uses Google-hosted mail.
- Visible clue: the message comes from a mail delivery subsystem.
- Risk: people assume the reporter made every policy decision.
Rejecting host
The rejecting host is the system that returned the SMTP error. That host's logs usually answer the question.
- Visible clue: look for Remote-MTA and the diagnostic code.
- Action: ask that provider for the SMTP transcript and SPF domain checked.
Common SPF failure causes after forwarding
Sort forwarded Gmail problems by the domain Gmail evaluated and the IP that connected at that moment. Without those two facts, the cause cannot be confirmed.
- No SRS: the forwarder sends to Gmail with the original envelope sender still intact.
- Bad SRS authorization: the envelope sender is rewritten, but the forwarder sends from an IP missing from its own SPF record.
- Hard fail: the checked SPF record ends in -all, so an unauthorized IP produces an SPF fail result.
- IP mismatch: the record authorizes the wrong address family or omits the actual outbound range.
- Missing SPF record: the envelope sender domain has no SPF record, producing none rather than fail. Check the rewritten domain when SRS is enabled.
- Multiple SPF records: the domain publishes more than one v=spf1 record, which causes a permanent error instead of combining the records.
- Lookup limit: the SPF evaluation exceeds 10 DNS-querying mechanisms or modifiers, including evaluated nested includes, and returns permerror. The ip4, ip6 and all mechanisms do not count toward this limit.
- Temporary DNS error: a DNS timeout or transient resolver failure returns temperror and should be separated from a permanent record defect.
- DKIM damage: this does not cause the SPF result, but it removes the main DMARC fallback when forwarding changes the SPF identity.
Before changing DNS, check that the domain publishes one valid SPF record with Suped's SPF checker. Then compare that record against the actual connecting IP in the headers or provider logs.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
A pass in one header does not prove every hop passed. A bounce can contain the headers of the bounce message itself, the original message, or both. For an SMTP rejection, use the rejecting receiver's reply and the forwarder's logs; a rejected message has no delivered Gmail copy to inspect. After a DNS fix, cached records remain visible until their TTL expires. Google advises allowing up to 48 hours for SPF changes in its SPF troubleshooting guidance.
|
|
|
|---|---|---|
No SRS | Original sender domain | Enable SRS |
Bad SRS authorization | Forwarder domain fails | Authorize the outbound IP |
Hard fail | fail with -all | Correct authorization |
Missing SPF record | none | Publish SPF for the checked domain |
Multiple records | permerror | Merge into one record |
DNS lookup limit | permerror | Remove stale or duplicate lookups |
Temporary DNS issue | temperror | Check DNS availability and retry |
Compact triage map for forwarded SPF failures.
How to check forwarded SPF results in Gmail
Start with the envelope sender and connecting IP for the failed delivery. For a delivered message in Gmail, open More, then Show original. Read the Authentication-Results header added by mx.google.com: smtp.mailfrom identifies the SPF sender domain, and Return-Path normally shows the envelope sender address. Use the relevant Received header to identify the connecting IP. If Gmail rejected the message during SMTP, use the bounce and forwarding logs instead.
- Find sender: identify the SMTP envelope sender in the delivery notice or provider logs.
- Find IP: identify the IP address that connected to the rejecting receiver.
- Check SPF: confirm whether that domain publishes one valid record and authorizes that IP.
- Check DKIM: confirm that a valid DKIM signature survives forwarding and that its signing domain matches the visible From domain under DMARC's rules.
- Check logs: ask the forwarding provider for the SPF domain, result, SRS status, and SMTP transcript.
- Retest the route: send a fresh message directly and through the same forwarding path, then compare Gmail's results after the DNS cache has expired.
Suped's domain health checker helps catch obvious DNS mistakes first. If the SPF record has too many includes, remove obsolete or duplicate mechanisms before using SPF flattening. Any flattened record needs automatic upkeep because provider IP ranges change.
Separate SPF records for a sender and its forwarderdns
; Direct mail sent only through Google Workspace sender.example. TXT "v=spf1 include:_spf.google.com ~all" ; Forwarder using an illustrative IPv4 address forwarder.example. TXT "v=spf1 ip4:203.0.113.25 -all"
Do not weaken SPF blindly
Changing -all to ~all changes the SPF result from fail to softfail for unmatched senders, but it does not authorize the forwarding server. Neither fail nor softfail satisfies DMARC through SPF. Fix SRS and the forwarder's sending IP authorization first, then preserve a valid DKIM signature with a signing domain that matches the visible From domain under DMARC's rules.
Gmail-specific forwarding practices
Gmail checks authentication again after forwarding. Google's forwarding recommendations are to rewrite and authenticate the envelope sender, preserve the original DKIM signature, and identify the forwarded route. These steps improve authentication handling without guaranteeing inbox delivery. See Google's forwarding recommendations.
- Rewrite the envelope sender: use SRS or an equivalent rewrite that references the forwarding domain and still routes bounces correctly.
- Authorize every forwarding IP: the rewritten domain's single SPF record must cover every server that can hand mail to Gmail.
- Preserve DKIM: avoid changing MIME boundaries, the subject, signed headers, or the encoded body after the original signature is added.
- Add forwarding headers: add X-Forwarded-For or X-Forwarded-To so the receiving system can recognize the forwarded path. These headers do not replace SPF or DKIM.
- Filter before forwarding: stop spam before relaying it because recipient complaints against forwarded spam can damage the forwarding identity's reputation.
- Separate the forwarding identity: use a dedicated domain or IP for forwarding when operationally practical, then monitor that identity separately.
Forwarding headers are supporting evidence
X-Forwarded-For and X-Forwarded-To describe the route, but Gmail still runs its own authentication checks. A forwarding header cannot turn an unauthorized connecting IP into an SPF pass.
Why SRS can pass SPF while DMARC still fails
An SPF pass for an SRS address authenticates forwarder.example, while the visible From address can remain user@sender.example. Those domains do not match for DMARC. SRS therefore fixes SPF at the forwarding hop without, by itself, producing a DMARC pass for the original sender. A surviving DKIM signature whose signing domain matches the From domain under DMARC's rules can supply that pass. These domain-matching requirements are defined in the DMARC specification.
Authenticated Received Chain (ARC) lets a forwarder record the authentication results it observed before relaying a message. Gmail considers that history alongside its own checks, as described in Google's authentication guidance. If the forwarder supports ARC, verify its recorded initial results and the chain that reaches Gmail. ARC does not turn the current SPF or DMARC result into a pass, and a valid chain alone does not guarantee delivery. Receiver trust and local policy determine how that evidence affects delivery under the ARC protocol.
A forwarder's DKIM signature has a different identity
Re-signing with d=forwarder.example authenticates the forwarder, but it does not satisfy DMARC for From: user@sender.example. Preserve the original valid DKIM signature. Do not add a recipient's independent forwarding service to the original sender's SPF record solely to mask forwarding failures, because that broadens authorization to send for the original domain.
Monitor forwarding failures with Suped
Suped's product combines DMARC reporting with SPF and DKIM checks for ongoing authentication monitoring. The hosted SPF workflow helps maintain the SPF record for a forwarding domain you control as outbound servers change. SRS must still be configured on the forwarding server.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
Suped's aggregate DMARC reports group reported traffic by source IP and authentication results. They can reveal patterns consistent with forwarding, but do not contain full message headers or SMTP transcripts. Compare source IPs and DKIM results with forwarding logs before attributing a failure to SRS. Reports cover receivers that send them, so missing traffic is not proof of successful delivery.
Manual DNS handling
- Visibility: headers, DNS lookups, and provider logs are reviewed in separate places.
- Updates: each sender change depends on manual DNS edits.
- Risk: lookup limits and stale includes can fail silently.
Suped workflow
- Visibility: DMARC, SPF, DKIM, alerts, and sender health are tracked together.
- Updates: hosted SPF lets teams manage senders without repeated DNS access.
- Risk: alerts flag authentication changes reported by participating receivers for investigation.
When Gmail delivers and still bounces
A confusing forwarded case can show both a delivered message and a bounce. That usually means there are two related transactions, not one clean accept or reject. A forwarded copy can land in the mailbox while a separate delivery attempt, alias path, or bounce path generates a failure notice.
This is also why the bounce can contain headers that belong to the bounce message rather than the original message. A null return path, a Mail Delivery Subsystem sender, Auto-Submitted headers, and delivery status fields point to a delivery status notice. Do not read those as if they are always the original message's authentication results.
The evidence that settles it
The forwarding provider's logs should show the original sender, the rewritten SRS sender, the IP used for the Gmail handoff, Gmail's reply, and whether the provider generated or relayed the rejection. Without that log line, the outside view is incomplete.
- Ask for: the SPF domain checked and the connecting IP.
- Ask for: the exact SMTP reply from Gmail or the forwarding MX.
- Ask for: confirmation that SRS was applied on the failed transaction.
Views from the trenches
Best practices
Keep SRS enabled on every forwarding path and verify the rewritten sender in headers.
Read Remote-MTA, Diagnostic-Code, and provider logs before changing any SPF DNS records.
Preserve original DKIM through forwarding so DMARC can pass for the visible From domain.
Common pitfalls
Assuming Gmail branding on a bounce means Gmail made the original SPF decision alone.
Reading the bounce message's headers as if they were the original message's authentication results.
Changing hard fail to softfail before confirming the envelope sender and connecting IP.
Expert tips
Ask the forwarder for the SPF domain, connecting IP, SRS sender, and exact SMTP response.
Treat simultaneous delivery and bounce as evidence of separate transactions to trace in logs.
Use DMARC reports with forwarding logs to separate forwarding failures from DNS defects.
Expert view
Expert from Email Geeks says the phrase "the domain" usually means the SPF domain in the SMTP envelope sender, not the visible From address.
2025-05-29 - Email Geeks
Expert view
Expert from Email Geeks says a Gmail delivery notice can report a rejection that came from the receiving MX or forwarding service.
2025-05-29 - Email Geeks
Frequently asked questions
Yes. Gmail performs its own SPF check against the domain in the SMTP envelope sender and the IP that connects to Gmail. An earlier SPF pass does not automatically carry over after the forwarding hop.
No. SRS fixes the envelope sender problem, but the rewritten domain still needs one valid SPF record that authorizes the forwarding server's actual sending IP. That SPF pass does not, by itself, satisfy DMARC for the original From domain.
Gmail can report the failure while another host made the rejection. Read Remote-MTA and Diagnostic-Code to identify the system that returned the SMTP error.
Yes, if the DKIM signature survives forwarding and its signing domain matches the visible From domain under DMARC's rules. Avoid modifying signed headers, MIME boundaries, or the encoded body.
Changing -all to ~all is not a forwarding repair. It changes fail to softfail for an unauthorized IP, but neither result is an SPF pass or satisfies DMARC through SPF. Fix the forwarding path first.
Permerror means the SPF record cannot be evaluated correctly, often because of multiple records, invalid syntax, or too many DNS lookups. Temperror means a transient DNS problem interrupted the check and should be investigated separately.
