# How to set up a Google Workspace inbound gateway for a spam filter URL: https://iblockspam.com/blog/google-workspace-inbound-gateway-setup Last updated: 2026-10-09 Published: 2026-10-09 Topic: Setup guides Author: iBlockSpam Team > Configure Gmail's Inbound gateway for an MX-level spam filter: gateway IPs, external IP detection, direct-mail rejection, TLS, DMARC and rollback. ## Short answer In the Admin console, open Apps > Google Workspace > Gmail > Spam, Phishing and Malware > Inbound gateway. Add the filter's public IP ranges, turn on Automatically detect external IP and Require TLS, save, then change MX. Once mail flows through the filter, turn on Reject all mail not from gateway IPs to block direct delivery. Google Workspace supports a filtering service in front of Gmail through a setting called **Inbound gateway**. It tells Gmail which servers relay mail to it, so Gmail can look past them to the real sender. This guide explains each option, the order of operations, and the one behavior that surprises most admins: DMARC. ## What does the Inbound gateway setting do? With MX pointing to a filtering service, every message reaches Gmail from the filter's IPs. Gmail would normally treat those IPs as the sender for reputation and SPF ([RFC 7208](https://www.rfc-editor.org/rfc/rfc7208)). Listing them as gateway IPs tells Gmail to skip them when deciding where the message really came from ([Google Workspace Admin Help](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-an-inbound-mail-gateway)). ## What are the options, and what should you choose? | Option | What it does | Recommended | | --- | --- | --- | | Gateway IPs | Lists the public IPs or ranges that relay mail to Gmail. Private IPs aren't supported. | Required: every range your filter delivers from | | Automatically detect external IP | Gmail uses the first non-gateway public IP in `Received` headers for SPF. If none is found, the message is treated as internal. | On | | Reject all mail not from gateway IPs | Rejects mail that arrives from anywhere other than the gateway | On, after MX has moved | | Require TLS for connections | Rejects gateway connections that don't use TLS | On | | Message tagging (header regexp) | Gmail marks mail as spam if a header matches, or extracts a numeric score | Off when the filter quarantines spam before delivery | | Disable Gmail spam evaluation on mail from this gateway; only use header value | Gmail relies only on the header | Off, so Gmail stays a second layer | ## How do you set it up, step by step? You need a super administrator or an admin role with the **Gmail Settings** privilege. Placeholders `` and `` stand for your filter's values. 1. **Record your current MX** (often `smtp.google.com`, or the older `ASPMX.L.GOOGLE.COM` set) and lower its TTL to 300 seconds a day ahead. 2. **Set up the filter** with Google's MX host as the delivery destination, and send a test through it. 3. **Open the setting.** In the Admin console, go to **Menu > Apps > Google Workspace > Gmail > Spam, Phishing and Malware**. Select the **top-level** organizational unit on the left, so the setting covers everyone. 4. **Edit Inbound gateway.** Under **Gateway IPs**, click **Add** and enter each range in ``. 5. **Select Automatically detect external IP.** 6. **Select Require TLS for connections.** 7. **Leave Reject all mail not from gateway IPs unchecked** for now. 8. **Leave Message tagging and Disable Gmail spam evaluation unchecked.** 9. **Save.** Google says changes can take up to 24 hours, usually less. You can follow them in the Admin console audit log. 10. **Change MX** to `` in one edit. Don't keep Google's MX listed as a backup: senders may use any MX record listed ([RFC 5321, section 5.1](https://www.rfc-editor.org/rfc/rfc5321#section-5.1)). 11. **Test** from several outside providers once the old TTL has passed. 12. **Turn on Reject all mail not from gateway IPs** after you see mail arriving through the filter. This closes the route spammers use when they deliver straight to Google. ## Why doesn't Gmail enforce DMARC for gateway mail? Google's documentation says: "Gmail does not enforce the sender's DMARC policy for messages that arrive from the inbound gateway." It still uses authentication information for compliance evaluation and to help prevent spam and phishing ([Google Workspace Admin Help](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-an-inbound-mail-gateway)). The reason is practical. A gateway may alter messages (adding headers or banners), which can break DKIM signatures, and a relay changes the connecting IP. Enforcing `p=reject` after that would bounce legitimate mail. What this means for you: - DMARC enforcement for inbound mail now depends on your filter. Make sure its spoofing protection is on. - Approved-sender entries should require sender verification, so a forged From address can't use them. - Your own domain's DMARC record still matters for mail you send. DMARC is now specified in [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989), which replaced [RFC 7489](https://www.rfc-editor.org/rfc/rfc7489) in 2026; the `v=DMARC1` record format is unchanged. Check yours with the [DMARC Checker](https://iblockspam.com/tools/dmarc-checker). ## How does Gmail pick the IP it checks? It helps to picture the `Received` headers of a filtered message, newest at the top: ``` Received: from () by mx.google.com ... Received: from () by ... ``` With **Automatically detect external IP** on, Gmail walks down these lines, skips every IP in your **Gateway IPs** list, and uses the first public IP it finds (here, the sender's IP) for SPF. If every IP in the chain is a gateway IP or private, Gmail treats the message as internal and doesn't require SPF. With the option off, Gmail checks only one hop back, which is the gateway. That is why the IP list must be complete. If the filter delivers from a range you haven't listed, Gmail stops at that IP and evaluates SPF against the filter, not the sender. ## What about mail between your own users? Mail from one user to another in the same Workspace organization stays inside Google and doesn't touch MX, so it is not filtered by the gateway and isn't affected by **Reject all mail not from gateway IPs**. If you have several domains in separate Google organizations, each needs its own gateway setup. ## How do you verify the setup? Open a test message in Gmail and choose **More > Show original**, or paste the headers into the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer), which runs in your browser. - **Received:** the hop just before Google should be your filter. - **Received-SPF / Authentication-Results:** the IP named should be the original sender's, not a gateway IP. If it's a gateway IP, a range is missing or **Automatically detect external IP** is off. - **Direct-delivery test:** after step 12, deliver a message to Gmail's MX for your domain from a server that isn't the gateway. It should be rejected. Use the [MX Lookup](https://iblockspam.com/tools/mx-lookup) for the public records. An MX lookup can't prove mail is filtered; the headers and the direct test can. ## How do you roll back? 1. Clear **Reject all mail not from gateway IPs** and save. Do this first, or mail delivered straight to Google after the MX change is refused. 2. Point MX back to Google with a short TTL. 3. Keep the filter active until the old TTL has passed and its queue has drained. 4. Remove the gateway IPs once no mail arrives through the filter. ## What are the common mistakes and risks? - **Setting the gateway on a child OU.** Users outside that OU get no gateway treatment. - **Incomplete IP list.** Mail from an unlisted range is judged by the gateway's IP, and is rejected outright once rejection is on. - **Enabling rejection before MX propagates.** Mail still routed directly is refused. - **Turning off Gmail's spam evaluation.** You lose a free second layer for no benefit. Our guide to [Gmail spam settings in Google Workspace](https://iblockspam.com/blog/gmail-spam-settings-google-workspace) covers how to tune that layer instead. - **Apps delivering straight to Gmail.** Website forms, CRMs and scanners that used Gmail's MX need another route once rejection is on. - **Assuming DMARC is enforced.** It isn't for gateway mail. ## How iBlockSpam helps iBlockSpam filters mail before it reaches Gmail, including spoofing and phishing protection, which matters because Gmail does not enforce DMARC for gateway mail. The setup wizard shows the exact gateway IP ranges to paste into **Gateway IPs**, your MX change as a before/after comparison, and the rollback steps. Spam is held in a personal quarantine for each user with scheduled digests, so you don't need Gmail's header tagging. If Google is unreachable, mail is held for up to 5 days. The Google settings themselves are yours to apply in the Admin console. ## Next steps 1. Confirm the gateway IPs and **Automatically detect external IP** are saved, then wait for the old MX TTL to expire. 2. Send a test from outside and check its path with the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer) before you turn on rejection. 3. For the iBlockSpam-specific values, see the [Google Workspace platform page](https://iblockspam.com/platforms/google-workspace). The iBlockSpam [portal demo](https://iblockspam.com/demo) shows the setup checklist that confirms MX routing and outgoing authentication for a sample domain. See all [spam filter setup guides](https://iblockspam.com/blog/topic/setup). ## Frequently asked questions ### What happens if I skip the Inbound gateway setting? Gmail treats the filtering service as the sender of every message. SPF is evaluated against the gateway's IP, so legitimate mail can fail SPF and Gmail's reputation signals lose accuracy. Mail still flows, but classification suffers. ### Is DMARC enforced for mail that comes through the gateway? Not by Gmail. Google states that Gmail does not enforce the sender's DMARC policy for messages that arrive from the inbound gateway. It still uses authentication results for compliance and spam evaluation. Your filter's spoofing checks need to cover that. ### What does Automatically detect external IP do? It makes Gmail find the first public IP in the Received headers that isn't one of your gateway IPs, and use it for SPF. Without it, Gmail looks only one hop back, which is the gateway. ### Will Reject all mail not from gateway IPs block my apps? It blocks anything that delivers to Gmail's MX for your domain without passing through the gateway. Route those apps through Google's SMTP relay service, authenticated submission, or the filter instead. ## Sources - [Google Workspace Admin Help: Set up an inbound mail gateway](https://knowledge.workspace.google.com/admin/gmail/advanced/set-up-an-inbound-mail-gateway) - [RFC 5321: Simple Mail Transfer Protocol (section 5.1)](https://www.rfc-editor.org/rfc/rfc5321#section-5.1) - [RFC 7208: Sender Policy Framework (SPF)](https://www.rfc-editor.org/rfc/rfc7208) - [RFC 9989: DMARC (obsoletes RFC 7489)](https://www.rfc-editor.org/rfc/rfc9989) - [RFC 7489: DMARC (original specification)](https://www.rfc-editor.org/rfc/rfc7489) ## Free tools for this guide - [MX Lookup](https://iblockspam.com/tools/mx-lookup): See where your mail is delivered, spot unfiltered backup MX and broken hosts. - [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser. - [SPF Checker](https://iblockspam.com/tools/spf-checker): Count real DNS lookups, find PermErrors, loops and risky "all" settings. - [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject. --- Source: iBlockSpam, https://iblockspam.com/blog/google-workspace-inbound-gateway-setup (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt