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.


About The Author

12 thoughts on “Troubleshooting Mail Flow Issues in Exchange Server”

  1. I also like to check the spam filter service as well. Often my clients have a third party spam filter service. The issue could be a maintenance mode, firewall issue or subscription expiry.
    Another item to check are black lists. check that both sides of the email are not on any blacklist.

  2. In a troubleshooting effort when checking for stopped Exchange services on multiple servers (concurrently) as is typically the case in a pinch, using Invoke-Command with Get-Service (as suggested in the post) appears to be more efficient than using Test-ServiceHealth as the cmdlet doesn’t have remoting. Using Test-ServiceHealth with Invoke-Command for multiple servers would also require establishing a PowerShell Remote session for each server.

    E.G. Invoke-Command -ComputerName (Get-ExchangeServer US*) -Command {Get-Service | Where-Object {$_.Name -Like ‘MSExchange*’ -and $_.Status -eq ‘Stopped’}}


  3. Nice post, however I’m having difficulty getting any useable info from any of these diagnostic commands or tools. I have installed Exchange 2016 cu11 on Server 2016. Windows is up to date. Checked for updates for Exchange when installing. I have plenty of space on the VM for a small test environment. All services needed are running. Ports are forwarded on the firewall. Windows firewall entries exist.

    I cannot send mail. Even when logged into OWA on the server itself as the test users… the sent mail items just stay in the draft box. Attempts to email from external domains just outright fail.

    Local run of Test-Mailflow fails with *FAILURE*, no additional info in event viewer. Basic connection test fails reporting no response on port 25.

    I’ve seemingly done everything needed to put up an Exchange mail server… but it’s just not working.

    Any ideas?

  4. Help:(
    When I run the test-mailflow I get errors saying “Couldn’t perform operation because a system mailbox isn’t available”

    I’m am working on a 2010 to 2016 coexistence environment. The mailboxes that exist on the 2016 server receive email from 2010 and external email but can not send out email externally. I could use assistance.

  5. Show cmds, cmdlets, … that would allow you to check and fix the following problems with Exchange Troubleshooting Problems. You should include at least there cmds or cmdlets for each area of MailFlow troubleshooting.

    • Troubleshooting Mail Flow:

    – DNS Failure: Mailbox servers can’t locate A records and therefore can’t reach next-hop servers.
    – Site Link Failure: No site link exists between sender and recipient.
    – Transport Failure: Transport services on all of the Mailbox servers in the user’s site are inaccessible.
    – Transport Agent: A transport rule prevents this email from reaching the recipient (because of sender restrictions, content restrictions, or recipient issues).
    – Mailbox Limits: The recipient’s mailbox is full, but nondelivery reports do not reach the sender for whatever reason.
    – Messages Stuck in Queue: A transient failure has temporarily stopped messages at a back-off location.
    – Back Pressure: Transport services are temporarily throttling message delivery due to resource constraints

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top