Deliver Sophos Phish Threat securely in Google Workspace

Google Workspace can filter, rewrite, or classify simulated phishing messages as spam just as it does real attacks. For meaningful Sophos Phish Threat campaigns, you must therefore account for the documented sending IP addresses, sender domains, and the X-PT-TOKEN header. However, these exceptions must neither exempt all external senders nor be confused with the production integration of Sophos Email Gateway with Google Workspace.

Secure fast track: Record the current sending values and first assess the tenant-wide impact. Email allowlist and Inbound gateway are configured for the top-level organisation and cannot be limited to a pilot organisational unit. Initially, assign only the custom Spam rule with its Address list and the Content compliance rule to a small pilot organisational unit with test recipients. Then use a controlled campaign to test matching and non-matching cases inside and outside the pilot. Assign an owner, purpose, and review date to every exception.

Important: This configuration specifically disables Gmail protection controls for matching simulation messages. It does not protect a production mail domain, does not replace MX, SPF, DKIM, or DMARC configuration, and is not the Google Workspace integration for Sophos Email Gateway. Use only values from the current Sophos Phish Threat documentation and the campaign you actually launch.

Prerequisites and scope of changes

Required:

Administrator access to Sophos Fusion (formerly Sophos Central) and to Google Admin console;
a Sophos Phish Threat licence and an authorised campaign administrator;
a small pilot group with specially designated test recipients;
an approved change window and access to Email Log Search and the Phish Threat campaign results;
the ability to document existing Gmail settings before making changes;
one owner each for campaign, Google Workspace rules, and later cleanup.

Capture screenshots or exports of the affected settings in advance. Back up Email allowlist and Inbound gateway as the tenant-wide initial state of the top-level organisation, including all IPs, TLS, and Message Tagging options. Additionally, document the organisational unit and inheritance status for Spam and Content compliance. Do not change any shared address list whose other purposes are not fully known.

The currently documented Phish Threat sending IP addresses are:

54.240.51.52
54.240.51.53

Check both values again immediately before making the change in the Sophos information IP addresses and domains. Only if the tenant actually uses Sophos Mailflow, add the Mailflow IP addresses specified by Sophos for your own region. Do not allow these regional values indiscriminately for tenants without Mailflow, and do not copy anything from another tenant or an old ticket.

The Sophos information lists the values amazonses.com, ~eu-west-1.awstrack.me~, and ~sophos-phish-threat.go-vip.co~ literally as domains or URLs to allow. Only awstrack.me is explicitly described there as a click-tracking path. Document these source values unchanged and use the syntax of the respective target system when entering them; do not infer wildcard semantics or a technical role from the tildes. For the Gmail Address list, however, use only the sender domains from Sending domains and IPs or from the specific campaign details. URL values are not evidence of a sender domain.

First plan the change as a pilot

Set up a pilot organisational unit with a few test accounts for Spam and Content compliance, or select an existing unit designated for this purpose.
Document the inheritance and local state of these two rule types there.
Conduct an impact analysis for the tenant-wide changes on Email allowlist and Inbound gateway. In particular, record existing gateways, direct delivery paths, other systems on the same IPs, and the global rollback state.
Record campaign ID, sending period, expected sender domain, recipients, landing page, and current sending IP addresses.
Define a positive test, a similar but non-matching external sender, and a recipient outside the pilot organisational unit.
Agree on termination criteria: unexpected bypasses inside or outside the pilot, an overly broad exception, missing TLS, or unexplainable header or tracking results.

The four Google configurations below are part of the process documented by Sophos, but they have different scopes in Google and are not four independently effective layers of protection. Do not broaden the OU-scoped rules beyond what is necessary, and do not add unknown networks or domains merely to work around a failed test.

IP interaction: Google treats an IP in Inbound gateway as a gateway and looks in the Received: lines for the original public source IP. If the same IP also appears in Email allowlist, this allowlist entry therefore does not affect delivery or spam filtering. Nevertheless, Sophos mentions both steps. After setup, verify using Email Log Search and the complete Received: chain which source IP Google identifies and which rule actually applies. Do not infer double protection from the presence of both entries.

Add sending IP addresses to Email allowlist

Log in to Google Admin console.
Open Menu > Apps > Google Workspace > Gmail.
Select Spam, Phishing and Malware.
On the left, explicitly select the top-level organisation. The setting still always applies to the entire domain and cannot be limited to an organisational unit.
Open the edit icon at Email allowlist.
Enter only the currently confirmed Sophos Phish Threat sending IP addresses.
Save with Save.

Do not adopt CIDR networks when Sophos only specifies individual addresses. Existing entries will not be replaced until the purpose and owner are clarified. Record which two tenant-wide values were added by this change so that the global rollback does not accidentally remove someone else’s exceptions. Note the interaction described above when the same IPs are also registered as gateways.

Configure Inbound gateway for Phish Threat

Under Menu > Apps > Google Workspace > Gmail > Spam, Phishing and Malware, explicitly open the top organisation on the left and then the setting Inbound gateway. This configuration applies tenant-wide; there is no pilot OU override. Only activate it after impact analysis and backing up the complete global baseline configuration.

Under Gateway IPs:

Click on Add and add each confirmed Phish Threat IP address.
Activate Automatically detect external IP (recommended).
Deactivate Reject all mail not from gateway IPs. This Phish Threat configuration must not reject all other legitimate delivery paths of the tenant.
Activate Require TLS for connections from the email gateways listed above.

Under Message Tagging:

Select Message is considered spam if the following header regexp matches.
Enter an intentionally non-matching value under Regexp, for example 344jedjs=-0sdfee3.
Select Message is spam if regexp matches.
Activate Disable Gmail spam evaluation on mail from this gateway; only use header value.
Save with Save.

The regular expression is intentionally not a characteristic of a real message. Before saving, ensure that it does not appear in existing headers or in your own mail gateway tags. It must not be replaced by .*, an empty expression, or a generic company-wide identifier. The IP restriction and mandatory TLS are the essential limits of this gateway exception.

Create your own Address list for Sophos sender domains

Open Menu > Apps > Google Workspace > Gmail > Spam, Phishing and Malware.
Explicitly select the pilot organisational unit on the left. Users in subordinate units can inherit the setting; therefore, check their actual scope.
Click on Configure under Spam.
Name the setting clearly, for example Phish Threat bypass.
Select Bypass spam filters for messages from senders or domains in selected lists.
Open Create or edit list and click under Manage address lists on Add address list.
Create a list used exclusively for Sophos Phish Threat, for example Sophos Phish Threat.
Only enter the currently confirmed sender domains from Sophos or the specific campaign display; do not use URL values as the sender domain.
Turn off the authentication requirement for this documented Phish Threat list and save with Save.
Return to the Spam setting of the pilot organisational unit and select Use existing list.
Select Bypass spam filters and hide warnings for messages from senders or domains in selected lists, then again Use existing list and the list you just created.
Save with Save.

Turning off the authentication requirement is a narrowly defined manufacturer requirement for this simulation list, not a recommendation for general allow lists. Do not mix supplier, partner, or your own company domains in this list. If a campaign domain is dropped, exactly this entry will be removed.

Configure Content compliance with IP and token

Open Menu > Apps > Google Workspace > Gmail > Compliance.
Explicitly select the pilot organisational unit on the left and check which subordinate units inherit this setting.
Click on Configure under Content compliance.
Assign a unique name, for example Phish Threat content compliance.
Under Email messages to affect select the direction Inbound.
Click on Add under If any of the following match the message.
Select Metadata match.
Set Attribute to Source IP and Match type to Source IP is within the following range.
Enter a confirmed Phish Threat IP address and save the expression. Repeat this for each additional confirmed address.
Add another expression under If any of the following match the message.
Select Advanced content match, then Location > Full headers and Match type > Contains text.
Enter exactly X-PT-TOKEN under Content and save the expression.
Under If the above expressions match, select the action Bypass spam filter for this message at Spam.
Under Encryption (onward delivery only), select the action Require secure transport (TLS).
Save the entire rule with Save.

Security boundary: The documented Google rule uses If any of the following match the message. Either a matching source IP or the header name X-PT-TOKEN can trigger the action. Therefore, the header is not a cryptographic proof of origin. Limit the rule by pilot organisational unit, direction, and lifecycle; do not use X-PT-TOKEN in other bypass rules and verify in the non-matching test that normal external messages do not receive an exception. Do not change any arbitrarily to all, as this deviates from the documented Sophos process and can alter campaign delivery.

According to the UI, the option Require secure transport (TLS) in this section applies only to onward delivery. The inbound TLS requirement is configured separately in Inbound gateway; neither option replaces the other.

Validate the configuration under controlled conditions

Wait until the tenant-wide changes and the rules of the pilot organisational unit take effect. Then start a small, clearly named Phish Threat pilot campaign. Do not request real credentials and do not send uncontrolled messages to distribution lists used in production.

Perform at least these tests:

Matching pilot recipient: The simulation email is delivered to the inbox. Sender domain, recipient, time, and campaign ID match.
Origin and rule effect: The complete headers contain the expected Received: chain and X-PT-TOKEN. Email Log Search and headers are evaluated together to document the source IP determined by Google and the gateway, allowlist, spam, or compliance rule that actually applied.
Transport: Check inbound TLS in Email Log Search and/or in the relevant Received: entry or other transport evidence. The mere presence of complete headers is not proof that TLS was used. The compliance option Require secure transport (TLS) separately concerns onward delivery.
Sophos events: Sending, delivery, as well as a controlled click or a report appear only for the correct test user in the campaign.
Similar Non-Matching Sender: A normal external test email without a confirmed Sophos IP and without X-PT-TOKEN goes through the regular Gmail checks. It must not receive the bypass solely because of an overly broad domain or wildcard rule.
Recipients outside the pilot: The OU-limited Spam and Content compliance rules may not apply there. The tenant-wide Email allowlist and Inbound gateway effects, on the other hand, can also affect this recipient and must be evaluated separately based on Email Log Search and headers.
Inappropriate header content: The intentionally impossible value from Message Tagging must not classify normal messages as Phish Threat simulation.

A delivered message alone does not prove that the correct exception applied. For acceptance, retain the Message-ID, timestamp, full headers, Google log result, and Sophos campaign result as evidence. Do not document real passwords or confidential message content.

Troubleshoot systematically

The simulation does not arrive: First check the campaign status and recipient address, then Email Log Search. If there is no Google entry, compare the actually sending IP with the current Sophos list. If there is an entry, distinguish the tenant-wide gateway/allowlist state from the OU scope and the inheritance of the spam/compliance rules. Then check spam/quarantine action and TLS errors.
The message ends up in spam: Compare the source IP, visible or envelope sender domain, Address list, X-PT-TOKEN, and the scope of the Content compliance rule. Do not set up a broader domain bypass before the deviation is explained.
Gmail rejects the connection: Check both Gateway IPs, the effective rule, and Require TLS for connections from the email gateways listed above. Do not disable TLS permanently; escalate in case of a reproducible transport error with message ID, time, and SMTP result.
Legitimate mail is bypassed unexpectedly: Stop the pilot campaign. Use Email Log Search and full headers to check whether a tenant-wide gateway/allowlist change or an OU-limited spam/compliance rule has taken effect. Disable the identified new exception according to the documented reset plan. Then check whether the message contains X-PT-TOKEN, comes from a registered IP, or matches an overly broad sender domain.
Clicks missing despite delivery: Check whether browser extensions or web filters are blocking access to awstrack.me. Sophos uses this AWS tracking path for click events. Do not change the Gmail sender bypass if only web tracking is affected.
The campaign uses a different sender domain: Compare the sender value shown in Sending domains and IPs or in the campaign details with the dedicated Address list. Add only the documented sender scope; do not derive it from a URL or its tildes.
Google connection fails: Check the Project Creation Settings in the Google Admin console. This is a permission or Google Cloud setting and is not resolved by additional Gmail allow lists.
Tracking shows incorrect users or automatic clicks: First, check redirects, group recipients, pre-scanned link scanners, and headers. Do not expand the exception; automatic security checks can open links before the user.

If an error remains reproducible, provide Sophos Support with the campaign ID, Message-ID, UTC timestamp, sender and recipient, source IP, relevant headers, and the Google log result. Remove or mask any personal content that is not required.

Roll back safely

A rollback restores the documented original state. First stop or pause active pilot campaigns to prevent ambiguous results during the rollback. Treat Inbound gateway and Email allowlist as tenant-wide changes; only Spam and Content compliance will be rolled back in the pilot organisational unit.

Deactivate or remove the newly created Content compliance rule in the pilot organisational unit.
From there, remove the new Spam rule and restore it to its original inheritance state. Don’t delete the dedicated Address list until no other rule is using it.
Select the top-level organisation and restore the previous tenant-wide Inbound gateway configuration exactly, including activation status, IPs, TLS, and Message Tagging. If no gateway was previously active, restore this global state; there is no local OU override.
In the top-level organisation, remove from Email allowlist only the Phish Threat IP addresses added by this change and thus restore the secured tenant-wide initial state.
Wait for the changes to take effect. Test a normal external message to a former pilot recipient and to a recipient outside the pilot; use Email Log Search and the headers to verify the restored global and local state.
Record the reason, time, executing person, and test result in the change.

Do not delete any shared list and do not overwrite any existing Google rule just to reset the pilot. If the global initial state is not clearly documented, do not remove entries belonging to others and do not guess the previous gateway state. Stop the campaign, only revert additions that can be clearly assigned to this change after a four-eyes check, and clarify the remaining rollback with the responsible Google Workspace administrator.

Maintain exceptions over campaign operations

The configuration is not a one-time ‘Allow forever’ step. Check before each campaign series and at least quarterly:

current Sophos Phish Threat sending IP addresses and, only if Sophos Mailflow is actually in use, the values for your own Mailflow region;
the sender domains specifically listed in Sending domains and IPs or in the campaign details;
Owner, purpose, tenant-wide scope of Email allowlist and Inbound gateway, OU scope of Spam and Content compliance, as well as the review date of each Google rule;
unexpected hits on X-PT-TOKEN, too broad wildcards, and orphaned address list entries;
TLS results, Google logs, and the quality of Sophos campaign events.

Remove IPs and domains that are no longer needed after a controlled test. In a permanent awareness campaign, only the values still in use remain active; temporary campaign domains are removed after completion. Every expansion undergoes impact analysis, matching, non-matching, and scope testing again. A pilot can only limit the Spam and Content compliance rules, not Email allowlist or Inbound gateway. This way, deliverability remains measurable without turning a phishing simulation into a permanent general bypass.