Skip to content
iBlockSpam
Platform setup

Spam filter for Google Workspace: an MX gateway in front of Gmail

Point your MX to iBlockSpam, then tell Gmail that the filtering service is your inbound gateway so it judges the real sender, not the gateway's IP address.

This page shows how to place iBlockSpam in front of Gmail for a Google Workspace domain. Internet mail goes to the filtering service first, and clean mail is delivered to Google. The key Google setting is Inbound gateway, documented in Google Workspace Admin Help: Set up an inbound mail gateway.

Placeholders used below:

  • <GATEWAY-MX-HOSTS>: the MX hostnames for your domain.
  • <GATEWAY-IP-RANGES>: the public IP ranges the filtering service uses to deliver mail to Google.

The iBlockSpam setup wizard shows your exact values, a before/after DNS comparison and the rollback steps. Copy values from the wizard, not from examples.

Prerequisites

  • A Google Workspace super administrator, or an admin role with the Gmail Settings privilege.
  • Access to your DNS host.
  • Your current Google MX value. Current setups use smtp.google.com; older domains may use the ASPMX.L.GOOGLE.COM set. iBlockSpam delivers clean mail to this host.
  • A list of systems that send mail straight to Google for your domain (for example, a CRM or website that delivers to Gmail's MX). These are affected if you choose to reject non-gateway mail.

Step by step

These are the iBlockSpam-specific steps. The general walkthrough of the Inbound gateway setting, for any filtering service, is in our Google Workspace inbound gateway guide.

  1. Add your domain in iBlockSpam. Enter the domain and set Google's MX host as the delivery destination. The wizard checks that it can deliver.

  2. Lower the MX TTL. Set the TTL on your current MX records to 300 seconds at least one full old-TTL period before the cutover.

  3. Open the Inbound gateway setting. In the Google Admin console, go to Menu > Apps > Google Workspace > Gmail > Spam, Phishing and Malware. Select your top-level organizational unit on the left, scroll to Inbound gateway, and click Edit (or Configure).

  4. Add the gateway IPs. Under Gateway IPs, click Add and enter each range from <GATEWAY-IP-RANGES>. Google accepts public IPs only. If mail passes through more than one gateway, list all of them.

  5. Select "Automatically detect external IP". With this on, Gmail finds the first public IP in the Received headers that is not in your gateway list and uses it for SPF. Without it, Gmail looks only one hop back, which is the gateway itself. We recommend turning it on.

  6. Leave the rejection option off for now. Reject all mail not from gateway IPs blocks direct delivery to Google. Turn it on in step 10, after MX has moved.

  7. Select the Require TLS for connections option. Gmail then rejects gateway connections that do not use TLS. The filtering service delivers over TLS.

  8. Leave Message tagging and "Disable Gmail spam evaluation" off. iBlockSpam quarantines spam before delivery, so Gmail does not need a header regexp. Keeping Gmail's own evaluation adds a second layer; our guide to Gmail spam settings in Google Workspace shows how to tune it.

  9. Save, then change MX. Click Save. Allow time for the setting to apply (Google says up to 24 hours, usually sooner). Then replace Google's MX records with <GATEWAY-MX-HOSTS>. Do not keep Google's MX as a backup: senders may use any listed MX (RFC 5321, section 5.1).

  10. Turn on "Reject all mail not from gateway IPs". After the old MX TTL has expired and test mail arrives through iBlockSpam, return to Inbound gateway and select this option. Direct deliveries to Google for your domain are then rejected, which closes the bypass route.

How to verify

Send a message from an outside account, open it in Gmail and choose More > Show original. Or paste the headers into the Email Header Analyzer, which runs in your browser.

  • Received lines: the hop just before Google should be the filtering service.
  • Received-SPF and Authentication-Results: SPF should name the original sender's IP, not a gateway IP. If you see a gateway IP, check that Automatically detect external IP is on and that all gateway ranges are listed.
  • ARC-Authentication-Results: may also be present; it records authentication results along the path.

Then test the lockdown: from a server that is not the gateway, connect to Google's MX and send a message to a user in your domain. It should be rejected.

Use the MX Lookup tool to confirm the public MX records and the Email Health Check for an overview.

Rollback

  1. In Inbound gateway, clear Reject all mail not from gateway IPs and save. Do this first, or mail arriving directly after the MX change will be refused.
  2. Change MX back to Google's value with a short TTL.
  3. Keep the iBlockSpam domain active until the old TTL expires so in-flight mail is still delivered.
  4. Remove the gateway IPs from Inbound gateway once no mail arrives through the filtering service.

Common mistakes

  • Changing MX before saving the gateway setting. Messages are judged against the gateway's IP until the setting applies, which can cause SPF failures and spam misclassification.
  • Missing IP ranges. Every range the filtering service delivers from must be listed. The wizard shows the complete list.
  • Turning on rejection too early. Mail still routed straight to Google is refused while DNS caches expire.
  • Configuring a child organizational unit. Set the gateway at the top-level organization so it covers every user.
  • Assuming DMARC is enforced by Gmail. It is not for gateway mail. Keep iBlockSpam's spoofing protection on, and use approved-sender lists with sender verification for trusted partners.
  • Forgetting internal senders. Apps that used Google's MX directly need another route once rejection is on, such as Google's SMTP relay service or iBlockSpam.

What changes for your users

Very little. Users keep signing in to Gmail as before, and sending is unchanged, so your SPF record does not need an iBlockSpam entry unless you use the outbound relay. If you want to confirm Google's own entry, our Google Workspace SPF record page shows the exact include. The visible change is that spam is held in iBlockSpam's quarantine instead of Gmail's Spam folder. Each user gets a personal quarantine with scheduled digest emails (hourly, daily, a chosen weekday or custom) and can review it from the digest. Admins see a domain-wide shared quarantine. Gmail's Spam folder still catches anything Google's second layer flags.

Limits

  • Each domain includes 100,000 inbound messages per month and accepts messages up to 400 MB. Gmail has its own message size limit, and the smaller limit applies.
  • Unlimited mailboxes means any number of mailboxes per domain, not unlimited message volume.
  • If Google is unreachable, mail is spooled for up to 5 days. Message history is kept for 30 days.
  • An MX lookup can't prove mail is filtered. Header checks and the direct-delivery test are the evidence.

Do you need a gateway?

Gmail's built-in filtering is strong, and some domains don't need anything in front of it. Read Google Workspace built-in protection vs a gateway for an honest comparison. Stuck on a step? Our support page lists what to send so we can trace mail quickly.

Frequently asked questions

Why do I need the Inbound gateway setting at all?

Without it, Gmail sees every message as coming from the filtering service's IP addresses. SPF checks then run against the wrong IP, and Gmail's spam and phishing signals lose accuracy. The Inbound gateway setting tells Gmail which IPs to look past.

Does Gmail still enforce DMARC on mail from the gateway?

No. Google states that Gmail does not enforce the sender's DMARC policy for messages that arrive from the inbound gateway, though it still uses authentication results for compliance and spam evaluation. iBlockSpam's spoofing protection runs before delivery to cover that gap.

Should I turn on 'Disable Gmail spam evaluation on mail from this gateway'?

Usually not. Leaving Gmail's own spam evaluation on gives you a second layer. iBlockSpam quarantines spam before delivery, so you don't need a header-based spam rule in Gmail.

Which Google edition do I need?

The Inbound gateway setting lives under Gmail's Spam, Phishing and Malware settings in the Admin console and needs an administrator with the Gmail Settings privilege. Check that your edition shows the setting before you change MX.

How long do Admin console changes take?

Google says Gmail setting changes can take up to 24 hours, though they usually apply sooner. Make the gateway change first, then change MX.

Last updated:

See how your domain is set up today.

A free check of your MX, SPF, DKIM and DMARC records. When you're ready to protect it, create your account.

Free, reads public DNS only. Protect your domain