Sophos Email Message History: trace messages and troubleshoot delivery
Message History is the first evidence trail for determining what Sophos Email did with a message. It separates processed messages from connections rejected because a mailbox wasn’t found. A result alone isn’t proof of final delivery: the last recipient event, external provider trace, and destination mailbox must agree.
This runbook covers interactive troubleshooting in Sophos Fusion (formerly Sophos Central). Trend reporting is a separate analysis process; automatic post-delivery remediation and programmatic API actions are outside this workflow.
Prepare the request, access, and search data
Use a named administrator account in the correct tenant. Confirm that its role can read Message History and perform only actions authorized by the request. Before searching, record the time range and time zone, SMTP sender and recipient, subject, Internet Message-ID or known Sophos ID, direction, and expected Gateway or Mailflow route.
Also preserve the bounce or complete SMTP response and, when available, the provider trace. Search fields use SMTP envelope addresses, which need not match visible From and To headers. One row can contain different outcomes for different recipients.
Select the correct report and date range
- In Sophos Fusion, open Reports > Email Security Logs > Message History.
- Select Processed report for messages accepted and processed by Sophos. Select Rejected report for connections rejected because a mailbox wasn’t found.
- For mixed domains, use Type to select Gateway, Mailflow, or all types.
- Set the range, then select Refresh.
The current day appears by default. The selectable history is up to 30 days, or up to 90 days with a Sophos Email Plus license. Export doesn’t extend that window. Investigate older cases through the external mail provider, existing bounces, or reports already retained; don’t assume Central must still contain them.
In Sophos EMS mode, Sophos scans journal copies and doesn’t intercept the original message. Statuses shown there are for reporting and don’t reliably represent the original message’s actual delivery status.
Search processed messages precisely
In Processed report, start with date range and direction, then narrow by Category, Status, TLS encryption, and Type. Advanced Search provides From, To, Subject, Message size, Attachment, and DSN code. Partial strings aren’t case-sensitive, multiple criteria use logical AND, and special, control, and formatting characters are ignored. Select Refresh after changing the range or filters.
Message size is MIME size and can be materially larger than raw file size. For DSN code, use a complete code or 2.. for success, 4.. for transient failure, and 5.. for permanent failure.
Compare Direction, Sender, Recipients, Type, Subject, Last Status, Date, and Category. Processing and Queued for Delivery aren’t terminal outcomes. Delivery Successful means Sophos successfully handed the message off for delivery; final confirmation comes from the receiving provider’s trace. Investigate recipient events for Delivery Failed, TLS Delivery Failed, Bounced, Failed to return to M365, and Clawback Failed.
Interpret details and recipient events
Select the subject to open Message Details. Under Details, verify SMTP From, SMTP Recipients, Header From, Header Recipients, Category, Sub Category, and IP Address. Expand every affected recipient and read Date, Status, Reason, and Additional Details chronologically.
Hover over the three dots for additional SMTP data such as TLS use, TLS version, cipher, and processing host name. Assess the final state per recipient; success for one recipient doesn’t disprove failure for another. Correlate the timestamp, recipient, and SMTP response with Microsoft Message Trace, Google Email Log Search, or the relevant destination trace.
A category explains classification, not necessarily the cause of interrupted delivery. For Authentication failure, inspect SPF, DKIM, DMARC, Header anomaly, or Domain anomaly. Correlate Spam, Malware, Intelix threat, URL/QR Code, Impersonation, Data control, Secure message, and Legitimate with Sub Category, effective policy, and event reason. Realtime blocked, Admin blocked, and User blocked require inspection of the corresponding block source.
For a Phish Threat simulation email, Category: Legitimate with Sub Category: PT campaign means that Sophos Email recognized the message as part of a Phish Threat campaign. This isn’t proof of delivery. Match the recipient and timestamp to the campaign, then check the final recipient status and provider trace. If the email is missing or the history doesn’t end successfully, continue with the Sophos Phish Threat: troubleshoot delivery failures and bounces runbook.
Inspect headers, attachments, and URLs
Under Raw Header, use Copy raw headers to preserve complete headers, Search keyword to find names or values, and column sorting to follow the route. AI Analysis analyzes headers only, not content or attachments. Its SPF, DKIM, DMARC, alignment, missing-signature, spoofing, and forwarding summary is a lead; raw headers and DNS or provider data remain authoritative evidence.
Attachments shows Name, MIME-based Size, and possibly File group. File group appears only when a Data Control policy evaluated the attachment. A missing value therefore proves neither an unknown type nor a scanning error. Don’t open attachments on an ordinary administrator workstation.
URLs lists detected links, or displays No URLs. Export can preserve the list as CSV or PDF. Treat it as investigation data, not an invitation to click. Eligible spam messages may offer Report threat or Report clean; reporting improves classification but isn’t an immediate delivery fix.
URL display limitation: Message Details displays only the base URL. URL parameters are hidden to avoid exposing sensitive or personal values. A displayed URL without query parameters therefore doesn’t prove that the link in the original message contained no parameters. This limitation concerns the display; it establishes neither that Sophos removed parameters from the message nor which components were checked during security analysis.
For evidence, record whether a value came from Message Details, an export, or the original message. A screenshot of the URL list documents the display, not the complete original link. Don’t treat a CSV/PDF export as the original message without checking it either: inspect its contents and scope before sharing, rather than assuming that the export contains full URLs or suppresses specific parameters. If the investigation requires the original link, analyze the .eml message obtained and retained with authorization as text only in a designated investigation environment with authorized access, without clicking links or opening attachments.
For tickets and screenshots, initially collect only the displayed base URL together with the Message-ID, timestamp, and recipient event. Collect full links and query values only when they are necessary for the specific issue under investigation and their processing is authorized. Redact tokens, personal parameters, and unnecessary message data from the ticket copy; preserve any required original separately with restricted access. Don’t put full suspicious links into public URL checking services, chats, or unprotected tickets.
Investigate rejections and SMTP responses
Rejected report, also called the rejection log, contains messages rejected because a mailbox wasn’t found and recorded reasons such as Mailbox not found, TLS failure, Version mismatched, or Unencrypted. Filter by Rejection Reason, or use Advanced Search with From, To, and Sender Ip. Select Refresh after every change.
Hard boundary: Sophos neither quarantines nor retains a rejected message. It therefore can’t be released or resent. After correcting the recipient, TLS, or routing fault, the sender must send a new message. If Sophos detects more than 1,000 messages from one IP in five minutes, it temporarily stops logging further messages from that IP, raises an alert, and resumes after five minutes. A rejection-log gap may therefore be throttling and doesn’t prove that no connection attempts occurred.
For a temporary 4xx error, Sophos follows this exact retry cadence: the first attempt is immediate, the second is also immediate, then attempts follow after 5, 10, and 15 minutes. It then retries every 30 minutes for one hour and hourly thereafter. After 24 hours, Sophos stops trying and sends a bounce. A fatal 5xx error isn’t retried.
Use the exact Sophos response code to select the remediation:
| Code | Specific cause | Practical remediation |
|---|---|---|
| XGEMAIL_0001 | The message has no valid DKIM signature. | Correct signing, selector, and published DKIM key; then verify the signature and domain alignment before resending. |
| XGEMAIL_0002 | The message failed SPF. | Authorize the actual sending IP in the envelope domain’s SPF record and correct SPF syntax or lookup failures. |
| XGEMAIL_0003 | The message failed DMARC. | Make SPF or DKIM pass and align with the visible From domain; correct the sender’s DMARC configuration. |
| XGEMAIL_0004 | The sender IP failed an RBL test. | Check the IP for abuse or compromise, stop the cause, and then request delisting or send through a clean authorized relay. |
| XGEMAIL_0005 | The sender domain failed a DBL test. | Check the domain and message URLs for compromise or bad reputation, remediate them, and then request delisting. |
| XGEMAIL_0006 | The TLS version doesn’t match the configured policy. | Configure the sending server and policy to share an allowed TLS version; don’t disable required TLS merely to bypass the rejection. |
| XGEMAIL_0007 | The Sophos Email license has expired. | Renew or reactivate the correct tenant’s license and confirm that protection is active before retrying. |
| XGEMAIL_0008 | The domain, IP address, or email address is on the administrator block list. | Verify the match and, if authorized, remove or narrow the corresponding administrator block entry. |
| XGEMAIL_0009 | The domain, IP address, or email address is on the user’s block list. | Have the recipient verify and remove or narrow the matching user block entry. |
| XGEMAIL_0010 | The recipient domain isn’t protected by Sophos Email. | Correct the address or add and verify the domain and its routing in the intended Sophos Email tenant. |
| XGEMAIL_0011 | The recipient address doesn’t exist in the protected domain. | Correct the address or create/synchronize the mailbox or user, then confirm recipient validation. |
| XGEMAIL_0012 | The message exceeds the allowed size. | Reduce the MIME message or attachment size, or use an approved file-sharing method, and send again. |
| XGEMAIL_0013 | A large message exceeds the maximum permitted recipient count. | Reduce or split the recipient list and resend the smaller batches. |
| XGEMAIL_0014 | One sender exceeded the recipient’s inbound rate limit. | Stop the burst, wait for the limit window to clear, and resume at a lower rate. |
| XGEMAIL_0015 | All senders together exceeded the recipient’s total inbound rate limit. | Investigate a traffic surge or flood, wait for the limit to clear, and reduce aggregate inbound volume. |
Save, schedule, and export reports
After applying and verifying the required filters, select Save as Custom Report. For Processed report, this saves a custom report from the Message History template on the Reports page; for Rejected report, it uses the Email Rejection Report template. Open the saved custom report on Reports to configure its schedule and recipients.
For a filtered rejection record, set a range of up to 30 days, or up to 90 days with Sophos Email Plus, apply Rejection Reason and any Advanced Search criteria, select Refresh, and verify the result. Then select Export as CSV. The downloaded CSV contains the filters that were applied at export time; record the range and time zone with the evidence.
Choose eligible remediation and validate it
Redeliver email is available only with Sophos Email Plus for inbound messages successfully accepted by Sophos within the last 90 days and only in these supported states: Delivery Successful, Delivery Failed, Returned to M365, Failed to Return to M365, Clawback released, or TLS Delivery failed. Rejected messages are never eligible. If the original was already delivered, redelivery creates a new email with the original attached, so account for duplicates first.
Use Initiate clawback only for successfully delivered inbound messages in mailboxes belonging to a domain connected for Post-Delivery Protection, with On demand clawback enabled. Follow each recipient under Additional Details to Clawback Successful or Clawback Failed, then verify the item in post-delivery quarantine. Provider processing can take up to ten minutes. A message or internal copy can be clawed back only once; after release from post-delivery quarantine, it can’t be clawed back again.
After remediation, repeat the same search and validate the message, recipient, and terminal state against the external trace and destination mailbox. A missing row alone isn’t proof of success: date range, filters, or retention can produce the same result.
Isolate common failures and escalate
- No result: check tenant, report, 30/90-day boundary, direction, Type, envelope address, and Refresh; remove criteria one at a time.
- Inbound policy appears ineffective: compare the recipient event and assigned policy, then check user and administrator entries in Inbound Allow/Block. Don’t create a broad exception as a diagnostic shortcut.
- Delivery is queued: monitor the 4xx response and next attempt. For 5xx, correct the recipient, authentication, TLS, size, or rate-limit cause and arrange a new send.
- Delivery Successful, but no receipt: search the provider trace by time and Message-ID, then inspect its quarantine, rules, forwarding, and mailbox state.
- UCEPROTECT rejection: contact the rejecting recipient or operator and ask them not to use UCEPROTECT as an RBL, DNSBL, or IP check. Don’t pay for delisting.
- Suspected misclassification: for Sophos Email, prefer Smart Banners, Message History, or the Sophos Outlook add-in; when offered in details, use Report threat or Report clean.
For escalation, collect tenant ID, UTC range, SMTP and header addresses, subject, Message-ID, direction, Type, category and subcategory, complete recipient events, SMTP/DSN code, raw headers, provider trace, policy name, and screenshots. For an apparently unapplied policy, add the delivered message in .eml format where privacy rules permit and the incident history. Never put passwords, tokens, or unnecessary message data in the ticket.