Troubleshooting Mail Flow Issues in Exchange Server

Exchange Server tends to be one of the more critical applications for many organizations, so when mail stops flowing, it is important to restore mail flow as quickly as possible. Fortunately, there are a variety of techniques that can help to resolve the problem.

Start with the Basics

Before jumping straight into the troubleshooting process, it is a good idea to gather some basic information about the problem. Taking a few minutes to better understand exactly how the mail flow issue is impacting the organization can help you to narrow down the possible causes of the problem, and may reduce the overall troubleshooting time. Some of the key questions that I recommend answering up front include:

  • Are all of the users affected by the problem, or does the problem only impact some users?
  • If only some users are affected, then what do those users have in common with one another? Are all of their mailboxes on the same server?
  • Does the problem occur with all mail flow, or is it limited to a specific type of mail, such as mail coming in from the Internet?
  • When did the problem start? Did any other significant events occur around that time, such as a patch being applied, or a piece of hardware failing?
  • Is Exchange displaying any error messages?

Once those basic questions have been answered, there are two things that I like to check for any on premises Exchange servers. First, I like to check to make sure that all of the required system services are running. The reason why I like to start out by checking the Exchange Server related services, is because it is easy to check the state of a service, and I have run into several situations over the years in which problems were traced to services that had stopped.

You can use the Service Control Manager to check the various services, but personally I like using PowerShell, because PowerShell makes it easy to cut through the clutter and find exactly what you are looking for. Here is a command that I like to use:

Get-Service | Where-Object {$_.Name -Like ‘MSExchange*’ -and $_.Status -eq ‘Stopped’}

As you can see in Figure A, this command displays Exchange Server services that have stopped.

Figure A

You can use PowerShell to view the Exchange Server services that have stopped.

The second thing that I like to check up front is the amount of storage space that is available to the mailbox databases. In theory, administrators should be fully aware of how much storage space is available. In reality however, I have encountered multiple real world situations in which Exchange came to a grinding halt because it ran out of storage space.

The Test Mailflow Cmdlet

Another technique that I sometimes use when trying to diagnose a mail flow issue is to use the Test-MailFlow cmdlet. There are both advantages and disadvantages to using this cmdlet. The advantage is that the Test-MailFlow cmdlet is really flexible and allows you to test a variety of conditions. The disadvantage however, is that the cmdlet can only be used for on premises diagnosis. It does not work with the Office 365 cloud.

One of the most common uses for the Test-MailFlow cmdlet is to test mail flow between two Exchange mailbox servers. To do so, you need only to specify the name of the source and target mailbox servers. Suppose for instance that you wanted to test mail flow from a server named E2K16MBX1 to a server named E2K16MBX2. You could accomplish this by using this command:

Test-MailFlow E2K16MBX1 -TargetMailboxServer E2K16MBX2

As an alternative, you can test mail flow from an Exchange mailbox server to a specific E-mail address. To do so, run the Test-MailFlow cmdlet locally on the server that you want to test, and then specify the -TargetEmailAddress parameter, followed by the E-mail address that you want to test. You can see how this works in Figure B. Notice that the cmdlet not only reports that the test was successful, it also reports the message latency.

Figure B

The Test-MailFlow cmdlet can test mail flow to a specific mailbox.

As previously noted, the Test-MailFlow cmdlet is very flexible, and there are a number of different parameters that you can use within your tests. You can find the full command syntax at:

The Exchange Remote Connectivity Analyzer Tool

Another tool that I like to use when diagnosing Exchange mail flow problems is the Exchange Remote Connectivity Analyzer. This is an online tool that tests an Exchange Server environment to verify that the correct firewall ports are open, and that the Exchange Servers are functioning correctly. You can find the tool at:

The Exchange Remote Connectivity Analyzer contains a number of diagnostic tests for Exchange, including some that are dedicated to testing inbound and outbound SMTP mail, POP mail, and IMAP mail. In addition, the tool does a good job of testing the AutoDiscover service, which is critical to proper client connectivity. You can see the available tests in Figure C.

Figure C

The Exchange Remote Connectivity Analyzer Tool offers a number of different diagnostic tests.

The thing that I like about this tool is that the diagnostic information that it provides is generally very helpful. The test steps are organized into a tree view. If you look at Figure D for example, you can see the partial results of a mail flow test. In this case, the mail flow test failed, and the Exchange Remote Connectivity Analyzer was able to trace the cause to the message being blocked by Spamhaus.

Figure D

The Exchange Remote Connectivity Analyzer was able to determine the cause of the failed test.


Hopefully, one of the diagnostic tools discussed in this article has helped you to resolve your Exchange Server mail flow issues. If not though, then be sure to check the server’s event logs. The event logs sometimes contain more detailed diagnostic information than what Exchange tends to display within its error messages.

Brien Posey

Brien Posey is a freelance technology author and speaker with over two decades of IT experience. Prior to going freelance, Brien was a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network engineer for the United States Department of Defense at Fort Knox. In addition, Brien has worked as a network administrator for some of the largest insurance companies in America. To date, Brien has received Microsoft’s MVP award numerous times in categories including Windows Server, IIS, Exchange Server, and File Systems / Storage. You can visit Brien’s Website at:

Published by
Brien Posey

Recent Posts

Qumulo raises $125M for cloud data management across a hybrid setup

Qumulo is an up-and-coming data management solution focusing on managing files in a hybrid setup.…

1 day ago

Why SMBs need a standalone solution for Windows 10 patch management

Is patch management for the Windows PCs at your business driving you crazy? Maybe there's…

2 days ago

Microsoft Teams guest access: How to enable and manage it

Two of the main factors that affect the total cost of an organization’s Microsoft 365…

2 days ago

Samsung Galaxy Unpacked 2020: Everything you need to know

Samsung rolled out the all-new Galaxy Z Fold 2, Note 20, Note 20 Ultra handsets…

3 days ago

SAN vs. NAS: Detailed comparison of these two storage technologies

SAN and NAS provide dedicated storage for a group of users using completely different approaches…

3 days ago

Generation 1 virtual machines: Modernize them and bring them up to date

In many companies, Generation 1 virtual machines have been superseded by Gen 2 VMs. But…

3 days ago