Microsoft 365 Mail Flow Troubleshooting: A Step-by-Step Order That Saves Time

When mail stops flowing in a Microsoft 365 tenant, the fastest way to lose an afternoon is to change settings before you know where the message stopped. Work in a fixed order instead: find the message, read the evidence, then check the layers that can affect it. This is the order I use for Microsoft 365 mail flow troubleshooting, with the free browser tools on this site where they help.

1. Define the symptom precisely

Write down four facts before opening any portal:

• Sender and recipient addresses, exactly as typed.
• Approximate time sent, with the time zone.
• Direction: inbound from outside, outbound to outside, or internal.
• What the sender saw: a bounce, silence, a delay, or a message in junk.

A bounce message is the best evidence you have. Keep the full text, including the enhanced status code such as 5.1.1 and the server name that generated it.

2. Run a message trace first

Message trace in the Exchange admin center answers the question "did Exchange Online receive this, and what did it do with it?" Search by sender, recipient and a tight time range, then open the detailed view. Microsoft documents the procedure and the statuses here: Run a message trace and view the results.

Read the status as a branch point:

• Delivered: Exchange Online handed the message on. If the recipient cannot find it, look at their junk folder, Outlook rules, and any third-party filtering behind Microsoft 365.
• Failed: open the detail. The reason text usually names the stage and the code.
• Pending or deferred: the destination or a connector may be slow or unreachable.
• Quarantined or filtered as spam: go to step 6.
• No result at all for an inbound message: it probably never reached Exchange Online. Go to step 3.

Message trace retention and the range you can search differ between recent and older data, so check Microsoft's current limits rather than assuming.

3. If the message never arrived, check MX and DNS

Inbound mail finds you through the domain's MX record. For a domain whose mail is delivered straight to Exchange Online, Microsoft's setup normally points MX at a host under mail.protection.outlook.com. If you use a third-party filtering service, MX will point there instead, and that is by design.

Use the Email and Domain DNS Checker to look up MX, SPF, DKIM and DMARC for the domain from public DNS. Check that:

• MX points where you expect, and there are no leftover records from a previous provider.
• DNS changes have had time to propagate. Remember that a long TTL on an old record keeps it alive in caches.
• The domain is verified as an accepted domain in the tenant.

4. Check SPF, DKIM and DMARC

Authentication problems cause two different symptoms: your outbound mail is rejected or junked by others, or someone else's mail to you is flagged.

• SPF. A domain should publish one SPF record, not several. For Exchange Online the standard mechanism is include:spf.protection.outlook.com, plus any other service that legitimately sends for you. Paste the record into the SPF Record Explainer to see each mechanism. It does not expand include chains or count DNS lookups, so check the ten-lookup limit separately.
• DKIM. Exchange Online signs with two selectors published as CNAME records. Use the DKIM Public Key Record Explainer to read a selector record, and confirm in the Microsoft Defender portal that signing is enabled for the custom domain.
• DMARC. The DMARC Record Inspector explains the tags in a policy. A p=reject policy is appropriate only once every legitimate sender is aligned.

To see how a receiving server judged a real message, take the headers from a test message and use the Email Authentication Results Header Reviewer. The Authentication-Results header shows the SPF, DKIM and DMARC outcomes the receiver recorded. These tools read what is published or pasted; none of them proves that a receiver will accept your mail.

5. Review connectors and transport rules

If mail routes through an on-premises server, a hybrid configuration, or a partner, connectors matter. Open Mail flow, then Connectors, and check:

• Inbound connectors that match by sender domain or IP address, and whether they require TLS or a certificate that has since expired.
• Outbound connectors that route a domain to a smart host, and whether that host is reachable.
• Whether more than one connector could match the same traffic.

A routing loop produces a "hop count exceeded" style error. Microsoft's overview is here: Use connectors to configure mail flow.

Next, open mail flow rules (transport rules). Rules run in priority order and can reject, redirect, modify, quarantine or stop processing further rules. Look for rules that match the sender or recipient, rules that redirect, reject or change recipients, and any rule recently edited. The message trace detail lists which rules acted on a message, so use it to confirm rather than guess. See Mail flow rules in Exchange Online.

6. Check quarantine and spam filtering

If the trace says quarantined or filtered as spam, review the quarantine in the Microsoft Defender portal. The quarantined item shows the reason, such as spam, phishing, malware or a policy match, and what release options your role allows. Read it before releasing: a message quarantined as phishing should not be released simply because the recipient is waiting. Microsoft explains the process here: Quarantine in Microsoft 365.

If a legitimate sender is repeatedly caught, fix the cause (usually authentication) rather than adding a permanent allow entry, which also lets spoofed mail through.

7. Decode the bounce code

Use the code and text in the non-delivery report. Microsoft maintains a reference: Non-delivery reports in Exchange Online. In practice, a 5.1.1 usually means the recipient address was not found, a 5.7.x code points to a policy or permission rejection, and the explanatory text often names the exact rule or setting.

8. Change one thing and re-test

Make one change at a time, send a fresh test message, and trace that message. Record what you changed. If two things were changed at once, you will not know which one fixed it.

Limits and when to get help

Tools that read DNS or pasted headers show only what is published or pasted. They cannot see inside a receiver's filtering. If mail is business critical, the trace shows delivery to a system you do not control, or you suspect spoofing or a compromised account, stop making changes and get an experienced administrator involved so evidence is preserved.