In this article, we are going to look about the mail flow issues that do not have a Non Delivery Report and troubleshooting to be performed to resolve it.
As we already discussed in the Part 1 of this topic, Mail flow issues with Non Delivery Reports are very easy to deal with. Now let’s jump into the other half. Understanding and Troubleshooting mail flow without NDR.
First things First:
When an external sender has sent an email and it has not been received by the intended recipient and neither the sender has received any NDR, We need to first check the MX record. There is always a due negligence observed among the administrators to check the DNS Records. Though the required DNS records like MX, CNAME, Autodiscover were created initially, we should have in mind that DNS zones are maintained by Network or Server team other than the Exchange team. Hence there could be some typo happened or the Pointing Server IP might be changed. Hence it’s always better to start off with DNS records. MX stands for Mail Exchanging records. The best way to check is to use the nslookup in command prompt or you can use any third party website. Once we confirmed that MX are fine then trace the email from our environment.
Until Exchange 2010, we had very good front end GUI for tracing the emails, however that was discontinued in the Exchange 2013. But still Exchange 2013 Powershell holds good for doing a trace. So either we use the GUI or the Powershell to trace the mail. GUI in Exchange 2010 is very user friendly now let see the powershell command.
Get-TransportServer | Get-MessageTrackingLog -Recipients:email@example.com -Sender “firstname.lastname@example.org” -MessageSubject “Test tracking” -Start “11/20/2016 6:15:00 PM” -End “11/20/2016 6:25:00 PM”
This will give us the set of results which will tell if the email has entered our organization or not. If the Email does not show up in the trace, then we have limited option to check and most probably the issue could lie on the sender’s end. So in this scenario a connection level filtering has happened, it means the Exchange server has rejected the connection itself. So now we should do a blacklist check on the sender’s domain that is major cause for connection level filtering. We can use the third party websites to check the IP and domain reputation (Blacklist). If it is blacklisted, then the sender’s IT team should remove it.
Now let’s assume the mail is showing up in the trace. Now we should look at the event of the email. There are different types of events, for example some events are
- Drop etc.,
If it is Drop then email has been stopped from sending for some reasons.
After this we can check the mail queue, whether the email still stuck in the queue. For checking the queue, we can use the queue viewer or the powershell. However powershell is not best way to check, since it can only give the number of emails in queue. To view the mails in the queue powershell is a tedious process, so let’s stick with the queue viewer. If you find the email in the queue, then the possible issues could be of mail.que file. It could lack space in its drive or even restarting the Transport Service will sometimes drain the queue. If emails are lost during the transaction we still have an option to recover it from the sender sent item. If the whole database is lost then we can consider OST recovery tool.
So by now most of the basic troubleshooting are done for the Mail flow issue and we should be able to find where exactly mail has stuck or dropped. These are very basic coverage of troubleshooting part and it may require deeper troubleshooting steps if the issue is not coming under these category. We may look some of them in near future.
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 error and word recovery software products. For more information visit www.datanumen.com