Part 7: Message Delivery Troubleshooting & Forensics

A message marked Delivered is not necessarily visible in the recipient’s Inbox. A message missing from one transport server’s logs is not necessarily missing from the organisation. Effective troubleshooting depends on understanding what each evidence source proves—and where its visibility ends.

In Part 7 of the Microsoft 365 Architecture & Exchange Enterprise Deep Dive series, we bring together Exchange Online message trace, Exchange Server message tracking and Microsoft Defender XDR email telemetry. The objective is a defensible timeline: who submitted the message, which systems processed it, what happened for each recipient, and whether a later security action changed its location.

1. Define the investigation before searching

Start with one message and one affected recipient. A report such as “external email is delayed” is useful operational context, but it is not a searchable case definition. Distribution groups, forwarding and recipient-specific filtering can produce different outcomes from the same submission.

Collect the sender and recipient addresses, approximate submission time, time zone, subject and original Internet Message-ID where available. Request the complete non-delivery report if one exists, including its diagnostic information. Preserve the original message and headers rather than relying only on screenshots or a forwarded copy.

Keep identifiers distinct. The Internet Message-ID is a message header value and is useful for correlation, but it is not guaranteed to identify one unique submission. Exchange Online’s MessageTraceId identifies a trace record. Exchange Server’s InternalMessageId is server-specific. Microsoft Defender XDR provides NetworkMessageId for correlating its email records. Do not substitute one identifier for another simply because two fields contain GUID-like values.

Finally, check whether the relevant evidence is still available. Exchange Online message trace supports searches within the previous 90 days; Get-MessageTraceV2 accepts a maximum ten-day interval per query. Exchange Server tracking availability depends on local logging and retention configuration. Defender hunting has its own data availability and retention boundaries.

2. Establish the Exchange Online transport outcome

For mail that passes through Exchange Online, begin with message trace in the Exchange admin centre under Mail flow. Search by sender, recipient and time, then open the relevant result to inspect its events. The summary status is a starting point; the detailed event sequence is the stronger diagnostic evidence.

For repeatable investigations, use Get-MessageTraceV2 and Get-MessageTraceDetailV2 from the Exchange Online PowerShell module. Use an account with the appropriate Exchange permissions. The following example searches a fixed UTC window; replace the dates with a recent incident window within the supported retention period.

Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline

$start = [DateTimeOffset]::Parse('2026-01-15T09:00:00Z').UtcDateTime
$end = [DateTimeOffset]::Parse('2026-01-15T11:00:00Z').UtcDateTime

$trace = Get-MessageTraceV2 `
    -SenderAddress 'sender@partner.example' `
    -RecipientAddress 'recipient@contoso.com' `
    -StartDate $start `
    -EndDate $end

$trace | Select-Object Received, SenderAddress, RecipientAddress,
    Subject, Status, MessageId, MessageTraceId

Select the matching result using the timestamp and identifiers, not merely the subject. If the query returns many records, narrow the window or follow the cmdlet’s documented continuation approach. Do not treat a result-limited response as a complete inventory.

$selected = $trace | Where-Object {
    $_.MessageId -eq '<original-message-id@partner.example>'
}

foreach ($item in $selected) {
    Get-MessageTraceDetailV2 `
        -MessageTraceId $item.MessageTraceId `
        -RecipientAddress $item.RecipientAddress `
        -StartDate $start `
        -EndDate $end |
        Select-Object Date, Event, Detail, Data
}

Interpret the events against the destination. A successful hand-off to another SMTP system establishes acceptance at that boundary, not placement in a downstream Inbox. Likewise, a Delivered summary does not establish that the message remained in the Inbox or was read. Review filtering and delivery details before declaring the investigation complete.

For failures or delays, preserve the exact diagnostic response, destination and event time. Distinguish temporary deferral from permanent rejection. For expanded groups or redirected messages, follow the resulting recipient paths separately. If no result appears, recheck the address, time conversion, retention boundary and whether the message actually entered Exchange Online.

3. Bridge the hybrid boundary with message tracking

In hybrid environments, Exchange Online evidence describes only part of the route. Exchange Server message tracking logs record transport activity on the servers that process the message. Search every relevant Mailbox server rather than assuming that the server hosting the destination mailbox also handled the original SMTP connection.

Run the following example in the Exchange Management Shell. Replace the server names and message identifier. The UTC boundaries are converted to local DateTime values for the search; record the shell host’s time zone and use consistent time handling across the investigation.

$startUtc = [DateTimeOffset]::Parse('2026-01-15T09:00:00Z').UtcDateTime
$endUtc = [DateTimeOffset]::Parse('2026-01-15T11:00:00Z').UtcDateTime
$servers = @('EX01', 'EX02')

$tracking = foreach ($server in $servers) {
    try {
        Get-MessageTrackingLog `
            -Server $server `
            -Start $startUtc.ToLocalTime() `
            -End $endUtc.ToLocalTime() `
            -MessageId '<original-message-id@partner.example>' `
            -ResultSize Unlimited `
            -ErrorAction Stop |
            Select-Object @{Name='QueriedServer'; Expression={$server}},
                Timestamp, EventId, Source, Sender, Recipients,
                MessageId, InternalMessageId, NetworkMessageId,
                ConnectorId, RecipientStatus, Reference
    }
    catch {
        Write-Warning "Tracking search failed on ${server}: $($_.Exception.Message)"
    }
}

$tracking | Sort-Object Timestamp

An unavailable server is a coverage gap, not a negative result. If Edge Transport servers participate in the route, collect their evidence separately as required. Also confirm that message tracking was enabled and the relevant log files have not expired or been removed.

Read event identifiers together with their source and recipient information. RECEIVE shows receipt by a transport component; SEND records an SMTP send to another transport service; DELIVER records delivery to a local mailbox. FAIL and DEFER identify failed or delayed processing. Group expansion and message transfer events can introduce additional branches that must be followed.

Correlate the Internet Message-ID with sender, recipient and time across systems. Within Exchange Server tracking, NetworkMessageId helps follow copies created through bifurcation or distribution group expansion. Do not use InternalMessageId as an organisation-wide key: its value changes between servers.

Where tracking establishes the boundary but not the SMTP exchange, inspect existing connector protocol logs. They provide SMTP conversation evidence when protocol logging was enabled. Enabling logging after an incident cannot reconstruct an earlier conversation, so distinguish historical findings from a controlled reproduction.

4. Separate initial delivery from later security actions

Microsoft Defender XDR advanced hunting adds security context where the relevant Microsoft Defender for Office 365 data is available. An empty query result is not automatically evidence that no security processing occurred: check permissions, service coverage and the hunting retention window first.

Use EmailEvents to locate the message and examine its recorded delivery action, delivery location and detection information. The envelope and visible sender fields are deliberately separate in this query.

EmailEvents
| where Timestamp between (datetime(2026-01-15T09:00:00Z) .. datetime(2026-01-15T11:00:00Z))
| where InternetMessageId == '<original-message-id@partner.example>'
| where RecipientEmailAddress =~ 'recipient@contoso.com'
| project Timestamp, NetworkMessageId, InternetMessageId,
    SenderFromAddress, SenderMailFromAddress, RecipientEmailAddress,
    DeliveryAction, DeliveryLocation, ThreatTypes, DetectionMethods
| order by Timestamp asc

Take the NetworkMessageId from the matching record and examine EmailPostDeliveryEvents. This table records supported post-delivery security actions, including actions associated with zero-hour auto purge and manual remediation. Use a broader end time than the original delivery search because remediation can occur later.

EmailPostDeliveryEvents
| where Timestamp between (datetime(2026-01-15T09:00:00Z) .. datetime(2026-01-17T09:00:00Z))
| where NetworkMessageId == 'replace-with-network-message-id'
| where RecipientEmailAddress =~ 'recipient@contoso.com'
| project Timestamp, NetworkMessageId, InternetMessageId,
    RecipientEmailAddress, Action, ActionType, ActionResult,
    DeliveryLocation, ThreatTypes, DetectionMethods
| order by Timestamp asc

Check ActionResult before describing a remediation as successful. A recorded action and a completed action are not interchangeable. Keep the recipient filter because one message can have different outcomes across recipients.

These tables are not a complete history of every mailbox move, deletion or user action. If transport confirms delivery and the security evidence does not explain the disappearance, continue with a separately scoped mailbox investigation. Do not convert an absence of post-delivery security events into a claim that the user deleted the message.

5. Preserve evidence and write a bounded finding

Headers help explain the route observed by the receiving system. Read Received fields from the bottom upwards to follow the asserted sequence, but establish which receiving infrastructure added each field. Do not treat every header supplied with an incoming message as equally trustworthy.

Authentication-Results can explain SPF, DKIM and DMARC evaluation at a receiving boundary. Those results are not delivery receipts. Equally, neither a message trace status nor an authentication result alone proves that every transport hop met a particular TLS policy. Where transport security is disputed, examine the relevant connection evidence and configuration separately.

Build a timeline with five elements: timestamp and time zone, system, event, correlation identifiers, and interpretation. Preserve raw exports alongside the narrative. Record the queries, filters, collection time and servers searched so another engineer can reproduce the investigation and identify coverage gaps.

Keep confirmed facts separate from hypotheses. A useful finding is: “Exchange Online recorded delivery at 09:14 UTC. Microsoft Defender XDR subsequently recorded a successful post-delivery security action for the same NetworkMessageId and recipient at 09:27 UTC.” This is stronger than “Exchange lost the message” because every statement has an identifiable evidence source.

Store exports and original messages in an approved, access-controlled location. Addresses, subjects, headers and message content may contain sensitive information. Share redacted working copies where appropriate, while retaining the originals according to organisational evidence-handling requirements.

6. Operational checklist

7. Conclusion: prove the boundary, then follow the evidence

Reliable delivery troubleshooting is a sequence of bounded questions: was the message accepted, where was it transferred, what happened for this recipient, and did anything change after delivery? Exchange Online message trace, Exchange Server tracking and Microsoft Defender XDR answer different parts of that sequence.

Use them together without stretching their meaning. The result should be a reproducible explanation of the message’s journey, not merely a plausible story. That discipline also provides a sound operational baseline for Part 8, where the series turns to Exchange Server Subscription Edition.

Message trace in the modern Exchange admin centre

Get-MessageTraceV2: parameters, search windows and result handling

Get-MessageTraceDetailV2: detailed trace events

Search message tracking logs in Exchange Server

EmailEvents advanced hunting schema

EmailPostDeliveryEvents advanced hunting schema

Originally published on Solution Savy. Need help with this? Book a consultation.