How to Troubleshoot Inbound Mailflow Issues

A common complaint from users has to do with their perception of how long it takes them to receive an email. The number of systems that a message has to pass through, and all the things that have to be correct before it can be delivered to their inbox are all behind the scenes and all but invisible to them, and if they have ever seen an email magically appear in their mailbox before they thought to expect it, anytime they think there is even a second of actual delay they will open a ticket.

User perception issues aside, mail flow troubleshooting is a useful skill, and sometimes a necessary task, so in this post we will cover some of the steps to take and areas to troubleshoot when you want to know what happens to a message from the time it leaves the sending system’s edge, until it gets to your user’s inbox.

Before you get too far into this, let me offer a little advice. First, make sure all of your systems’ clocks are synched to an NTP source. Then, make sure they all either log time in UTC or in your local time zone. You want accurate time, and you want consistent time, else this becomes an incredibly painful task.

1. Start with name resolution. Make sure that, on the Internet not your internal DNS, your MX records are correct and the lowest weight record goes to your primary entry point.

2. Evaluate what your firewall is doing and its load. Some firewalls have modules for content analysis, or protocol inspection, and you want to make sure that your firewall is not overloaded and causing a bottleneck. High average CPU and low memory are both clear signs of a firewall that is handling too much load.

3. Next, get the header. The SMTP message header is critical to this task. You can grab the header from an email in Outlook by opening a message, and choosing File, Properties. Copy it, and paste it into the great SMTP header analysis tool at http://www.mxtoolbox.com/EmailHeaders.aspx. This will clearly identify the systems that processed the message, and the times between them. Remember our tip above though, and don’t assume the sender’s systems have their clocks synced like your do.

4. Each device in your network that touches the message at an SMTP level will add to the header. Look for any time delays of more than a few seconds between hops. The system that holds the message the longest before delivery to the mailbox is where the bottleneck exists.

5. If that is your Edge Transport server, consider the load it is under and whether the hardware is adequate. If you don’t already have a third party anti-spam/anti-malware solution in place, consider deploying one to offload the anti-x from the Edge, so it can focus on mail routing and leave the filtering to a system better suited to that task.

6. Also sanity check the internal routing that a message follows before delivery to a mailbox. Exchange 2010 routing follows the same paths as the AD replication topology, and it’s very common to find inefficiencies in this that cause mail to route through several extra internal steps before delivery to the mailbox.

With good time sync in place, and the headers from a message, you can quickly identify the source of mail delays. Spam and malware filtering are a common cause, inefficient routing is another. Both are easily fixed once they are identified.

This guest post was provided by Casper Manes on behalf of GFI Software Ltd. GFI is a leading software developer that provides a single source for network administrators to address their network security, content security and messaging needs. Learn more about third party solutions to use together with you Exchange anti-spam.

All product and company names herein may be trademarks of their respective owners.

Post your questions, comments, feedbacks and suggestions

Contact a consultant