Exchange Online Mail Not Arriving? Trace and Diagnose Delivery Failures

Gather four facts before you open anything

Mail problems tend to arrive as 'Anna says Ben never got her email'. That is not enough to trace anything. Two minutes spent collecting the details below makes the rest of the job much quicker, and anyone can do it without admin rights.

• Who sent it and to whom, as exact full email addresses. A typo is the most common cause of all, so compare what the sender typed with the address the recipient actually uses.
• When it was sent, as closely as you can get. Message trace works in UTC unless you change the time zone, and UTC is an hour behind UK clocks during British Summer Time.
• The complete text of any bounce message (an NDR, or non-delivery report). Ask for it forwarded, not a screenshot of the friendly part at the top, because the technical detail sits further down.
• Whether the problem is outbound (someone in your organisation sending out), inbound (the outside world sending to you) or internal. The answer decides which side of the trace you read first.

Run a message trace in the Exchange admin center

A message trace is Microsoft 365's record of what happened to a message: received, sent, delivered, deferred, failed. It only reads data, so it is safe to run as often as you like. You need to be an Exchange Administrator or a member of the Organization Management role group. Global Administrator also works, but it is far more access than this job needs.

Searches of 10 days or less give you a Summary report almost immediately. You can look back up to 90 days, but only 10 days at a time. If the message is older than that, or your range runs even slightly past 10 days, the result becomes a downloadable CSV report prepared from archived data, which can take several hours, so start it and do something else. The last 24 hours of archived data typically is not included in those downloadable reports, so use the Summary report for anything recent.

1. Sign in to https://admin.exchange.microsoft.com and go to Mail flow, then Message trace. The Message trace page opens with tabs for Default queries, Custom queries, Autosaved queries and Downloadable reports.
2. Select Start a trace. In the New message trace flyout, type the sender in Senders and the recipient in Recipients. External addresses are fine. Entering both narrows the results to the conversation you care about. A single wildcard such as *@contoso.com is allowed in a value, but not several.
3. Set the Time range. The default is 2 days. Switch to Custom time range and bracket the time the sender gave you, with a margin either side. Check the Time zone setting here, because it applies to both your query and the results.
4. Under Detailed search options, leave the delivery status filter on All for the first pass. Filtering straight to Failed would hide a Delivered result, and 'it was delivered' is often the answer you need.
5. Leave Report type on Summary report and select Search. Results appear newest first with Date, Sender, Recipient, Subject and Status columns. If the newest message shows Getting status, Microsoft 365 has only just received it. Check again in a few minutes, as there can be a five to ten minute lag between the reported status and what has really happened.
6. Select the row itself (not the round check box) to open the details flyout. Expand Message events to see the sequence, such as Receive, Send, Deliver, Defer or Fail, and expand More information for the Message ID and the IP addresses involved. The Message ID is the one value worth copying down, because the recipient's own mail system can search for it.

Read the status: who has the message now?

The status tells you whose turn it is. Work out which of the cases below you are in before you touch any configuration.

• Delivered: the message was successfully delivered to its intended destination. For an internal recipient, a Deliver event means it reached the mailbox, so look at the Junk Email folder, inbox rules, forwarding and whether the recipient is searching the right mailbox. For an external recipient, Microsoft 365 has handed it to their mail servers and the To IP value shows where it went. The rest is the recipient's side, and you can give their administrator the Message ID, the time and that IP address.
• Failed: delivery was attempted and did not succeed, and a bounce will have been generated. Go to the next section and read it.
• Pending, with a Defer event: delivery is being attempted or retried. This is usually a temporary problem at the destination. It will either go through eventually or end in an NDR, commonly 4.4.7 Message expired, which points at the receiving server.
• Filtered as spam or Quarantined: this is security filtering, not routing. Filtered as spam means the message was identified as spam and was rejected or blocked. Quarantined means it is being held in quarantine. Do not release anything until you have checked that the sender is genuine, because that is a security decision rather than a mail-flow fix.
• Expanded: the recipient was a distribution group and was expanded into its members. Read the individual member lines that follow rather than the group line.
• No results at all: first widen the time range and check the addresses for typos and the time zone. If you are certain the search is right and the message is under 90 days old, it probably never reached Microsoft 365. For inbound mail, that points to the sender's own bounce message, your MX record or your accepted domains, covered below. For outbound mail, check the sender's client, because a message stuck in Outlook's Outbox or sent while offline leaves no trace.

Read the bounce before you guess

An NDR looks like a wall of text, but only three details matter: the enhanced status code, the server that rejected the message and the plain-English reason. In newer-style NDRs Microsoft adds a Fix-it owner indicator showing whether the sender, Microsoft 365 or the recipient's side has to fix it. In older ones, scroll to Diagnostic information for administrators. There, Generating server is the server that created the NDR. If a remote server is listed under the recipient, that server rejected the message. If none is listed, the generating server rejected it itself.

The enhanced status code follows the pattern x.y.z. A code starting with 5 is a permanent failure and one starting with 4 is temporary, so the second sort will often fix itself. If you are an administrator on a Microsoft 365 tenant that is not a government, 21Vianet or Germany tenant, the Microsoft 365 admin center also offers an NDR diagnostic: paste the code or error message into it and select Run Tests for Microsoft's own explanation.

These are the codes most worth recognising, and who usually fixes each one.

• 5.1.10 or 5.1.1 (recipient not found or bad destination mailbox address): the address does not exist or could not be resolved. For one of your own users, check that the account exists under Users, then Active users in the Microsoft 365 admin center, that its address matches what the sender used and that it has a licence if its mailbox is in Exchange Online. A stale Outlook auto-complete suggestion is a classic culprit, so have the sender delete the suggestion and retype the address. A 5.1.10 for a message you never sent is probably backscatter from someone forging your address, which is annoying but not a sign of compromise.
• 5.4.1 has two meanings. 'Relay Access Denied' means the server that produced the error does not accept mail for that domain, which points to DNS or mail server configuration. 'Recipient address rejected: Access denied' means DBEB (directory-based edge blocking) turned the message away because the address does not exist in Microsoft 365. The same code needs entirely different fixes, so read the text after it.
• 5.7.1, 5.7.124, 5.7.133, 5.7.134 or 5.7.136: a permission or restriction. Typical causes are a group that only accepts mail from listed senders, a recipient set to reject messages from outside the organisation, or a mail flow rule that rejects the message. The NDR often names the restricted group. The owner of the recipient has to change it, not the sender.
• 4.4.7 Message expired or 4.4.316 Connection refused: Microsoft 365 could not reach or get an answer from the destination server in time. This almost always lies with the receiving server or a network outside Microsoft 365. The 4.4.316 text should include the IP address of the server giving the error, which tells you whom to contact.
• 5.7.23 (SPF violation) or 5.7.509 (DMARC failure): the message was rejected because the sending domain's email authentication did not pass. That is a job for whoever manages the sending domain's DNS records, and it is a separate piece of work from tracing this message.
• 5.1.8, 5.1.90, 5.2.2, 5.7.501 to 5.7.503 and 5.7.705 or 5.7.708: the sending account or tenant has been blocked or has exceeded sending limits. Treat these as a security problem first. Microsoft says the usual cause is an account compromised by phishing or malware, so do not simply unblock it. Secure the account, then ask for the restriction to be lifted. For 5.7.705 and 5.7.708 the tenant itself is blocked and Microsoft says to resolve any compromise or open relay and then contact support.

If the problem is routing rather than the message

Use this section when an inbound trace comes back empty, or when an NDR on your own domain says 5.1.10, 5.4.1 or Relay Access Denied. These checks all read configuration and change nothing. Hold off on edits until you know which of them is wrong, because some changes make things worse if you get the design wrong. An accepted domain switched to Internal relay without a matching connector breaks delivery to on-premises recipients, and one switched to Authoritative while recipients exist only on your own servers gets those recipients rejected.

The first check needs permission to view domains in the Microsoft 365 admin center. The second needs access to the Exchange admin center.

1. Check the MX record. In the Microsoft 365 admin center go to Settings, then Domains, select the domain and, in the Required DNS settings pane, select Check DNS. A domain whose mail goes straight to Microsoft 365 normally has a single MX record pointing at YOURDOMAIN.mail.protection.outlook.com or YOURDOMAIN.subdomain.mx.microsoft, with Microsoft not supporting more than one MX record for a domain enrolled in Exchange Online. If your MX deliberately points at a third-party filtering service or your own server, that is a different design that depends on connectors, so find out why before changing anything. DNS changes usually spread within a few hours but can take up to 72 hours, so do not judge a fix too soon.
2. Check the accepted domain type. In the Exchange admin center go to Mail flow, then Accepted domains and open the domain. Authoritative means mail goes only to recipients that exist in Microsoft 365 and unknown recipients are rejected. Internal relay means unknown recipients are passed on to your own mail servers, which needs a connector. If every mailbox for the domain is in Microsoft 365, Authoritative is the right setting. If you prefer to read it as text, run the command below in Exchange Online PowerShell after Connect-ExchangeOnline. It only lists settings.
   powershellCopy

   Get-AcceptedDomain | Format-Table Name,DomainName,DomainType

3. Look at Mail flow, then Rules in the Exchange admin center for any rule that rejects, redirects or modifies mail for the people involved. Then look at Mail flow, then Connectors, which matter only if you have a hybrid setup, a third-party mail gateway or devices relaying through Microsoft 365. Read them and make a note, but do not edit them while you are still diagnosing.
4. Run the Inbound SMTP Email test under Office 365, then Mail Flow Configuration in the Microsoft Remote Connectivity Analyzer at https://testconnectivity.microsoft.com. It is an outside-in check that your domain's MX records can accept mail. Treat it as a pointer to where the connection fails rather than a final verdict. The Outbound SMTP Email test next to it checks the other direction.

Run the same trace in PowerShell

Use PowerShell when you need to check many messages, copy results into a ticket or work through a very long recipient list. You need the Exchange Online PowerShell module, version 3.7.0 or later for the message trace commands Get-MessageTraceV2 and Get-MessageTraceDetailV2, and one of the same admin roles as before. Microsoft says the older Get-MessageTrace is replaced by Get-MessageTraceV2 and will eventually be deprecated, so use the V2 commands for anything new. Everything below only reads data.

Three limits are worth knowing. With no dates, you get only the last 48 hours. A single query covers at most 10 days within the last 90. Results default to 1000 and cap at 5000 per query, so narrow the time range rather than asking for more. The dates below are written in an unambiguous year-month-day format with a Z for UTC, which avoids the trap of a UK computer reading 06/13 as nonsense.

Replace YOUR_SENDER_ADDRESS and YOUR_RECIPIENT_ADDRESS with the full addresses, and change the two dates to bracket the time you were given.

1. Connect to Exchange Online PowerShell and sign in when prompted. The second command shows the installed module version.
   powershellCopy

   Connect-ExchangeOnline

   powershellCopy

   Get-Module ExchangeOnlineManagement -ListAvailable | Select-Object Name,Version

2. Run the trace and store the results in a variable, then show them as a table. The Status column uses the same values as the Exchange admin center.
   powershellCopy

   $trace = Get-MessageTraceV2 -SenderAddress YOUR_SENDER_ADDRESS -RecipientAddress YOUR_RECIPIENT_ADDRESS -StartDate '2026-11-10T09:00:00Z' -EndDate '2026-11-10T17:00:00Z'

   powershellCopy

   $trace | Format-Table Received,SenderAddress,RecipientAddress,Subject,Status -AutoSize

3. Pull the event-by-event detail for any failed messages. The pipeline passes each message to the detail command, which lists the events (Receive, Send, Fail and so on) with their detail text. If it returns nothing, there were no failed messages in that window, so go back to the table.
   powershellCopy

   Get-MessageTraceV2 -SenderAddress YOUR_SENDER_ADDRESS -RecipientAddress YOUR_RECIPIENT_ADDRESS -StartDate '2026-11-10T09:00:00Z' -EndDate '2026-11-10T17:00:00Z' -Status Failed | Get-MessageTraceDetailV2 | Format-List Date,Event,Detail

Confirm the fix, or escalate with evidence

Once you have corrected something, whether it is a mistyped address, a group's allowed senders or an MX record, have the sender send a fresh test between the same two addresses. Wait a few minutes, then run a new trace. You are looking for a Delivered status with a Deliver event for an internal recipient, or a Send event to the right destination for an external one, and no new NDR. Ask the recipient to confirm they can see it, because a trace cannot show what happens inside a mailbox after delivery.

If you are still stuck, the next stop is the recipient's administrator or Microsoft support, and they will ask for the same things. Collect the Message ID, the time in UTC, the full NDR text including the Diagnostic information for administrators section and the trace results (Export results in the Exchange admin center saves a CSV file). That file contains addresses and subject lines, so treat it as business data and share it only with people who need it. A trace that shows nothing for a message that should have arrived, or an NDR saying your tenant itself is blocked, are the two cases that most often need Microsoft's own support route.