Sophos Phish Threat: Troubleshoot delivery failures and bounces
When users do not receive a Sophos Phish Threat email, there are several possible causes: the campaign has not yet reached the recipient, the target address is invalid, a gateway is limiting the sending rate, or a security control is blocking or quarantining the simulation. The investigation therefore begins in Sophos Fusion (formerly Sophos Central) and then follows the delivery path actually in use.
Important: Users listed on the Bounced Mailboxes page do not receive emails from future campaigns until the cause has been corrected and the users have been removed from the list. Removing them is therefore not the first troubleshooting step; it should only be done after correcting the issue.
Quick diagnosis
| Observation | Check first | Then |
|---|---|---|
| The campaign has just started | allow at least one hour before sending begins and check the sending schedule | check campaign progress again |
| Only some users received an email | interval-based sending, recipient list, and active mailboxes | check Bounced Mailboxes and directory synchronization |
| Central shows Bounced or Not Sent | error details under Bounced Mailboxes | investigate the address, DNS/SMTP errors, and mail flow |
| Central shows Delivered, but the email is not visible | Message Trace, gateway logs, quarantine, and junk folder | identify the filter rule that was triggered |
| Many emails fail at high volume | rate limiting or throttling | stagger sending over several hours or days |
| Direct Delivery is configured for the domain | Direct Delivery configuration | continue troubleshooting in the relevant runbook |
1. Record a reproducible case
Before making changes, record the following information:
- campaign name
- scheduled and actual start time, including the time zone
- one to three affected recipients and one working recipient for comparison
- sending domain used
- delivery status of the affected user
- time of the delivery attempt
- full error text, DNS code, and SMTP error, if shown
- latest changes to the campaign, recipient list, directory synchronization, or mail filters
Do not immediately start another large campaign. Repeated full-scale sends make correlation more difficult and can trigger rate limits or security rules again.
2. Check the campaign schedule and progress
Under Phish Threat > Campaigns, open the affected campaign. Check whether it is active and being processed, and which delivery status Central shows for the affected users.
After a campaign starts, emails are not sent for at least one hour. A campaign can also deliver emails in stages, ranging from immediate delivery to batches as small as 5 percent. If only part of the target group has received the email, check the configured schedule and outstanding sending intervals first.
For changes to the schedule or pausing a running campaign, follow Manage Sophos Phish Threat campaigns. Do not change an active campaign without documenting the effect on emails that are still pending.
3. Review Bounced Mailboxes
Open the Global Settings icon and go to Products and Services > Sophos Phish Threat > Bounced Mailboxes. For failed deliveries, this page contains the Email ID, campaign name, and error details such as the DNS code and SMTP error.
You can filter the list by the following information:
- username
- email address
- campaign name
- bounce type
Start with the affected email address and campaign name. Record the error text and time without altering them. The Email ID is a Sophos Fusion field and must not be equated with an RFC Message-ID, gateway log ID, or trace ID unless the relationship is supported by evidence.
The entry shows that delivery failed, but it does not yet show which system caused the failure. Do not remove users from Bounced Mailboxes until the following checks are complete and the cause has been corrected.
4. Check recipients and directory synchronization
Check the following for every affected user:
- Is the email address spelled correctly and complete?
- Does the mailbox exist, is it active, and can it receive normal messages?
- Did incorrect addresses come from a manual CSV import?
- Has the current primary address been synchronized to Sophos Fusion?
- Is the directory synchronization in use running without errors?
Correct incorrect or outdated target addresses at their source first, and then confirm successful synchronization. Simply removing a user from Bounced Mailboxes fixes neither an invalid address nor a disabled mailbox.
5. Determine the delivery path
Before searching logs, determine whether the affected domain uses Direct Delivery or the normal mail flow.
If Direct Delivery is configured, continue with Configure and verify Sophos Phish Threat Direct Delivery. API, permission, and provider checks belong in that procedure, not in an SMTP analysis.
For delivery through the normal mail flow, check the logs of all systems actually involved. For Microsoft 365, Sophos Phish Threat delivery in Microsoft 365 describes the provider-specific steps; for Google Workspace, see Sophos Phish Threat delivery in Google Workspace.
6. Investigate Message Trace and gateway logs
Search the local mail gateway’s Log Viewer or Message Trace using a narrow time window. Depending on the environment, this may be Sophos Firewall email logs, Message Trace in the Exchange Admin Center, or the logs of an upstream spam filter.
Narrow the search to the following attributes:
- exact recipient address
- time of the delivery attempt
- documented regional Sophos Phish Threat sending IP addresses
- sending domain used in the campaign
Do not copy sending IP addresses and domains from old tickets. The current values are available under Phish Threat > Settings > Sending domains and IPs.
Record the following for the last confirmed hop:
- Did the gateway reject the connection?
- Was the email blocked or quarantined because of spam or phishing detection?
- Was it rejected because of SPF, DKIM, or DMARC alignment?
- Was rate limiting or throttling applied?
- Was the email accepted and forwarded to the next hop?
Record the complete SMTP error, responding host, and timestamp. If the status is Delivered, also check quarantine, the junk folder, and downstream rules.
If there is no log entry, check the time window, time zone, recipient, sending IP or sending domain, and selected delivery path first. Only then assume that no delivery attempt took place.
7. Correct the specific cause
Rate limiting or throttling
Use the batching feature to spread sending over several hours or days instead of sending all emails at once. Then use a small, authorized target group to check whether the gateway accepts the new rate.
A filter blocks or quarantines the simulation
Do not create an ad hoc global exception. Configure the required regional Sophos IP addresses, sending domains, and affected controls according to Allow Sophos Phish Threat senders in a controlled manner.
For every temporary diagnostic change, record:
- original configuration
- responsible person and approval
- narrowly limited scope
- start and expiry time
- rollback step
- result of the delivery test and regression test after rollback
Permanent exceptions for simulations also require a documented scope, an owner, and regular review. Do not extend them to arbitrary Sophos networks, senders, or all security controls.
Invalid recipients or synchronization errors
Correct the address or mailbox in the authoritative source, allow synchronization to complete without errors, and only then retest.
8. Clear the bounced mailbox entry and test on a limited scale
After the technical correction, follow this sequence:
- Document the cause and correction.
- Confirm that the address, mailbox, and delivery path in use are now working.
- Remove the affected user from Bounced Mailboxes.
- Use a small, authorized test campaign or the next controlled campaign send.
- Check the delivery status in Phish Threat > Campaigns.
- For the normal mail flow, confirm acceptance and forwarding in the logs of the systems involved.
- Check whether the email appears in the intended mailbox or expected quarantine.
Only include more recipients after a successful test. If the test fails again, evaluate the new entry under Bounced Mailboxes and the corresponding gateway logs instead of repeatedly removing the user.
Evidence package for escalation
If the issue remains reproducible after the correction, provide the following information through the secure support channel:
- Central tenant or account ID
- campaign name
- affected recipient address, redacted where possible in accordance with data protection requirements
- delivery status and time, including time zone
- Email ID from Bounced Mailboxes
- complete DNS code and SMTP error
- delivery path used
- for normal mail flow: SMTP code, responding host, last confirmed hop, and any available Message Trace or gateway identifier
- correction performed and result of the limited test
Passwords, tokens, campaign links, and complete user exports do not belong in the evidence package. Headers and logs may contain internal hostnames, IP addresses, email addresses, and tracking values and must not be copied into public tickets or forums.