Fix: “Inbound Gateway” SPF Overrides

When an organization routes its incoming email through an external security gateway (such as Proofpoint, Mimecast, Barracuda, or an on-premises mail hygiene appliance) before delivering it to Google Workspace, incoming messages frequently fail SPF or land in the spam folder. Because Google receives the message directly from your gateway’s IP address rather than the original sender’s server, Gmail evaluates SPF against your security gateway. Configuring an Inbound Gateway override in the Google Admin Console fixes this by instructing Gmail to inspect the true external IP address.

Quick Answer

When email routes through an intermediate security filter, Gmail evaluates the filter’s IP instead of the sender’s IP, breaking SPF. To fix this, navigate to Google Admin Console > Gmail > Inbound gateway. Enter your security gateway’s IP ranges and check “Automatically detect external IP” to evaluate SPF against the original sender.

---

Why Third-Party Gateways Break SPF in Gmail

Under standard email flow, an external sender connects directly to Google Workspace:

External Sender (198.51.100.10) ──► Google MX Server
Gmail evaluates SPF: Does 198.51.100.10 match sender's SPF record? ──► PASS

However, when an organization uses an email security gateway for specialized inbound filtering or archiving, the path changes:

External Sender (198.51.100.10) ──► Security Gateway (203.0.113.50) ──► Google MX Server

When Google receives this message:

1. Google sees the connection originating from 203.0.113.50 (your security gateway).
2. Google checks the external sender’s SPF record to see if 203.0.113.50 is listed.
3. Because the external sender has no knowledge of your private security gateway, the check fails.
4. Gmail assigns an SPF Softfail or Fail, raising the spam score or triggering safety warnings on legitimate inbound mail; see Gmail “Safety Warning” for Spoofed Emails.

[Incoming Email Flow with Intermediate Gateway]

External Sender (198.51.100.10)
        │
        ▼
Third-Party Gateway (203.0.113.50)  <── Appends Received: header
        │
        ▼
Google Workspace MX Server
        │
        ├─► [WITHOUT Inbound Gateway Configured]:
        │   Evaluates connecting IP (203.0.113.50) against sender's SPF.
        │   RESULT: SPF FAIL / SOFTFAIL (False Positive Spam)
        │
        └─► [WITH Inbound Gateway Configured]:
            Skips trusted gateway IP (203.0.113.50).
            Extracts original sender IP (198.51.100.10) from headers.
            RESULT: SPF PASS (Accurate Authentication)

---

What the Inbound Gateway Setting Does

The Inbound Gateway configuration in Google Workspace tells Gmail’s mail processing pipeline:

1. Trusted Proxies: Explicitly identifies your gateway’s IP addresses as internal transport hops rather than the originating sender.
2. External IP Extraction: Tells Gmail to look past the gateway’s Received: header line and extract the original public IP address from the preceding hop.
3. Accurate SPF Evaluation: Evaluates SPF, DKIM, and DMARC using the original sender’s IP address rather than your gateway’s infrastructure.
4. Access Control: Optionally blocks any inbound email that attempts to bypass your gateway by connecting directly to Google Workspace MX servers.

---

Diagnostic Steps: Spotting the Gateway Mismatch

To confirm that an intermediate gateway is corrupting your inbound SPF checks:

1. Open a misclassified email in Gmail and view the raw headers using How to Read Gmail “Original Message” Headers.
2. Find the Authentication-Results header stamped by mx.google.com.
3. Check the client-ip value reported in the SPF evaluation: Authentication-Results: mx.google.com; spf=softfail (google.com: domain of client@external.com does not designate 203.0.113.50 as permitted sender) client-ip=203.0.113.50;
4. If the client-ip matches your Mimecast, Proofpoint, or Barracuda relay IP instead of the sender’s server, your Inbound Gateway rule is missing or misconfigured.

---

Step-by-Step Configuration in Google Admin Console

Follow these steps to establish the correct gateway overrides:

Step 1: Gather Gateway IP Addresses

Collect the complete list of public outbound IP addresses or CIDR blocks used by your security vendor to deliver mail to Google Workspace. (For example, Proofpoint provides specific /24 or /28 blocks in their setup documentation).

Step 2: Configure the Gateway in Google Admin

1. Sign in to the Google Admin Console using an administrator account.
2. Navigate to Apps > Google Workspace > Gmail > Spam, phishing, and malware.
3. Scroll down to the Inbound gateway setting and click Configure (or Edit).
4. Enter a descriptive name (e.g., Proofpoint Inbound Relays).
5. Under Gateway IPs, click Add and enter each IP address or CIDR range.

Step 3: Configure IP Detection and Security Options

• Automatically detect external IP (recommended): Check this box. This is the core setting that instructs Google to bypass the gateway hop and extract the true sender IP from the headers.
• Reject all mail not from gateway IPs: Leave unchecked initially. Only check this box after verifying that mail flows seamlessly and direct MX delivery is no longer required.
• Require TLS connections from the email gateways: Check this box to ensure your gateway encrypts traffic between its servers and Google Workspace.

[Inbound Gateway Configuration Checklist]
[X] Gateway IP Addresses Added (e.g., 203.0.113.0/24)
[X] "Automatically detect external IP" enabled
[X] "Require TLS connections" enabled
[ ] "Reject all mail not from gateway IPs" (Enable only after testing)

1. Click Save in the bottom-right corner.

---

Verification: Testing the Override

After saving the configuration, wait up to 30 minutes for Google Workspace settings to apply across all clusters.

1. Send an external test email through your security gateway to a Google Workspace user.
2. Open the email in Gmail and inspect the headers via Show original.
3. Locate the Authentication-Results header.
4. Verify that:
   • The client-ip listed under spf= matches the true external sender’s IP, not your gateway’s IP.
   • The SPF status reflects pass (assuming the external sender publishes a valid SPF record).
   • DMARC evaluates correctly without false policy rejections; see How to Resolve DMARC Policy Rejects: Reject vs. Quarantine.

If inbound messages still fail validation after applying these settings, verify that your gateway is not stripping or re-ordering the incoming Received: headers during transit. For a complete review of domain-level mail flow and security health, consult The Workspace Email Authentication Master Checklist.