Microsoft 365 / Troubleshoot missing email with message trace

If emails do not arrive in Exchange Online, first collect the sender and recipient email addresses and the sending time, then search in the Exchange admin center under [Mail flow] → [Message trace]. Message tracing is the starting point to check whether Microsoft 365 received the mail, and whether it was queued, rejected, or delivered.

Information needed before the search

• Exact email addresses of the sender and recipient
• Date, time, and time zone of sending, with an approximate allowable range
• If there is a non-delivery report (NDR, also called a bounce message), the error code and body
• If you have the mail subject or message ID, collect only the details needed to identify the message

There is no need to request the entire body of the email sent to the customer. First, narrow down the range by address and time, and handle only the minimum necessary information.

Prepare permissions and the search period

You need the Exchange Administrator role or appropriate Exchange Online permissions to run a message trace. Simply being a regular user who sends emails or a Microsoft 365 license administrator does not grant tracking permissions. Instead of giving global administrator rights to everyone for queries, have an approved mail operations person conduct the investigation.

The retention period for message trace data is 90 days by default and is not configurable. Currently, summary queries allow a maximum search period of 10 days at a time within the 90-day range. Search intervals longer than 10 days require a downloadable Enhanced summary or Extended report. Check the report type on the search screen. Note that generating a download request can take several hours, so absence of immediate results does not mean the email did not exist.

If data is not visible immediately after sending, query again shortly afterward under the same conditions. Microsoft FAQ states that it may take about 5–10 minutes for tracking data to appear. This does not indicate the delivery delay time for all emails. For operations requiring long-term history storage, manage necessary reports separately according to your organization's information retention policies.

Run a message trace

1. Enter the Exchange admin center with the necessary administrative privileges and open [Mail flow] → [Message trace].
2. Set the sender, recipient, and time range. If the time doesn't match, check the time zone provided by the user and expand the range slightly.

3. Check the status and recipient address in the results. If there are multiple messages with the same subject, distinguish them by message ID and time.
4. Open the target message and read the event flow and final status. You can check the meaning of the status in Microsoft's Exchange admin center Message Trace documentation.

Example of finding a single case by address and time

Assume an external client said it was sent at '9:20 AM'. First, confirm whether the sender's time zone is Korean time, and confirm the exact address the sender used: an individual address, a shared address, or a group address. Do not search using only the display name in the address book.

1. Enter the external sender and the actual recipient address to start tracking. Initially, set the delivery status to 'All' so that failed or quarantined results are not excluded.
2. The custom time-zone setting applies to both the search inputs and the displayed results. Adjust it and select a small interval that includes both before and after the incident. Start with a one- or two-hour interval and expand it based on evidence.
3. Cross-check the address, time, size, and message identification information of the results. Resent emails with the same subject may be mixed with the originals.
4. Open the necessary results to read detailed events such as receipt, policy processing, or forwarding. Do not draw conclusions based on other messages that only have the same subject.

Server responses in Non-Delivery Reports (NDRs) and the Message-ID of the original message help narrow down the target. The Internet Message ID and the tracking ID shown by the tracking tool may be different items, so record which value is which. If there are too many results or a timeout occurs, reduce the sender, recipient, or period and search again.

How do you interpret the results?

“Delivered” does not mean that the user has actually read it. It also does not show all situations in external segments that did not reach Microsoft 365 tracking. Check Microsoft’s Message Trace FAQ for the timing of result display and limitations of search scope.

If you see Expanded in the distribution group, it means the group address was expanded to individual recipients. You should also check the delivery results for the individual recipients afterward. Quarantined is the item for which you need to check Defender's quarantine and policy reasons, and Getting status may indicate that the final data is not yet ready.

“Delivered” for emails sent externally may reflect that the message was handed off to the recipient's mail system. You cannot track situations where the receiving server classified it as junk or applied its own policies after acceptance. Conversely, if internal delivery is confirmed within the organization, mailbox rules, forwarding, junk folder, and client display are the next items to investigate. Message trace is not a tool to recover email contents or prove whether an email was read.

Choose the next action for each finding

• Incoming mail from an external sender has no result: Recheck the address, time zone, and trace-data availability, then request bounce information and logs from the sender. If the MX points to a different gateway, also verify whether it actually delivered to Microsoft 365 in that segment.
• Mail sent from the organization to an external recipient failed: Compare the remote server's response and the NDR code for detailed events. Determine whether it is due to an address error, recipient server policy, or authentication failure, and forward it to the responsible person as needed.
• Delivered but not visible to the user: First, check all relevant folders and rules in Outlook for the web. If it is visible on the web but not in a specific app, investigate client synchronization and view conditions.
• Quarantined due to security policy: Verify whether the message is legitimate and investigate policy and sender authentication. Apply exceptions by specifying the target, reason, and duration, without disabling the overall filter.

Resolve the cause and verify delivery

If quarantined by policy, do not arbitrarily turn off the entire policy; review the appropriateness of the message and policy. If a bounce occurred, forward the error code and the remote mail server's response to the sender. If it was delivered to the mailbox but not visible, check both web Outlook and the desktop app and investigate rules and junk mail settings. After resolution, send a test mail through the same sending route to check both tracking status and actual receipt.

The processing record includes the search conditions and time zone, message identifier, confirmed final event, actions taken, and retest results. Only the necessary address, time, and error code are sent to external personnel through a secure channel, and the full report is not shared indiscriminately. If DNS or policies were changed, the previous values and recovery criteria should also be recorded so they can be compared if the same issue occurs again.