Sophos Phish Threat: Allow senders, domains, and IPs

Sophos Phish Threat can only provide realistic campaign results if simulations are delivered and users can reach the associated phishing and training pages. This requires allowing the sender domains, IP addresses, and web destinations provided by Sophos at every control point they actually pass through. However, a blanket bypass of email or web security is neither necessary nor advisable.

This process is vendor-neutral. It applies to upstream mail gateways, Mail Transfer Agents, Secure Web Gateways, proxies, firewalls, DNS and URL filters, and products that automatically inspect links or attachments. Product-specific steps are covered in the delivery guides for Microsoft 365 and Google Workspace.

Find the current values in Sophos Fusion (formerly Sophos Central)

Retrieve the authoritative list from the affected Sophos Fusion tenant:

1. Click the Global Settings icon.
2. Open Products and Services > Sophos Phish Threat.
3. Click Sending domains and IPs.
4. Document all displayed sender domains, IP addresses, and web destinations, including the retrieval date.

The regional Sophos Mailflow IP addresses must not be added indiscriminately to the Phish Threat allowlist. They are used only for automatically configured Microsoft 365 Mailflow connectors or to restore those connectors after configuration changes. These networks must therefore be entered only as part of the documented Mailflow connector configuration and only for the region in use—not preemptively in upstream gateways, proxies, or web filters.

The list may include values for different functions:

• IP addresses and domains used to send campaign emails,
• sender or Return-Path domains,
• tracking and redirect destinations for click measurement,
• domains for simulated phishing or sign-in pages,
• training pages and other web destinations required for the campaign workflow.

Phish Threat links may redirect through the AWS tracking destination awstrack.me documented by Sophos. Such a redirect is expected for click measurement. Before the pilot send, compare the hosts actually required against the current Sophos list and the destinations used by the specific campaign. Do not allow additional subdomains unless their need is confirmed there or in the product documentation.

Map the data flow before allowing traffic

Allowlisting is performed at every control point, not just on the final mail server. First document the actual path taken by a test message and a test click:

1. Sophos Phish Threat sends the simulation.
2. An upstream cloud filter, Secure Email Gateway, or MTA accepts the message.
3. Other anti-spam, anti-phishing, sandbox, or link-analysis services process it.
4. The destination system delivers it to the mailbox.
5. When the user clicks, the request passes through DNS filters, a proxy, a Secure Web Gateway, a firewall, and possibly browser or endpoint protection.
6. Tracking, phishing, and training pages send the events back to Phish Threat.

For each step, record the product, rule owner, required value, intended exception, expiry or review date, and rollback path. If multiple filters are in sequence, every relevant filter must be considered. Allowing traffic only at the destination mailbox does not resolve blocking at an upstream gateway.

Implement the narrowest possible allowlist

Make the rule only as broad as technically required for the simulation. Prefer exact IP addresses or hostnames, the current Phish Threat list, and the intended test recipients. Use a complete domain, wildcard pattern, or global scanner exception only if the campaign configuration or product does not permit a narrower rule.

Some products distinguish between delivery, spam scoring, URL rewriting, Time-of-Click inspection, Attachment Sandboxing, and web access. A single “Allow” rule does not automatically cover all of these functions. Conversely, an allowance for email delivery must not inadvertently exempt every file or URL from the same sender from all inspection.

Allow variable hosts only when there is a demonstrated need

Initially, add only the individual hosts shown in Sophos Fusion or the product documentation and used by the campaign. If a specific product or campaign destination demonstrably uses variable hosts and the allowance cannot technically be limited to exact hostnames, a wildcard may be required. In that case, apply these additional controls:

• set the wildcard only below the base domain shown by Sophos,
• do not allow the entire parent provider domain,
• limit the rule to Phish Threat traffic and, where possible, pilot recipients,
• document the owner and review date,
• check whether an additional host is used before every new campaign template.

A very broad allowance, such as an entire shared cloud or sending platform, increases the risk of admitting unrelated traffic. If a product cannot implement the required narrow scope, accept this residual risk before the change or choose a different delivery path.

Prevent false clicks and automatically opened attachments

Email security products often inspect messages by visiting URLs or opening attachments in a sandbox. Phish Threat may interpret such a request as a user action. This results in apparent clicks or opened attachments even though the recipient has not yet interacted with the message.

Typical signs that an event came from a scanner rather than a user include:

• events occur before or immediately upon delivery,
• many recipients show the same action almost simultaneously,
• source addresses or User-Agents belong to the security service,
• several links in the same message are opened in quick succession,
• the pattern can be reproduced with a newly sent pilot message.

Correct the issue on the scanner causing it: add the current Phish Threat IP addresses and domains to its designated list for authorized phishing simulations or targeted scan exceptions. The exception must match both the identified source and the affected scanning function. Allowing only a sender address is insufficient if the service independently opens every URL in a sandbox.

Missing click events often have the opposite cause. Tracking destinations may be blocked by Secure Web Gateways, DNS filters, or browser extensions such as ad blockers. Therefore, if telemetry is missing, do not restart the campaign immediately; first inspect the redirect chain in the browser and the proxy, DNS, and endpoint logs.

Microsoft 365 bypass headers only as a legacy exception

Older guides use transport rules with the headers X-MS-Exchange-Organization-SkipSafeLinksProcessing or X-MS-Exchange-Organization-SkipSafeAttachmentProcessing. Such rules are not the baseline for a new deployment. For SMTP-based delivery through the Microsoft 365 transport pipeline, Microsoft provides the Advanced Delivery Policy. For new deployments, however, Sophos recommends M365 Direct Delivery; this delivery path bypasses the transport pipeline, so Advanced Delivery does not apply to it. The specific Microsoft 365 configuration must follow the current Sophos guidance for the selected delivery path and is outside the scope of this article.

Legacy headers should be considered only if an existing environment demonstrably still requires them, the current support status has been checked, and an approved change with a narrow IP/domain scope exists. Rule priority, effect, and security implications must be tested separately. Do not run old header rules “just in case” alongside a current simulation allowance.

Validate a pilot campaign

Start with a small pilot group of controlled test accounts. It should include at least one mailbox for every relevant delivery path, policy group, and location. The test covers a message with a link and—if used operationally—a campaign with an attachment and training.

Before sending, document the timestamps, campaign ID, recipients, expected sender, domain used, and IDs of the changed rules. Then verify:

1. The gateway accepts the message and delivers it exactly once to the expected mailbox.
2. The values actually used for the intended rule match must appear on the current Sophos list: the relevant visible From domain or Envelope Sender/Return-Path domain and, if the rule is IP-based, the source IP of the sending SMTP system that the inspecting gateway logged as its connection peer. Check these fields separately; the receiving server’s IP is not a sender-IP match.
3. The message ends up neither in quarantine nor unexpectedly in the Junk folder.
4. No click or attachment event appears in Phish Threat before a user action.
5. A controlled user click opens the expected redirect, simulation, or training page.
6. Exactly that action appears in the campaign result at a plausible time.
7. Proxy, firewall, DNS, and scanner logs show the expected rule, but no unnecessarily broad bypass.
8. A normal external test message and a web destination that has not been allowed continue to be inspected under the existing security policies.

Success means more than “email arrived.” Delivery, accurate campaign measurement, reachable web destinations, and security controls that remain effective must all be confirmed. Only then should the rule be expanded to the intended recipient group.

Isolate errors systematically

If delivery fails, work inward from the first acceptance point: SMTP log, upstream gateway, quarantine, downstream transport rule, and destination mailbox. The SMTP error or product verdict indicates where the message was rejected. Adding broad exceptions without this evidence makes root-cause analysis more difficult.

For false clicks, compare the timeline from sending through delivery. Use scanner logs, source IP, and User-Agent to attribute a reproducible automated request to the product causing it. For genuine clicks that are not recorded, check DNS resolution, the proxy decision, TLS connection, redirects, and browser extensions.

If the cause remains unclear, stop the pilot campaign. An exception must not be widened step by step until delivery happens to work.

Roll back changes and maintain them continuously

Before implementation, define a rollback for each rule: previous state, rule ID, export or screenshot, responsible person, and rollback order. Disable the change or restore the last validated state if unrelated messages are delivered unexpectedly, security is bypassed too broadly, proxy access is suspicious, or campaign data remains distorted. Then inspect the mail and web logs again.

Apply these minimum controls during ongoing operation:

• compare current values with Sophos Fusion before every major campaign,
• retest rules after a product, routing, or provider change,
• regularly review wildcards and global exceptions for a narrower scope,
• remove domains, IPs, and legacy rules that are no longer required,
• record a review date, owner, and technical rationale for every exception,
• always run a pilot campaign without an automatic false click after changes.

FAQ