How to Troubleshoot Mail Flow Issues in Exchange (Part I)

In this article, we are going to look about the various mail flow issues and troubleshooting to be performed to resolve the same.

Introduction:

Mail flow is an essential ingredient in any Exchange Systems, without which the Exchange system and its concepts are a complete failure. So an IT Administrator’s job does not stop with configuring and setting up mail flow, it extends to troubleshoot when the mail flow is disrupted. In this chapter, we are going to learn the basics of Mail Flow troubleshooting.

Identifying the Issue:

Most of the administrators would have enabled Alerts using SCOM, SCCM or any other third party applications for identifying a certain point of failure like Transport Services, Mail Queues, Network Connectivity etc., So immediately after the issue arises, alerts are triggered and respective teams are notified. Then troubleshooting would start immediately and the services will be restored to normalcy with a less or negligible down time. So we are not going to concentrate much on that. There are certain other areas when the administrators will not know until an end user reports the issue. So basically we can divide this kind of mail flow issues into two types. They are,

1. User sends an email and receives an Non Delivery Report (NDR)
2. User sends and email, no NDR has been received and the recipient also did not receive the email.

Non-Delivery Report (NDR):

When a Non Delivery Report is received, it is very easy to identify what is the issue and in most cases the NDR would be so user friendly that an IT Administrator would definitely be able to understand the Root Cause and can resolve it very easily. NDR will have a detailed summary about the mail and the reason for failure. It consists of the following Components.

1. Enhanced Status Code.
2. Description and Possible Cause.
3. Additional Information about the issue and the servers.
4. Generating Server.
5. Complete mail headers.

The first three options are for the sender (end user) to understand and it will be in simple English. The last two options are for the Administrators to analyze the root cause and identify the issue.

When an email bounce back with an NDR it need not be an issue. It could happen even because of some restrictions applied either by Sender’s IT team or the recipient’s IT Team. For Example, restriction for receiving emails from External domain, Restrictions on message and attachment size, even internally certain departments are not allowed to email other teams. These are Managerial requirement set by the company’s management. So these NDRs are easily understandable. The sender or the recipient would request the management/IT Team to remove those restrictions with necessary approvals. These are some examples of restrictions,

Enhanced status code	Description	Possible cause
5.7.1	Delivery not authorized	The sender of the message is not allowed to send messages to the recipient.
5.5.3	Too many recipients	The combined total of recipients on the To, Cc, and Bcc lines of the message exceeds the total number of recipients allowed in a single message.

For more NDR we can refer to https://docs.microsoft.com/en-us/exchange/dsns-and-ndrs-in-exchange-2013-exchange-2013-help

Conclusion:

Hence by reading the NDR we can judge the issue and act upon accordingly. The Generating Server option will exactly tell whether the issue/restriction is from Sender or the Recipient. If the emails are rejected or bounced back, then it will not be stored in the database and we do not have an option to recover even with OST file recovery tools. Issues without NDR is a separate topic on its own and hence let’s discuss that in the next part.

Author Introduction:

Sophia Mao is a data recovery expert in DataNumen, Inc., which is the world leader in data recovery technologies that includes OST Recovery, repair pst mail damage and word recovery software products. For more information visit www.datanumen.com