This article applies to:
Exchange 2010, Exchange 2016, SMTP

In this article I will show an example of Exchange 2010 to Exchange 2016 mail flow trobleshooting, based on a recent customer support case.


The customer is in a process of migrating from Exchange 2010 to Exchange 2016. The environment consists of 2 Exchange 2010 servers and 2 Exchange 2016 servers. All 4 Exchange Servers are located in the same Active Directory site. As a part of the migration some of the mailboxes are moved from Exchange 2010 to Exchange 2016.

The customer now reports a problem that users with mailboxes on Exchange 2010, are not able to send emails to users with mailboxes on Exchange 2016. Sending of emails in the opposite direction, from Exchange 2016 to Exchange 2010, is working fine.


As a first step, we will check the queues, in order to determine where the messages got stuck. For this you can use the following PowerShell command:

Copy to Clipboard

This will give us a list of all email queus from all Exchange servers, that are not empty.

As you can see the top 2 queues are in status Retry which shows us that the Exchange 2010 servers have correctly routed the e-mails towards Exchange 2016. But for some reason those are not accepted on the Exchange 2016 side.

If we further expand our PowerShell comannd with Format-List at the end, we will also be able to see the exact error message.

Copy to Clipboard

Under LastError we can see the exact SMTP error message:

451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.” Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.

By default, Exchange server 2016 receives email messages from other Exchange server via the SMTP connector named Default Frontend <Severname>. This connector is configured to allow connections from Exchange Servers and usage of Exchange Authentication method for authentication. As we can see here, this is configured correctly.

So where is the catch then? Why can’t the Exchange 2010 servers connect to Exchange 2016 by using Exchange authentication?


This indicates that the connection from Exchange 2010 servers lands with another connector on the Exchange 2016 server and not the default one. This would occur if you have additional custom connectors on your Exchange 2016 server, and one of them has the IP addresses of the Exchange 2010 servers configured. In such case, that custom connector would by used instead of the Default Connector.

And after investigation of other connectors on the Exchange 2016 machines, exaclty this turns out to be the case: both Exchange 2016 servers have a Relay connector where IPs of the Exchange 2010 servers are listed.

And, if we look at the configuration of the Relay connectors on our Exchange 2016 Servers, we can see that Exchange Authentication protocol is not configured, neither are Exchange Servers allowed to connect. This explains the error message. And this also explains why failover was not possible (both Exchange 2016 servers were configured in this way).


Solution here is to simply remove the IP address of the Exchange 2010 servers from the Relay connector on the Exchange 2016 servers.

On the next queue retry Exchange 2010 will establish connection correctly via Default Frontend connector and messages will be delivered normally.

In case you don’t want to wait, you can force the queue retry manually by using the Retry-Queue PowerShell command.

Dejan Foro