When someone says “I never got that email” or “did my message actually send?”, message trace is how you get a real answer instead of a guess. It’s the mail-flow log built into Exchange Online, and it tells you exactly what happened to a message after it reached Microsoft: whether it was delivered, is still pending, bounced, or got pulled into quarantine.
Most traces take under a minute. The skill is reading the result correctly — knowing what each status really means, when to switch to a detailed trace, and how to handle mail older than the standard window. This guide covers all of that, plus the everyday cases where a trace settles an argument fast.
Before you start
You need the right access and a few details about the message, or you’ll waste time scrolling through unrelated results.
Before you run a trace
- You have an admin role with message tracking (Exchange Administrator is enough)
- You know the sender or recipient address (even one side helps)
- You have a rough date and time the message was sent
- You know whether the mail is newer or older than ~10 days
- You've confirmed the message involved Exchange Online (not a purely external hop)
Where message trace lives
- Sign in to the Exchange admin center (
admin.exchange.microsoft.com). - In the left menu, go to Mail flow → Message trace.
- Click Start a trace.
You’ll set the sender, recipient, date range, and delivery status, then run it. Keep the filters as narrow as you reasonably can — a wide-open trace across all senders for a busy tenant returns a wall of rows that’s hard to read.
Reading the delivery statuses
The status column is where people misread results. Here’s what each one actually tells you.
Message trace statuses, plain English
| Delivered | Exchange Online handed the message to the destination mailbox or onward server. It arrived — though an inbox rule could still have filed or deleted it after. |
|---|---|
| Pending | Accepted but not yet delivered. Usually the receiving side is deferring or retrying. Often clears on its own. |
| Failed | Delivery was rejected. The sender typically got a non-delivery report (NDR) with an error code explaining why. |
| Quarantined | Held by spam or malware filtering. Not bounced — it's waiting in quarantine for release or review. |
| Filtered as spam | Delivered, but routed to Junk by spam filtering rather than blocked outright. |
| Expanded | The message went to a distribution group and was split out to the individual members. |
The two that cause the most confusion are Delivered and Quarantined. Delivered does not mean “read” and does not mean “in the Inbox” — a message moved to Junk or eaten by a client-side rule still shows Delivered. Quarantined is not a bounce; the mail still exists and can be released. Treating a Quarantined result as “lost” sends people down the wrong path.
Running a detailed trace for older mail
For anything older than about 10 days, you run an extended trace and read the result as a report rather than a live grid.
- In Message trace, set the date range to include the older dates (this flips it to the extended type automatically).
- Fill in whatever sender/recipient detail you have to keep the report focused.
- Choose to include the enhanced detail / extended report options when prompted.
- Submit the trace. It’s queued, not instant.
- Come back to Message trace later — the finished report appears in the list of downloadable results, often as a CSV you can open in Excel.
Reading the detailed event log
For a recent message, click into a single result to open its detail view. Below the summary is a chronological event log — the play-by-play of what Exchange Online did with the message. This is where you find the actual reason behind a status.
Events you’ll commonly see:
- Receive — the message arrived at Exchange Online.
- Submit — it was handed to the transport pipeline.
- Deliver — it reached the destination mailbox.
- Defer — delivery was paused and will be retried (this is what sits behind a Pending status).
- Fail — delivery was rejected, with a reason and often a remote server response.
- Resolved / Expanded — the recipient resolved to a mailbox or expanded from a group.
- Spam / Quarantine — filtering acted on the message.
The most useful detail in a Failed or Pending event is the remote server response — the raw
SMTP error the other side returned, like 550 5.4.1 Recipient address rejected or a throttling
notice. That text usually tells you whether the problem is on your side, theirs, or a bad
address. When the log points at recurring delivery failures or mail not leaving the tenant at
all, the broader checklist in
Microsoft 365 email not sending or receiving
walks through the DNS and mail-flow causes behind those errors.
Common uses for a trace
A few scenarios cover most of why you’d open message trace in the first place:
When to reach for a trace
| "I never got the invoice" | Trace by sender + recipient. A Delivered status points at the recipient's rules or Junk; nothing found means it never arrived. |
|---|---|
| "My replies are bouncing" | Trace outbound by recipient. The Failed event's remote response gives the exact rejection reason. |
| "Did the newsletter reach everyone?" | Trace by sender across recipients to see who got Delivered vs Filtered vs Failed. |
| "Is mail being delayed?" | Look for Pending/Defer events and read the retry reason in the event log. |
| Spoofing / phishing review | Trace a suspicious sender to see whether messages were Quarantined or Delivered, then tighten policy. |
Quick checklist for a clean trace
When a trace comes back empty or confusing, run through this before concluding anything:
- Double-check the address spelling — a trace on the wrong alias returns nothing.
- Widen the date/time range slightly; senders are often off about when they sent it.
- Confirm you’re on the right side — trace by recipient for inbound problems, sender for outbound ones.
- If the mail is older than ~10 days, switch to an extended trace.
- Empty result + correct details usually means the message never reached Exchange Online — the problem is upstream of your tenant.
Wrapping up
Message trace turns “I think it sent” into a documented timeline. Run a real-time trace for anything in the last 10 days, switch to an extended report for older mail, and read the status carefully: Delivered means it left Exchange Online (not that it was read), Pending usually clears itself, Failed comes with an error you can act on, and Quarantined mail is held, not lost. When a status alone doesn’t explain things, the event log and its remote server responses almost always do.
If your traces keep surfacing delivery failures or missing inbound mail, pair this with the mail-flow fixes in Microsoft 365 email not sending or receiving, and if the trouble is around a team address, confirm the setup in our shared mailbox guide.
