Deliver Sophos Phish Threat safely in Microsoft 365

Sophos Phish Threat provides two technically distinct delivery routes in Microsoft 365:

• M365 Direct Delivery uses Microsoft Graph to write campaign, training enrollment, and training reminder emails directly to mailboxes. The messages bypass the Microsoft transport pipeline, so Advanced Delivery does not apply.
• With SMTP delivery, the message passes through the Microsoft transport pipeline. Microsoft 365 must identify it as a third-party phishing simulation using the actual Sending IP and the domain from 5321.MailFrom or the DKIM domain.

Both routes must be kept separate from Sophos Email Mailflow and Sophos Email Gateway. Phish Threat simulates attacks; Sophos Email protects production mail traffic. Direct Delivery requires neither MX records nor Exchange Online connectors. The SMTP route likewise does not justify a global EOP bypass or a blanket IP allow list.

Prerequisites and change boundaries

Before making the change, you need:

• an active Sophos Phish Threat license and an email domain verified in Sophos Fusion (formerly Sophos Central);
• administrative access to Sophos Phish Threat > Settings;
• an approved Microsoft Graph application and tenant-wide admin consent for Direct Delivery;
• permission to manage Advanced Delivery in the Microsoft Defender Portal for the SMTP route;
• one controlled pilot mailbox, a business owner, a change window, and an abort criterion for each domain.

For manual Direct Delivery setup, Sophos requires the Microsoft Graph application permissions (Application permissions, not delegated permissions) Domain.Read.All and Mail.ReadWrite; both require admin consent. Domain.Read.All can read all domain properties without a signed-in user. Without further restrictions, Mail.ReadWrite can read, create, modify, and delete messages in all mailboxes in the tenant. The permission does not include Mail.Send, but its tenant-wide read and write access still makes it highly privileged. This scope must be considered before consent is granted and during offboarding.

Record the domain, tenant ID, selected delivery route, credential, current Direct Delivery status, and existing Microsoft simulation values beforehand. An existing Sophos Email Mailflow or Gateway deployment remains a separate system. Do not change its connectors, transport rules, MX, SPF, or Enhanced Filtering settings as a side effect of this Phish Threat change. The relevant owner runbooks are Sophos Email Mailflow for Microsoft 365 and Sophos Email Gateway with Microsoft 365.

Select the delivery route

Sophos recommends Direct Delivery. It is enabled separately for each verified domain; a green status for one domain does not prove that other domains are ready. The owner runbook Sophos Phish Threat: Set up Direct Delivery covers authorization, quick testing, troubleshooting, and deactivation for this route. The rest of this article addresses the Microsoft 365-specific SMTP route and distinguishes it from Direct Delivery.

Set up SMTP delivery with Advanced Delivery

Do not copy variable Sophos values from an old guide. Immediately before the change, read them in Sophos Fusion under My Products > Phish Threat > Settings > Sending domains and IPs, then confirm them against the headers of a current pilot message. Allow-list Phish Threat senders and destinations covers other destinations and how to limit them safely.

Determine the correct matching values

Microsoft requires at least:

1. the actual Sending IP that Microsoft 365 detects for the SMTP message; and
2. either the domain from 5321.MailFrom — also called MAIL FROM, P1 sender, or Envelope Sender — or the provider-specified DKIM domain (header.d).

The visible From:/5322.From domain is not an interchangeable substitute. Therefore, check smtp.mailfrom, header.d, and the detected source IP in Authentication-Results. Microsoft does not pair individual domain and IP entries; keep both lists restricted to the Sophos values that are actually required.

The optional Simulation URLs to allow field is not required for links in email phishing simulations. Microsoft primarily intends it for non-email simulations, such as links in Teams messages or Office documents. Leave it empty for this email procedure.

Configure the Microsoft Defender Portal

1. In the Microsoft 365 Admin Center, open Show all > Security.
2. In the Microsoft Defender Portal, open Email & collaboration > Policies & rules > Threat policies.
3. Under Rules, select Advanced Delivery.
4. Open the Phishing simulation tab and select Edit. If no third-party simulation exists yet, the button for adding one appears instead.
5. Under Domain, enter only confirmed 5321.MailFrom or DKIM domains — not the visible From: domain unless it is also one of those two values.
6. Under Sending IP, enter only the Sophos source IP detected by Microsoft or the verified, smallest possible range.
7. Leave Simulation URLs to allow empty for this email simulation, compare the values with the change record, and select Save.

Connector and routing boundary

If the MX record does not point directly to Microsoft 365, the IP in Authentication-Results must still match the Sending IP configured under Advanced Delivery. Enhanced Filtering for Connectors can help detect the original source IP in supported upstream filtering topologies, but it replaces neither domain-and-IP matching nor the simulation configuration.

Microsoft explicitly documents a limitation for in-and-out routing through Internet > Microsoft 365 > on-premises environment or third-party security service > back to Microsoft 365: Microsoft 365 cannot reliably detect the true source IP of the third-party simulation, and Enhanced Filtering does not resolve this case. Do not enter the gateway, on-premises, or connector IP as the supposed Sending IP. Otherwise, any internet sender imitating a configured domain could bypass the spam filter.

The safe boundary is to send the simulation directly to the Microsoft 365 MX or use a method explicitly documented by Microsoft for the specific topology. If the real Sophos IP cannot be detected, stop the SMTP rollout instead of forcing it with a gateway IP or broad transport rule.

Classify Safe Links and Safe Attachments correctly

Do not mix the two delivery routes here:

• SMTP with a correct Advanced Delivery match: Safe Links does not block or detonate the specified URLs in this email simulation when clicked, and Safe Attachments does not detonate its attachments. The URLs remain rewritten. An additional entry under Do not rewrite the following URLs in email is unnecessary and may trigger unwanted click alerts.
• Direct Delivery: These messages bypass the transport pipeline, so Advanced Delivery does not apply. If a controlled Direct Delivery test reproduces a Safe Links click block, the Sophos-documented Safe Links exception, limited to the simulation domain actually used, may be required. It applies only to this Direct Delivery case and is implemented according to Allow-list Phish Threat senders and destinations.

Legacy transport rules using X-MS-Exchange-Organization-SkipSafeLinksProcessing or X-MS-Exchange-Organization-SkipSafeAttachmentProcessing are not an additional standard step. Evaluate an existing rule separately only when there is documented need and a confirmed narrow source-IP condition; never extend it to all messages or to an arbitrarily chosen sender domain.

Validation before the first SMTP campaign

Send a small pilot campaign only to authorized test accounts. For each domain, record the recipient, sending time, campaign ID, and expected matching values. Then verify:

• delivery or quarantine and the corresponding Microsoft Message Trace;
• the Sending IP detected by Microsoft and smtp.mailfrom and header.d in the message headers;
• that at least the actual Sending IP and an eligible 5321.MailFrom or DKIM domain match Advanced Delivery > Phishing simulation;
• rendering, link clicks, and the expected Phish Threat events;
• that no automated check was counted as a user action.

The business evaluation belongs in Sophos Phish Threat: Results and reports. A Message Trace entry alone proves neither inbox delivery nor correct campaign measurement.

Troubleshoot systematically

If a test fails despite correct values, collect the domain, UTC time, recipient, campaign ID, Microsoft trace, relevant headers, and configured simulation values. Send this information to Sophos Support or the Microsoft 365 owner. Do not put secrets, access tokens, or unnecessary personal campaign data in the ticket.

Roll back and review SMTP exceptions

If an SMTP change fails, restore the previously recorded values under Advanced Delivery > Phishing simulation. Remove newly created exceptions or legacy transport rules only when their association with the affected simulation is unambiguous. Then use a controlled test to confirm that production mail flow still works unchanged. Sophos Email connectors and rules remain untouched.

At least before each new campaign series and after changes to the domain, Sophos sender values, routing, or Microsoft security policies, the owner checks:

• current Sophos values against the actual Sending IP and smtp.mailfrom or header.d of a pilot message;
• the direct or explicitly supported route to the Microsoft 365 transport pipeline;
• domains, IP addresses, and legacy rules that are no longer used;
• a controlled end-to-end test including a link click and campaign event.

When Sophos sender values change, replace them through an approved change and delete the old values only after successful pilot delivery. Direct Delivery credentials, testing, and offboarding remain in the Direct Delivery owner runbook, so the API lifecycle is maintained in only one place.