Skip to content
Avanet

Set up Sophos Phish Threat Direct Delivery for Microsoft 365 and Google

Sophos Phish Threat

With Direct Delivery, Sophos Phish Threat delivers campaign emails directly to mailboxes through Microsoft Graph or Gmail APIs. This also applies to training registrations and training reminders. Mail filtering rules are bypassed; Phish Threat sender domains and IP addresses do not need to be allowlisted in Microsoft 365 or Google Workspace for this delivery method.

This article deals exclusively with API direct delivery. SMTP exceptions, gateways, compliance rules or provider-related allowlisting procedures belong to the separate SMTP delivery path and are not replicated here.

Deciding before activation

Direct Delivery is activated per verified domain. If you have multiple domains, each domain requires separate activation and testing. Choose the provider based on the target system for the domain in question:

  • Microsoft M365 uses Microsoft Graph. A Global Administrator or Privileged Role Administrator in Microsoft Entra is required to grant tenant-wide consent for Microsoft Graph application permissions.
  • Google Workspace uses Google APIs. A Super Admin must authorize the OAuth client and scopes specified by Sophos through Domain-wide delegation in the Google Admin console. If Multi-party approval is enabled, a second Super Admin must approve the change.

Before the change, document the domain, provider, technical owner, test recipient, maintenance window, and previous delivery method. Only verified domains appear under My Products > Sophos Phish Threat > Settings > Direct Delivery for M365/Google.

Before switching, pause active campaigns, campaigns about to start, staggered sends, and training reminders for the affected domain. Document the previous SMTP delivery method and verify it with a controlled recipient. If you have multiple domains, proceed sequentially: activate exactly one domain per maintenance window, complete the quick test and a controlled click test, and resume sending only after successful validation.

Important: If M365 Direct Delivery is not activated, Phish Threat uses SMTP by default. Before a rollback, the previous SMTP delivery path must therefore continue to be functional. The exceptions required for SMTP are not part of this API configuration.

Microsoft 365: Requirements and permissions

Sophos recommends Microsoft 365 automated provisioning because it creates the credential with the required permissions. For manual registration, Domain.Read.All and Mail.ReadWrite must be configured as Microsoft Graph application permissions (Application permissions, not delegated permissions) and approved through tenant-wide admin consent. The App ID and Client Secret of the registered Entra application are also required. Do not add extra permissions as a precaution.

This consent applies to the entire tenant without a signed-in user: Domain.Read.All allows the application to read domain objects; Mail.ReadWrite allows it to create, read, modify, and delete messages in all mailboxes. Information security must approve this scope before consent is granted, and the credential must be protected accordingly.

An existing credential in Sophos Fusion (formerly Sophos Central) can be used only if it includes the Phish Threat permissions. If they are missing, the credential appears under Disallowed credentials. In that case, add the required permissions to the existing credential or create a dedicated new credential. The separate article about Integration Credential Manager explains how to check usage and dependencies before later suspending or deleting a credential.

Connect Microsoft 365 automatically

  1. Open My Products > Sophos Phish Threat > Settings and choose Direct Delivery for M365/Google.
  2. In the column Direct delivery activate the switch of the desired domain.
  3. In the dialog Configure Direct Delivery select the provider Microsoft M365 and click Proceed.
  4. On Credential Manager, select a suitable existing credential or click add new credential.
  5. On Add Microsoft Graph Credential, select Use Microsoft 365 automated provisioning.
  6. Enter a unique name and description and click Save and Continue to Provisioning. The name is just an identifier.
  7. Continue to Connect to Microsoft 365 with Continue.
  8. In the Microsoft sign-in window, select the correct account, review the terms, and click Accept. Also confirm the second consent dialog for the Sophos Fusion integration with Accept.
  9. Close the sign-in window with Close. Review the newly created credential on Credential Manager and click Enable.

The first consent authorizes the Master App, the second authorizes the Sophos Fusion integration. Both steps must be successfully completed.

Connect Microsoft 365 manually

  1. Follow the steps above through Add Microsoft Graph Credential.
  2. Enter authentication details manually.
  3. Enter the registered Entra application data and assign a unique credential name.
  4. Click Save, then click Update in Credential Manager.

The domain is connected through Direct Delivery only after successful activation. A stored App ID alone is not a functional test.

Google Workspace: Requirements and permissions

For the setup, pop-ups must be allowed in the browser. If login data of another Google domain is stored, an incognito or private browser window should be used. This prevents consent from being given in the wrong workspace.

Sophos requests permissions based on the required function during connection. The common setup scopes include:

  • https://www.googleapis.com/auth/cloud-platform to create, read, update or validate required Google cloud resources during setup.
  • https://www.googleapis.com/auth/userinfo.email to identify the approving Google administrator account.

The Google OAuth Client ID and OAuth scope required for Direct Delivery are displayed in Sophos Fusion. Copy them unchanged from there to the Google Admin console. Do not copy scopes from examples or shorten them yourself.

For new Google Workspace accounts, the policy for creating service account keys in Google Cloud is enabled by default. If it remains activated, the direct delivery connection fails. The policy must therefore be deactivated before connection in Google Cloud. This relaxes a security control: the exception must be managed and limited as narrowly as possible. After successful provisioning, check whether the policy can be enforced again.

Connect and authorize Google Workspace

  1. Open My Products > Sophos Phish Threat > Settings > Direct Delivery for M365/Google.
  2. In Direct delivery activate the switch of the desired domain.
  3. In Configure Direct Delivery, select Google Workspace and click Proceed.
  4. In Sign in with Google, select the correct administrator account and sign in.
  5. Check privacy policy and Terms of Service, click Continue, select the required access and click Continue again.
  6. Wait until the connection progress reaches 100%, then click Close.
  7. On Direct Delivery for M365/Google open the connected domain.
  8. With Copy, copy the values next to Google OAuth Client ID and OAuth scope.
  9. As Super Admin open the Google Workspace Admin console and re-authenticate if necessary.
  10. Under Domain-wide delegation, select Add new. In the Add a new client ID dialog, enter the copied ID under Client ID and the copied scopes under OAuth scopes (comma-delimited). Confirm with Authorise. If Multi-party approval is enabled, a second Super Admin must approve the change.
  11. Back in Sophos Fusion, click Verify and connect. Authorization may take a few minutes.
  12. After successful verification, confirm the Verify Connection dialog with Ok.

The domain is fully authorized only after Verify and connect completes successfully. A connection progress of 100% does not replace this second verification step.

Validate each domain with a quick test

Microsoft 365 and Google Workspace use the same domain-specific test process:

  1. On Direct Delivery for M365/Google, click Test next to the activated domain.
  2. In Run a quick direct delivery test enter the address of a controlled recipient of this environment.
  3. Click Proceed and document the success or error message.
  4. In the destination mailbox, check receipt, the sender display, and the intended campaign link.

Run the test separately for every activated domain. A success message confirms API delivery to the test recipient, but does not automatically confirm that downstream protection features will allow every URL click.

Microsoft Defender can block URLs from simulated phishing campaigns when a user clicks them, even though Direct Delivery successfully delivered the message to the mailbox. This is not a contradiction: the successful quick test proves API delivery, but not that Safe Links or other protection features will allow every campaign link.

For blocked or rewritten links, first retrieve the current phish threat IP addresses, domains and web destinations in your own tenant at Global Settings > Products & Services > Sophos Phish Threat > Sending domains and IPs. Then check the current Microsoft 365 exclusion procedure for the delivery route used. In a Safe Links policy, the URL patterns provided by Sophos may be required under Do not rewrite the following URLs. Sophos documents the format *.domainname/*, for example *.hr-benefits.site/*. Limit the exception to the patterns actually needed and document it separately from the direct delivery activation.

Do not rewrite the following URLs alone does not guarantee that Microsoft Defender will allow a link when clicked. Depending on the Microsoft 365 configuration and delivery path, Advanced Delivery and other Defender exceptions can also affect how the simulation is handled. Therefore, do not add a blanket transport rule. Test the actual combination of Defender, Advanced Delivery, and Safe Links with a controlled user click and document the result.

Troubleshoot specific errors

A domain is not displayed

Direct Delivery for M365/Google lists verified domains. If a domain is missing, first check its verification status in Sophos Fusion; do not work around the issue by creating a credential for another domain.

Microsoft shows Disallowed credentials

The selected credential was created for another purpose and does not include the Phish Threat permissions. Review and add the required Graph permissions and consent, or create a suitable credential with Use Microsoft 365 automated provisioning. For manual provisioning, Domain.Read.All and Mail.ReadWrite must be configured as Application permissions with tenant-wide admin consent; delegated permissions are not sufficient.

The Microsoft quick test fails

Check whether the switch is active for the correct domain, the associated credential is still valid, and both Microsoft consent steps are complete. For a manual configuration, also check the App ID, Client Secret, Application permission type, and tenant-wide admin consent. Then run Update and use Test again.

Google does not connect

For new workspaces, first check the policy for creating service account keys in Google Cloud. Then check the pop-up blocker, the Workspace domain in use, and the administrator account. Use a private window to rule out a cached sign-in for the wrong domain.

Verify and connect remains pending or fails

Wait a few minutes for the authorization to propagate. Then compare the Client ID and OAuth scopes (comma-delimited) with the values displayed in Sophos Fusion. Missing, shortened or authorized scopes in the wrong workspace domain prevent the full connection.

This indicates successful Direct Delivery followed by downstream URL inspection. Retrieve the current values under Sending domains and IPs, review the Microsoft 365 exclusion procedure and Safe Links settings for the delivery method, and repeat the click test in a controlled manner. Do not recreate the API connection while the quick test succeeds.

Google permissions revoked

If permissions are removed in Google Workspace, the associated Sophos function will no longer work. Direct Delivery must then be reconnected and authorized in Sophos Fusion. Merely resending a Test does not restore permission.

Deactivate and roll back in a controlled manner

Before deactivation, pause sending for the affected domain, document the current domain status and credential, and verify the SMTP fallback. Then, during the maintenance window, deactivate only that domain’s switch in the Direct delivery column. For M365, the domain falls back to SMTP-based delivery by default. Keep sending paused until a controlled follow-up test confirms the intended fallback delivery method. If the test fails, do not resume any campaign; restore the documented initial state or escalate to Sophos Support.

For Google, a guided disconnection process is also documented:

  1. On Direct Delivery for M365/Google, disable the domain’s switch under Direct delivery.
  2. Review and accept the terms of use again; this is required for every disconnection.
  3. Select the Google Workspace administrator account used for the disconnection and complete the account verification.
  4. Check the requested permission dialogs, select the required access and click Continue.
  5. Wait until the disconnection is complete and click Close.

Disconnection can take a few minutes. The domain must then be shown as disconnected.

Deactivate delivery or remove authorization

Disabling delivery is not the same as fully revoking permissions:

  • Microsoft 365: The domain switch ends Direct Delivery for this domain, but does not automatically delete the Sophos credential, a manually created Client Secret, or the Entra service principal and its admin consent.
  • Google Workspace: After the guided disconnection, inventory the domain-wide delegation and third-party permissions in the Google Admin console. Review them separately and remove them if appropriate.

Before deleting a credential, service principal, Client Secret, or Google authorization, always check whether other Sophos integrations or domains use it. Only after confirming the rollback and completing this dependency check should you revoke authorizations and remove secrets that are no longer required; then document the revocation.

Acceptance criterion: Activation is complete only when the desired domain shows the expected status and API delivery has been tested successfully with a controlled recipient. Click behavior under Safe Links requires a separate test. A rollback is complete when Direct Delivery has been disabled for the domain, the intended fallback delivery method has been verified, and any intended permission revocation has been verified separately.