Share via

Outbound mail queued up at Edge Server with 451 4.4.0 DNS query failed

  • Article

I have came across a couple cases with this issue as of recent and thought enough to create a blog post on, since if I see the issue on multiple people calling into MS support for an issue with the same fix, I'm sure others are experiencing it as well. I'll keep this short and sweet though. The recent issue I've experience, a customer implemented a new Exchange environment with Edge servers, and could receive inbound emails fine, but email was failing outbound on their Edge servers with the error below in the queue:

LastError: {LED=451 4.4.0 DNS query failed. The error was: DNS query failed with error ErrorRetry -> DnsQueryFailed

This was for all external domains we got the DNS query failure.  We verified via nslookup that we were able to resolve external domains MX records just fine, so there wasn't an issue with the DNS servers we had configured.  The issue turned out to be because of one simple (advanced) setting on the NIC "Register this connection's addresses in DNS".

After we checked this setting we were able to successfully resolve MX records and send outbound mail!

Now you may be asking why this would be the case, when clearly we are able to resolve DNS records with our configured DNS servers?  My theory is that this is due to the Exchange 2013/2016 code design differences that we had in Exchange 2010.  For instance, in Exchange 2010, this was just a checkbox for the DAG Network in the EMC if you wanted a network to be mapi/replication enabled or not.  When managing your DAG networks in Exchange 2013/2016, Exchange sees networks as "Replication Enabled" when the same "Register this connection's addresses in DNS" option is checked on the NIC or not.  If it's checked to register in DNS, Exchange thinks "oh this is a resolvable NIC address, this must be a MAPI network", and if it's not a registered DNS address, then we are probably using this for replication traffic, and it's not a client-accessible network.  My theory is that Transport uses this same logic for when it tries to do MX lookups for external domains.  If the NIC isn't registered in DNS, then we won't do DNS lookups.

 

Hopefully if you're having these symptoms this will help you out!

//DannyP