After you’re sure that SMTP connectivity to the Exchange server is working, and that the Exchange server is accepting the inbound email, you can begin troubleshooting in the transport pipeline. The transport architecture for each version of Microsoft Exchange Server is slightly different, but the troubleshooting process is basically the same for most scenarios.

Transport Pipeline diagram from TechNet
Transport Pipeline diagram from TechNet

The best source of troubleshooting info to start with is message tracking logs. If you’re new to this topic then I recommend reading the introduction article, otherwise you can begin performing message tracking log searches using PowerShell.

Work on your message tracking log search until you have a clear set of tracking events, sorted in order of time stamp (the articles above will teach you how to do that), showing the passage of the email through the transport pipeline to its ultimate destination. If you find any FAIL or DROP events, or anything else that indicates the message was not successfully delivered, then that will get you close to an answer on what happened to the email.

A common scenario in my experience is when message tracking shows successful delivery to the mailbox, but the mailbox owner claims that the email did not arrive. Usually this is due to one of two causes:

If the email message is still in the mailbox, or has only recently been deleted and can be restored from the recoverable deleted items, then that is obviously a much faster resolution than going to your backups to restore the email message (assuming the message was ever backed up).

Return to main article

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for

Leave a Reply