How to Use Message Trace for BEC Investigations

The finance manager says she never approved the wire. The vendor swears the banking-change request came from the right email thread. By the time anyone notices, the attacker has already hidden half the replies with a mailbox rule. This is where Message Trace stops being a “mail admin feature” and turns into one of the most useful tools in a real business email compromise case.

In a proper BEC Investigation, Message Trace helps you answer the first hard questions fast: did Microsoft 365 receive the message, who got it, was it delivered or quarantined, and did the compromised mailbox send anything else out? That is the difference between a messy theory and a usable timeline.

If your runbook still points people to ancient screenshots of classic Exchange pages, bin it. As of March 29, 2026, the practical workflow is the modern Exchange admin center, with the Defender portal acting as a shortcut into the same experience. The tool is solid. The problem is that a lot of teams use it far too late, far too broadly, or for the wrong questions.

What is Message Trace?

Message Trace is Microsoft 365’s transport-level record of what happened to an email as it moved through Exchange Online. During a BEC investigation, it tells you whether the service received the message, what status it hit, who it touched, and what happened before final delivery or failure.

That makes it excellent for Email Tracking, scoping blast radius, and confirming whether a “missing” email really vanished or just landed somewhere unpleasant. It can show statuses like delivered, failed, pending, quarantined, filtered as spam, or the wonderfully unhelpful but still real “getting status.”

It is also time-sensitive. For newer mail, results are near real time. In practice, mail can take around five to ten minutes to show up in trace data after it is sent, which matters during active incident response when everyone is refreshing like their keyboard owes them money.

It is not a full forensic record of mailbox behavior. Message Trace shows email flow through the service. It does not prove whether the attacker read the message, created the inbox rule, or logged in from a suspicious device. That is where mailbox auditing, Purview audit data, sign-in logs, and other M365 Logs come in.

• Use Message Trace to answer: Did the email arrive, where did it go, and who else got a copy?
• Use it again to answer: Did the compromised mailbox send similar mail outward?
• Do not use it alone to answer: Who logged in, who changed mailbox settings, or who read the message after delivery?

Concept Overview

Think of Message Trace as transport evidence, not full compromise evidence. It is brilliant for scoping suspicious email flow and fast Email Analysis, but it will not tell you who created a forwarding rule, whether a delegate was involved, or whether a user approved a shady app consent prompt on their phone at 11:47 p.m.

A lot of articles get this wrong. They treat Message Trace like the whole truth. It is not. It is the mail-flow ledger. That sounds less glamorous, but in real cases it is exactly what you need first.

Why this matters in practice: if finance got one spoofed invoice email, you have a phishing event. If finance, payroll, and the CFO’s assistant all got the same thread-hijack message, you have a much bigger operational problem. Message Trace helps you separate those two realities quickly.

One useful detail many teams forget is the original client IP. For recent data, downloadable reports can include that field, and it can be extremely helpful when a compromised mailbox starts sending outbound mail. But it is not available forever, and it is not surfaced the same way in every report. If you wait two weeks and then go hunting for that breadcrumb, you may be out of luck.

Another practical tip: if you can get the message header from the reported email, do it early. Filtering by sender plus a short time range is good. Filtering by message ID is better. Filtering by the right message identifier in a crowded incident is the difference between a clean answer and a swamp.

• Warning sign: suspicious mail delivered to multiple finance or executive recipients within a tight window
• Warning sign: outbound bursts from one mailbox to vendors, free-mail accounts, or external contacts after hours
• Warning sign: user says replies disappeared, but trace shows delivery succeeded
• Warning sign: the same subject line appears across internal and external recipients with slightly different sender details

Prerequisites & Requirements

Before you touch Message Trace, gather enough context to stop the search turning into digital archaeology. The tool works best when you already have a sender, recipient, time window, and some idea of whether you are chasing inbound phishing, outbound abuse, or both.

• Data sources: user report, original suspicious email header, sender and recipient addresses, approximate date and time, subject fragments, related vendor thread details, mailbox audit data, sign-in logs, and any relevant Exchange Online logs already collected in your case notes
• Infrastructure: access to the Exchange admin center or Defender portal, time zone awareness for the tenant and the investigator, and Exchange Online PowerShell if you need deeper filtering or historical exports
• Security tools: Defender for Office 365 or equivalent mail security tooling, SIEM, endpoint telemetry, case management, and a place to preserve exported CSV evidence
• Team roles: messaging admin, security analyst, incident lead, and the mailbox owner’s business stakeholder such as finance, HR, or executive support

Permission matters too. Depending on where you access it, Message Trace usually requires Exchange role groups or the appropriate Microsoft Entra admin roles. Least privilege still applies. You do not need to hand out Global Administrator like party favors just because someone wants to investigate mail flow.

If you prefer PowerShell, use the current V2 cmdlets. The older Message Trace UX and cmdlets are deprecated, so make sure your internal docs are not still living in 2024.

Step-by-Step Guide

The fastest way to use Message Trace in a live incident is simple: anchor the suspicious email, expand to related messages, inspect outbound abuse, then correlate with other logs that explain what the attacker changed. The mistake is starting with giant vague searches and producing a giant vague mess.

Step 1: Build the timeline first

Goal: Establish a narrow, trustworthy window around the reported activity.

Checklist:

• Confirm the reporter’s local time and date
• Note sender, recipient, subject, and any known attachment or link theme
• Account for tenant time zone and investigator time zone differences
• Remember there can be a short delay before fresh messages appear in trace data

Common mistakes: Searching a 24-hour window because the user said “this afternoon,” mixing UTC and local time, or assuming an empty result means no email existed when it may simply be too new.

Example: An accounts payable user reports a fake vendor request “around 2 p.m.” You confirm it was 2:07 p.m. Cairo time, then search a tight window from 1:50 to 2:20. That alone can cut your noise by 90 percent.

Step 2: Find the original suspicious email

Goal: Confirm whether Microsoft 365 received the message and how it was handled.

Checklist:

• Search by recipient and narrow time range first
• Add sender, subject, or message ID if you have them
• Record delivery status, timestamps, and any useful identifiers
• Check whether the message was delivered, quarantined, filtered, failed, or still pending

Common mistakes: Searching only by subject, ignoring small sender variations, or assuming “not in Inbox” means “not delivered.” In real cases, the email may have been delivered and then hidden by a rule five minutes later.

Example: The fake banking-change email was delivered not just to one clerk but to two shared finance mailboxes. That changes your scoping, your comms, and probably the urgency of the call you make next.

Get-MessageTraceV2 -RecipientAddress [email protected] -StartDate "03/27/2026 13:50" -EndDate "03/27/2026 14:20" -Subject "bank details"

Step 3: Pivot to related messages and recipient spread

Goal: Identify other copies, adjacent recipients, and thread-related mail.

Checklist:

• Search the same sender across nearby recipients
• Search the same recipient cluster across nearby times
• Use message ID where available for cleaner pivots
• Check distribution groups and shared mailboxes, not just the original reporter

Common mistakes: Stopping after the first hit, forgetting that an executive assistant or shared mailbox was copied, or ignoring the possibility that one message fan-out created multiple related traces.

Example: What looked like a single phish to finance turns out to have reached payroll and the CFO’s assistant through a group expansion. Suddenly you are not handling a lone user complaint. You are handling executive-adjacent fraud exposure.

Step 4: Hunt for outbound abuse from the compromised mailbox

Goal: Determine whether the attacker used the mailbox to contact internal or external targets.

Checklist:

• Switch your thinking from inbound to outbound
• Search sender equals compromised mailbox over the relevant period
• Look for spikes, unusual external recipients, or messages sent outside business hours
• Pull downloadable reporting early if you may need original client IP details

Common mistakes: Focusing only on the initial phishing email, skipping outbound review because the user “does not see anything in Sent Items,” or waiting too long to request the richer downloadable data.

Example: A compromised controller mailbox sends fourteen messages between 2:11 a.m. and 2:19 a.m., including one to a personal Gmail address before messages go to vendors. That small test message is the kind of detail attackers hope you will never notice.

This is one of the most useful real-world uses of Message Trace during a BEC case. It shows whether the attacker merely landed in the mailbox or actually weaponized it.

Step 5: Correlate with other logs

Goal: Link suspicious email flow to the mailbox changes and account activity that made it possible.

Checklist:

• Review current inbox and forwarding rules
• Search audit data for mailbox rule creation or modification
• Check sign-in activity around the same period
• Use Defender data if available for related message clustering and detections

Common mistakes: Expecting Message Trace to tell you who created the rule, who read the reply, or whether a token was abused. That is not a Message Trace failure. It is just the wrong question for the tool.

Example: Message Trace shows vendor replies were delivered correctly. Mailbox auditing then shows an inbox rule moved matching replies out of the Inbox. Suddenly the mystery of the “disappearing approvals” is no longer much of a mystery.

Get-InboxRule -Mailbox [email protected] | FL Name,Description,DeleteMessage,MoveToFolder,Enabled Search-UnifiedAuditLog -StartDate "03/27/2026" -EndDate "03/29/2026" -UserIds [email protected] -Operations New-InboxRule,Set-InboxRule,Remove-InboxRule -ResultSize 1000

Step 6: Preserve evidence and turn findings into containment

Goal: Keep the evidence clean enough to support containment, reporting, and follow-on review.

Checklist:

• Export trace results to CSV when useful
• Document timestamps, delivery status, and affected recipients
• Capture message IDs or trace IDs tied to your case
• Coordinate resets, session revocation, rule cleanup, and external notifications

Common mistakes: Relying on screenshots alone, failing to preserve UTC and local time references, or forgetting to notify external partners who are still sitting inside the hijacked thread.

Example: You confirm the attacker replied inside a live vendor chain. Finance resets the mailbox, security removes the rule, and procurement warns the vendor before the attacker gets another shot. That is what “useful evidence” looks like.

Workflow Explanation

In a real case, Message Trace works best as a pivot engine. You start with one suspicious message, pivot to every related inbound and outbound email, then hand that timeline to audit and sign-in data to explain what the attacker changed. That sequence is faster and far more reliable than guessing from screenshots.

1. A user gets phished, reuses a password, or approves something they should not have approved. Very normal human behaviour, unfortunately.
2. The attacker lands in the mailbox, studies active threads, and may create a forwarding or inbox rule.
3. A legitimate vendor or colleague email arrives, and the attacker replies inside the existing conversation.
4. The recipient trusts the thread because the context is real, the timing is believable, and nobody expects fraud at 4:42 on a Friday.
5. Message Trace confirms the inbound mail, the related recipients, and any outbound replies from the compromised mailbox.
6. Audit and sign-in data explain the mechanism: login source, rule creation, forwarding changes, or other mailbox activity.

This is why Message Trace matters so much during a thread-hijack case. It gives you the transport map. Without that map, teams often waste time arguing over whether the email was spoofed, forwarded, or “just disappeared.” Magic is not a root cause.

One edge case worth calling out: if the compromise is mostly OAuth or consent abuse and the attacker did not actually send or route suspicious email through Exchange, Message Trace may not have much to show. That does not mean the account is clean. It means you need to pivot harder into audit and sign-in evidence.

Troubleshooting

Most Message Trace pain during incident response comes from ordinary issues: the search is too broad, the time range is wrong, the mail is too new, or the investigator is asking a transport tool to answer a mailbox question. Fix those first and the whole process gets much less annoying.

Problem: The suspicious email does not appear in the results.
Cause: The search window is wrong, the message is too new, or the recipient was not what you expected.
Fix: Recheck time zone, narrow the window, confirm recipient addresses, and allow a few minutes for fresh messages to appear.

Problem: Trace shows “Delivered,” but the user says the mail vanished.
Cause: Inbox rule, forwarding rule, folder move, or delegate action after delivery.
Fix: Check current rules, review mailbox audit activity, and inspect hidden or unusual folders.

Problem: You only see part of the campaign.
Cause: You searched one mailbox or one recipient and stopped there, or the message expanded to groups and shared mailboxes.
Fix: Pivot across related recipients, group members, shared mailboxes, and nearby timestamps.

Problem: You need client IP detail but cannot find it.
Cause: You are looking at the wrong report type, or the data is older than the window where that detail is available.
Fix: Pull the richer downloadable report early in the case if outbound abuse is suspected.

Problem: The query times out or returns too much noise.
Cause: The search is too broad.
Fix: Use sender plus recipient plus a tight time range, or better yet use the message ID if you have it. PowerShell can also be easier for stubborn cases.

Problem: Nothing suspicious appears in Message Trace, but the mailbox still looks compromised.
Cause: The attacker may have used mailbox access, rule abuse, or app consent without sending traceable email during your window.
Fix: Pivot to audit logs, sign-in logs, delegate permissions, forwarding settings, and app consent review.

Security Best Practices

Message Trace is not just for investigation after the fire starts. In strong Email Security programs, it becomes the fast confirmation layer inside a bigger response process. In weaker ones, it becomes the emergency shovel everyone reaches for after the fraud team is already panicking.

• Document your team’s standard time zone handling so incidents do not turn into timestamp arguments.
• Include shared mailboxes, finance aliases, executive assistants, and distribution groups in your routine scoping.
• Review suspicious forwarding and inbox rules as a default step, not a “maybe later” step.
• Practice the workflow before the real incident. Nobody wants to learn their Message Trace process during a live payroll fraud attempt.

Resources

If you are building a fuller OmiSecure-style runbook, these are the next posts that usually make sense to link internally:

• Microsoft 365 Account Takeover Response
• Investigating Suspicious Exchange Inbox Rules
• Spot Microsoft 365 Takeover Signs Early

Wrap-up

When a mailbox is tied to fraud, thread hijacking, or missing replies, Message Trace gives you the fastest trustworthy view of what happened to the email itself. That is why it belongs near the front of your incident response process, not buried halfway down a generic Microsoft 365 checklist.

Use it to prove transport facts, scope recipients, and catch outbound abuse. Then hand off to audit logs, sign-in review, and containment actions for the rest of the story. That is the practical way to run a BEC investigation without wasting half the day debating what Outlook “seemed to show.”

Frequently Asked Questions (FAQ)

Can Message Trace tell me whether an attacker read or deleted an email after delivery?

No. Message Trace shows transport events in Exchange Online. If you need to know whether a message was moved, deleted, or hidden after delivery, check mailbox auditing and related audit records.

How far back can I use Message Trace in Microsoft 365?

Message Trace data is retained for 90 days. Newer data is easier to query quickly, while older searches often rely on downloadable historical reporting and may take longer to return.

What is the fastest way to search for one suspicious message?

Start with recipient plus a tight time window, then add sender, subject, or message ID. If you have the original message header, that usually gives you the cleanest pivot.

Why would Message Trace show “Delivered” if the user never saw the email?

Because delivery to the service is not the same as visibility in the Inbox. Inbox rules, forwarding, folder moves, delegate actions, and client-side sorting can all make a delivered message seem to disappear.

Should I use the Defender portal or the Exchange admin center for Message Trace?

Either is fine operationally, but the Defender portal route effectively opens Message Trace in the modern Exchange admin center. The bigger point is consistency: pick one workflow and train your team on it.