The Limitations of Native Filtering
Google Workspace includes one of the most sophisticated, machine-learning-driven spam and malware filters on the planet. For 99% of businesses, Gmail’s native filtering is more than sufficient.
However, highly regulated enterprises (such as financial institutions or government contractors) often require dedicated, third-party security appliances (like Proofpoint, Mimecast, or Barracuda). These platforms provide extreme granular control over threat intelligence, advanced URL rewriting, and strict data loss prevention analytics that Google’s native interface does not expose.
Integrating a third-party filter creates a massive architectural challenge. You must point your public MX (Mail Exchange) records to the third-party filter so it receives the email first. The filter scans the email, and if it is clean, forwards it to Google Workspace. The vulnerability is that an attacker can look up Google’s direct server IP addresses and send malware directly to Gmail, bypassing your expensive Proofpoint filter entirely. To seal this loophole, administrators must configure a Gmail Inbound Gateway.
Step 1: The Architectural Flow
Before touching the Google Admin console, you must alter the flow of the internet.
- Log into your public DNS provider (e.g., Cloudflare, Route 53).
- Delete your existing Google MX records (e.g.,
ASPMX.L.GOOGLE.COM). - Create new MX records pointing to your third-party security provider (e.g.,
mxa-00123.mail.proofpoint.com).
Now, all emails originating from the internet hit Proofpoint first. Proofpoint is configured with a “delivery route” that points the cleansed emails back to ASPMX.L.GOOGLE.COM.
Step 2: Configuring the Inbound Gateway
Right now, your Google Workspace is receiving emails from Proofpoint, but it is also still accepting emails directly from anyone else on the internet who knows the IP address. You must lock this down.
- Log into the Google Workspace Admin Console (admin.google.com).
- Navigate to Apps > Google Workspace > Gmail > Spam, Phishing and Malware.
- Locate the setting named Inbound gateway and click configure.
This is where you define the security perimeter.
Step 3: Whitelisting the Gateway IP Addresses
In the Inbound Gateway configuration window, under Gateway IPs, you must input the exact, specific IP address ranges (CIDR blocks) owned by your third-party provider (e.g., Proofpoint or Mimecast).
You must obtain this official IP list from your vendor’s documentation. By entering these IPs, you are telling Google: “These are the only servers on earth allowed to act as an authorized proxy for my domain.”
Step 4: Locking Down Direct Delivery (Reject all other traffic)
Defining the Gateway IPs is not enough. You must explicitly tell Google to reject traffic from anyone else.
Scroll down in the Inbound Gateway settings and check the box labeled: Reject all mail not from gateway IPs.
This is the most critical step in the entire architecture. If a Russian botnet attempts to bypass your Proofpoint appliance and connects directly to ASPMX.L.GOOGLE.COM to deliver a phishing payload, Google will instantly drop the connection with a 550 fatal error, because the botnet’s IP address is not in the trusted Gateway list.
Step 5: Bypassing Google’s Native Spam Filters
Because Proofpoint or Mimecast has already spent immense CPU power scanning the email for spam, executing malicious URLs in sandboxes, and analyzing attachments, there is absolutely no reason for Google to scan the email a second time.
In fact, double-scanning causes massive problems. If Proofpoint modifies the email header to add a “Cleaned by Proofpoint” tag, Google’s algorithms might interpret that modification as tampering, and falsely flag the legitimate email as spam, throwing it into the user’s junk folder.
To prevent this, you must configure Google to trust the gateway implicitly.
Still within the Inbound Gateway settings, ensure the following boxes are checked:
- Message Tagging:
Message is considered spam if the following header matches...(You can configure this if you want Proofpoint to tag spam, but let Google deliver it to the spam folder. If Proofpoint quarantines spam on its own servers, you leave this blank). - Check the box for: Disable Gmail spam evaluation on mail from this gateway; only use header value.
By checking this box, you effectively turn off Google’s native AI spam filtering for all inbound mail, relying 100% on your third-party appliance.
Step 6: Handling Internal Routing (Crucial Edge Case)
There is one dangerous edge case. What happens when the CEO ([email protected]) sends an email to the CFO ([email protected])?
By default, Google sees this as internal traffic and routes it instantly within the Google data center. The email never leaves Google, meaning it never hits your Proofpoint appliance for scanning. If the CEO’s laptop was compromised by an internal worm, the worm will spread laterally to the CFO.
To force internal emails to be scanned by the third-party gateway, you must create a separate Outbound Routing Rule in the Google Admin Console. You configure a routing policy that intercepts all internal email (from your domain to your domain) and forcefully routes it out to the Proofpoint SMTP relay. Proofpoint scans it, and then routes it back through the Inbound Gateway to the CFO.
Conclusion
Deploying an enterprise email security appliance requires more than just updating DNS records. Without explicitly locking down the Google Workspace perimeter using an Inbound Gateway, attackers will effortlessly bypass your multi-million-dollar security investment. By strictly defining Gateway IPs and disabling native spam evaluation, administrators ensure a mathematically secure, single-pane-of-glass mail flow architecture.