Configure Sophos Email Gateway with Google Workspace

With a gateway integration, inbound mail follows Internet → Sophos Gateway → Google Workspace, while outbound mail follows Google Workspace → Sophos Gateway → Internet. For a safe migration, configure and test every destination, gateway, and internal route before changing the production MX records. This keeps a known delivery path and rollback route available at every stage.

Quick path: verify the domain in Sophos Fusion (formerly Sophos Central), prepare the separate Google delivery host, add the mailboxes, restrict the Google Inbound Gateway to the regional Sophos IP addresses, and route internal messages directly to Google. Then enter the Outbound Relay Host shown in Sophos Fusion as Google’s outbound gateway. Only after testing both directions should you change the primary MX records to the values shown for your Sophos region.

Scope and prerequisites

This guide covers Sophos Email in Gateway mode with Google Workspace. You need administrative access to Sophos Fusion, the Google Admin console, and the mail domain’s DNS. The domain must be configured in Sophos Gateway, and every recipient to be protected must exist in Sophos Email.

Record the following data in a change worksheet before starting:

mail domain and affected Google Workspace organizational unit;
current production MX set, including priorities and TTL;
current SPF record and existing DKIM and DMARC configuration;
MX, Delivery IP, relay, and SPF values displayed in Sophos Fusion for your data region;
current MX destinations specified by Google for your tenant;
one external and one internal test sender, plus one internal and one external recipient;
intended TLS requirements and a maintenance or rollback window.

Do not copy regional hosts or IP addresses from examples or old tickets. Copy them from Sophos Fusion immediately before the change. Also verify the Google destination values against current Google documentation or the tenant display.

Product boundary: Google Post Delivery Protection and Google Directory synchronization neither change nor replace this SMTP routing design. They are separate tasks and are out of scope here.

Prepare the change safely

Document the current mail flow with one inbound and one outbound test message. Save the headers and Google trace, and confirm that the messages don’t yet appear in Sophos Message History.
Lower the DNS TTL of the production MX records to an operationally appropriate value well ahead of the change. Record the old MX set and all existing Google routing rules as the rollback state.
Check whether another secure email gateway, Google Outbound Gateway, or catch-all routing rule is already active. Don’t apply overlapping rules to the same messages in parallel.
Use a small pilot scope or a planned test window. Enable safeguards such as Reject all mail not from gateway IPs only after all regional Sophos Delivery IPs are present and the internal Google paths have been tested.

The most important loop prevention measure is an unambiguous separation of destinations: the primary MX will point to Sophos, while the delivery destination stored in Sophos points to a separate Google destination and never back to the Sophos MX. Google’s outbound route points to Sophos, but must not be reapplied to inbound messages already delivered by Sophos.

Configure inbound mail flow

Prepare the domain and Google delivery destination in Sophos

In Sophos Fusion, open Global Settings > Products and Services > Email > Gateway Domains, then select or add the domain.
For the Delivery Destination, use a separate MX name under your domain, for example routing-mx.example.com, and enter the SMTP port documented by Sophos. This name is a dedicated DNS delivery path for Sophos, not the production MX of the primary domain.
Start Verify Domain Ownership, publish the TXT value shown for this domain unchanged in DNS, and verify again after propagation.
Create MX records for routing-mx.example.com that point to the current Google destinations specified for your Google Workspace tenant. These records must not point to Sophos.
Add every protected mailbox or recipient to Sophos Email and save the domain configuration.

Verification succeeds when Sophos Fusion shows the domain as verified and a DNS query for routing-mx.example.com returns only the intended Google destinations.

If delivery through ASPMX.L.GOOGLE.COM has problems, change only the Google delivery destination behind routing-mx.example.com to SMTP.GOOGLE.COM. This is a conditional Sophos-to-Google delivery alternative, not a universal default and not a change to the primary domain’s production MX, which continues to point to Sophos. Confirm the values valid for your Google Workspace environment before the change, then retest inbound mail flow. If that test also fails, restore the previously documented Google delivery destination and contact Sophos Support.

Secure the Google Inbound Gateway

In the Google Admin console, open Apps > Google Workspace > Gmail > Spam, Phishing and Malware > Inbound gateway for the affected top-level organization.
Enable the Inbound Gateway and add only the Delivery IPs listed in Sophos Fusion for your region.
Enable Automatically detect external IP and the agreed TLS requirement.
Enable Reject all mail not from gateway IPs only after a pilot test. This option blocks direct delivery and therefore prevents bypassing Sophos, but an incomplete IP list can also stop legitimate mail.
Save and allow up to 24 hours for the inbound setting to take effect.

If Google’s own delivery paths are blocked by the strict gateway restriction, temporarily turn off rejection, restore mail flow, and establish the current required Google and Sophos addresses from vendor guidance. Don’t broadly allow unknown networks.

Sophos reports a DMARC anomaly from its own testing: when Time of Click URL Protection or end-user message settings are enabled, Google sometimes marks inbound messages as DMARC failures even though Google’s documentation says DMARC authentication is bypassed for incoming messages from listed gateway hosts and the inbound gateway should perform the check. Sophos says it has raised this discrepancy with Google. Account for it before treating a reported failure as evidence that Automatically detect external IP or the Delivery IP list is wrong.

Route internal messages directly to Google

Internal messages should not travel through the production MX to Sophos and then back to Google. In Apps > Google Workspace > Gmail > Hosts, create a route using the current Google destinations for the tenant. In Apps > Google Workspace > Gmail > Routing, apply that route only to Internal - Sending and restrict it to your domain with an envelope sender filter. Enable TLS and CA-signed certificate validation as specified by Google and Sophos.

Make the internal route and the outbound gateway rule non-overlapping by scope and matching conditions. Save the routing change and allow up to 24 hours for it to take effect; you can track changes in the Google Workspace Admin audit log. Don’t begin internal-message or pilot validation, or cut over the production MX, until the change is effective. Then send an internal message to a recipient in the same domain: it must remain in Google and must not additionally appear as both an inbound and outbound scan in Sophos.

Configure outbound mail flow

Open the domain in Gateway Domains and select Inbound and Outbound under Configure Domain.
Select Google Apps Gmail as Outbound Gateway, save, then copy the Outbound Relay Host shown for this tenant under Configure External Dependencies > Outbound Settings. This label represents Google Workspace in Sophos Fusion.
Open the outbound gateway configuration for the affected top-level organization in the Google Admin console and enter exactly that relay host. The current Google interface may arrange the routing section differently; don’t derive hostnames from examples.
Give the rule sender and message criteria that do not overlap with the internal route. Disable or remove a second catch-all or gateway rule from the same scope.
Save, allow several minutes for the outbound setting to take effect, and first send from a pilot sender to an external test address.

Keep SPF and DKIM aligned with the actual sending path

The SPF record must cover every path that actually sends authorized mail, but shouldn’t retain unused paths. During a controlled transition, both Google Workspace and Sophos can be authorized. Once outbound mail flows exclusively through Sophos, remove the obsolete direct Google sending path only if no application, forwarding service, or third-party platform still uses it.

Take the regional Sophos SPF include value from Sophos Fusion; an example value would be unsafe here. Before saving, confirm that the domain still has exactly one SPF TXT record and that the chosen -all or ~all strategy fits the migration. Keep DKIM signatures and DMARC active separately and verify them on a message received externally after the change.

Validate the pilot, then change the production MX

Before the production MX cutover, use the pilot scope or planned test window to validate outbound delivery through Sophos and an internal-to-internal message that remains in Google. Confirm the expected headers, Google trace, and Sophos Message History, and verify that the prepared SPF record covers the pilot’s actual sending path.

Only after the delivery destination, recipients, Inbound Gateway, internal route, outbound gateway, SPF preparation, and pilot checks work should you replace the primary domain’s production MX set with the MX values and priorities shown in Sophos Fusion for your region. Keep the previous state, owner, and rollback decision documented during DNS propagation. If delivery fails, restore the saved MX set instead of adding more untested routes.

Validate both directions

After every change, allow for propagation, then perform four focused tests:

external → protected internal recipient;
internal user → external recipient;
internal user → internal user in the same domain;
direct delivery attempt that bypasses Sophos, provided this test is authorized and can be performed safely.

For tests 1 and 2, exactly one matching record with the correct direction, sender, recipient, time, and result must appear in Sophos Fusion under Reports > Message History. In parallel, inspect the Google trace and the delivered message’s full headers. The Received chain must show the expected path in the correct order; check SPF, DKIM, and DMARC at the external destination for the expected result.

Test 3 must not pass through Sophos twice unnecessarily. Test 4 must be rejected after the strict Inbound Gateway restriction is enabled. Multiple Sophos records for the same Message-ID, repeated hosts in the Received chain, or sharply increasing delivery times indicate duplicate processing or a loop.

Troubleshoot systematically

External inbound mail is missing: Check the production MX and its region first, then Sophos Message History. If there is no record, the fault is upstream of Sophos. If there is a record but no Google delivery, check routing-mx.example.com, the Google destinations, recipient inventory, Delivery IP restriction, and TLS.
Outbound mail is missing from Sophos: Check the scope and matching conditions of the Google rules and the configured Outbound Relay Host. If it appears in Sophos but not at the destination, inspect the delivery status, SPF/DKIM/DMARC, and the destination system’s error.
Internal mail appears twice in Sophos: Confirm that Internal - Sending matches only your domain and that no general rule matches the same messages. Remove overlapping outbound or catch-all rules instead of adding another bypass.
TLS error: Compare source and destination host, certificate name, CA trust, and the TLS option required on both sides. Don’t disable the requirement permanently; relax it for a test only after a documented risk decision, then restore it.
Mail cycles between Google and Sophos: Stop the change. Compare the primary MX, routing-mx.example.com, Google outbound route, and header hops side by side. The Sophos delivery destination must be Google, not Sophos; the Google outbound rule must not recapture mail delivered inbound by Sophos.
Only individual recipients fail: Check that the recipient exists and is spelled identically in Sophos Email and Google Workspace, including alias and group resolution. Don’t work around domain or recipient errors with broad relay permission.

If DNS, route scope, hosts, domain matching, TLS, and recipient inventory are correct but the documented error remains reproducible, give Sophos Support the Message-ID, timestamp, sender, recipient, relevant headers, and records from Sophos Message History and the Google trace. This allows the affected hop to be investigated without changing more production rules on suspicion.