Fixing Exchange Server Message Queue Error ‘451 4.4.0 DNS query failed’

In a recent Exchange 2010 to Exchange 2016 migration, I was doing all the standard testing for mailflow after placing a test mailbox on the Exchange 2016 server. In this environment, the private and public DNS and NAT on the firewall were still pointing to the Exchange 2010 server as it is a good idea to make sure everything is working prior to making your DNS changes. I tested the following for mail flow:

1. Exchange 2010 -> Exchange 2016
2. Exchange 2016 -> Exchange 2010
3. Exchange 2010 -> External
4. External -> Exchange 2010
5. Exchange 2016 -> External
6. External -> Exchange 2016

I was striking out on #1 and #6. No. 6 made sense, because for mail to come in from external it had to hit the Exchange 2010 server first, and then route to the Exchange 2016 server. If that wasn’t working then the mailflow from external to the Exchange 2016 server would not work.

Eventually the mail sent from the Exchange 2010 server to a mailbox on the Exchange 2016 server would get returned with a non delivery report (NDR) to the mailbox on Exchange 2010. Looking at the Exchange 2010 toolbox’s Queue Viewer I found this as the error: 451 4.4.0 DNS query failed.

I checked the local adapter DNS settings and there was a public IP address listed at the third address. As it was listed as the third entry I wouldn’t think that would have been the issue, however I removed it anyways as public IP addresses should never be put on domain joined computers. They should always rely on the DNS servers (usually the Active Directory Domain Controllers) for DNS. Afterwards, from an elevated command prompt I did an “ipconfig /flushdns” and for good measure an “ipconfig /registerdns.” I restarted the Microsoft Exchange Transport service and retried the messages in the queue. Still no go.

However, Exchange doesn’t have to use the Network Adapter settings for its DNS. Inside of Exchange Management Console on the Exchange 2010 server, if you navigate to Server Configuration, Hub Transport, right click your server and go to properties; there are two DNS relevant tabs in there (External DNS Lookups and Internal DNS Lookups). The Exchange 2010 server was set to this:

So, while the network adapter card settings were correct, Exchange was configured to ignore the DNS settings for the network card and use the settings specified here. After seeing this it was obvious that this Exchange 2010 would never be able to lookup the internal FQDN of the Exchange 2016 server. I changed these two settings to use the network card DNS settings for All Available IPv4.

I applied the settings and restarted the Microsoft Exchange Transport service again. I expected messages to clear the queue, and yet, they did not!

Something’s fishy. I went to the Exchange Management Shell to see what might be going on. From there, I ran the command:

Get-TransportServer | fl *dns*

While I had changed the properties of the transport server to not use the external DNS servers, they still were set to use them! Time to try again through PowerShell.

Set-TransportServer -Identity <servername> -InternalDNSServers $null

Set-TransportServer -Identity <servername> -ExternalDNSServers $null

Check your work with the same command you used before:

Get-TransportServer | fl name, *dns*

Much better. Restart the Microsoft Exchange Transport service one more time. This time around I watched the mail start flowing out of the queue.

Other useful commands I found in troubleshooting this in the Exchange Management Shell were:

Get-queue

This would show all the Next Hop Domain identities and counts of mail in the queue and their status. Find the one where mail is building up and run this:

Get-queue -Identity <servername><identity> | FL

This should give more information about the mail stuck in the queue and reasons for it.

Hope this one saves you some troubleshooting time when trying to fix the “451 4.4.0 DNS query failed” error.

Have an IT issue you need helping resolving? Contact Sikich and let’s come up with a solution together.