I recently encountered an Exchange 2010 server that was unable to send emails to a small number of domains. The messages would queue on the outbound transport server, and a look at the queue status would return an error of “451 4.4.0 DNS query failed”.
Interestingly the domain name was resolving just fine in DNS when queried from the server, including for MX record lookups, and a telnet to port 25 was successful too. When I created a send connector just for that namespace and designated their MX as the smart host IP address delivery was successful. It just would not work if DNS lookups were being used.
There are many reports of this error on forums such as TechNet but no concrete explanations for the causes or how to solve it. I saw many references to disabling IPv6 on the server, but also follow up reports that this did not work.
In the end the solution was to enable the option to force the send connector to use the external DNS settings for the transport server.
Even though there was nothing unusual about the external DNS settings on that server. They were simply set to use the DNS settings of the network interface, which worked fine for NSLookup.
After changing the send connector config and restarting the MSExchangeTransport service the mail delivered successfully to the troublesome domains.
It’s possible this is a bug with the particular combination of Exchange 2010 and Windows Server 2008 R2 that the customer is running, although I could not find anything that specifically confirms this. It is also not an issue I’ve encountered elsewhere with this combination of server versions, nor can I reproduce it in a test lab. But if you do encounter this issue the above solution seems to work fine and is certainly very quick and easy to try.
Worked for me! Thanks!
What a stupid bug… just check a box and restart a service. SBS 2011 Server.
Shouldn’t even have mattered. It IS the transport server already, and has worked for years.
This command mentioned above “dnscmd /config /enableednsprobes 0” and restarting transport service worked for me, but I hate this kind of stuff.
Why then other domains are successful? And why another Exchange (2013) using the same DNS server sends to specific domain (in my case is outlook.com) normally?
Thanks Paul, this worked for me too.
Thank you! That solved the issue for me too!
This post from almost four years old solved my problem.
Hi Paul,
Do you know how this error occur?
“451 4.4.397 Error communicating with target host. _> 421 4.4.2 Connection Dropped due to TimedOut”
Is this error came from the network side?
This is still helping people! Solve my issue on Server2008r2 and Ex2010. Thanks heaps! Saved my arse.
How can this still be an issue after all that time. And fix/workaround put out by MS is crazy… This is simple and I know it will work for all domains…
Thanks for this! We started to experience this when our DNS provider implemented DNS SEC on their end. In our case we did not have to restart any services for the queues to clear.
Thanks Paul! That was the solution I needed.
Once again you are a life saver, sir Cunningham!
I bookmarked your blog a long time ago and still thankful every day for that.
I had this particular issued described in this blog post and as always, your solution worked. Absolutely no logic to it, just a bug, but you, unlike others, gave the right answer and workaround.
The client has an SBS2011 server with Exchange 2010 running on it. Even though I promissed myself to never burn myself again on a piece of garbage like SBS, I was forced into the task of changing the SBS server’s IP address (had to go on a different subnet). And because its SBS, everything started to collapse. This is one of the issues.
Thanks a bunch!
Sorry, but the correct text is this:
Hello friends,
I went through the same issues with Win2012R2 with Exchange 2016 CU3.
In my case it happened after I disabled the “Register this connection’s addresses in DNS” DNS option on the Edge Transport server. This Edge server queried internal DNS and was in the DMZ. After I enabled the tag the service went back to work …. I took the time to do what you recommended in this article ..
Since you said that you had not simulated the error, try to see if it happens in your lab.
Thank you!
Hello friends,
I went through the same issues with Win2012R2 with Exchange 2016 CU3.
In my case it happened after I enabled the “Register this connection’s addresses in DNS” DNS option on the Edge Transport server. This Edge server queried internal DNS and was in the DMZ. After I removed the tag the service went back to work …. I took the time to do what you recommended in this article ..
Since you said that you had not simulated the error, try to see if it happens in your lab.
Thank you!
https://support.microsoft.com/es-pe/kb/3038746
My Exchange 2007 server just had this issue… Workaround above resolved it. But very strange…
Paul
Thanks again. Solved something we had been chasing with us.af.mil addresses for days.
Could telnet to them and send but the exchange server would not.
This is exchange 2013 on 2012 R2. Soon as we changed this the queues emptied.
Thanks for your articles. Saved us more than once.
Very strange that this fixed our problem.
Our server suddenly stopped sending messages to bigpond.com bigpond.com.au bigpond.net.au which are all from the same ISP which is one of Australia’s biggest and a very popular email server.
Our server has been using the same configuration for years and I have not applied any updates recently that could break our end. I suppose Bigpond could have rolled out a change to there servers that brought this DNS bug to the surface.
I watched my queues quickly drain once ticking that little box. 🙂
Thanks for writing such a well thought out and formatted article.
David
What should the check box be for TLS I have a 2010 dag
Thanks this worked for me too!!!!
Same Problem! Same Solution! Windows 2008 R2 and Exchange 2013.
Thanks Paul!
Same Problem! Same Solution! Windows 2012 and Exchange 2013.
Thanks Paul!
Hi Paul,
When we use FQDN of server as smart host (Linux server) to relay emails we are getting DNS 451 4.4.0 DNS query failed. However when we use IP Address of the server it is working fine. Any idea what could be the issue.
Thanks
Srini
Thank you for this… We just started experiencing this with accounts that we migrated from our on-premise Exchange 2010/Server 2008 environment to Office365, where we are routing our mail first through our on-premise server and then to O365. The strange thing was that it was intermittent – the queue viewer would show the mailbox database for Office365 as offline, while the on-premise databases were delivering without any problem. Then it would come back online and the mail that built up would all be delivered at once. After making the change in this article, we have not seen the problem since. Thanks again!
Has anyone ever experienced this issue internally within an Exchange organization? My environment is mostly 2010 with one 2013 server, and three 2016 servers for migration testing. I can send from test mailboxes on 2016 to 2010 mailboxes, but not vice versa, and this is the exact error I’m getting in the queues. The Next Hop Domain shows the name of the 2016 mailbox databases, but not the server name, and I get InfoNoRecords every time. 2010/2013 hub transport services just won’t send to 2016.
I can’t even count the number of Exchange issues I have resolved at this site. Whatever the nmuber, this adds another.
Thanks once again, Paul…
Mr. Paul,
Just wanted to say thanks to you for the website. Invaluable information.
Wayne
Thanks, Paul. This was the fix for us, too. Incidentally, we had migrated over to this server with your swing instructions. Kudos.
Nice work. I ran into this issue a couple of months ago. It was tough because we had just changed public IP addresses when this issue showed up so I wrongly thought it was some routing thing with our new IPs. Applied this fix and out the email went after restarting the transport service. Again… nice work… useful post.
Also having this issue with some domains. Seems like those remote domains have SECDNS servers. They respond with additional Records that MS DNS Server cannot handle in combination with Exchange. If you look into DNS Console in the cached lookups and search for that domain, you may find not just MX and A Records but also RRSIG records. Exchange seems to be confused by them.
We began facing the issues after Migrating from Exch 2010 SP2 to SP3 and RP10
I was experiencing the exact same symptoms. Checking the Queue Viewer, I got the “DNS Query Failed” message. Enabling “Use the External DNS Lookup settings on the transport server” worked perfectly!
I just realized we were having this problem recently, maybe because few weeks ago I decomisioned my old DCs WS2003R2 but it also might be because I installed last rollup 10 to Exchange 2010SP3 on 20150718. So I’m not sure what was the root cause.
My environment: Exchange2010/WS2008R2 on Hyper-V WS2012R2 STD, and Two Physical DC WS2012R2 STD.
I just want to point out that the problem was only with some few external domains.
and as Paul said. the Exchange server is still using exactly the same DNS servers. I did not change at all anything related to DNS servers or on them.
Paul, thank you so much for your article.
P.S. I did not have to reset the MSExchange transport service.
Had the same issue at a friends site running Exchange 2010 on SBS 2008
I did some underlying DNS Test’s and the domain in question had 1 issue. I had 4 MX records for the domain however, one of the A records for the MX Records was unresolvable. 2 Records with Pref 10, one with 20 and one with 30. One of the A records for PREF 10 is not in DNS.
I’ve a hunch that if it has issues with DNS Resolution, it may fail the domain, so making the change suggested fixed the issue.
Gary
Just to add to this. I was experiencing similar problems with Exchange 2013 on an Edge transport, but the above suggestion did not fix the problem. However, I found this:
http://www.o-xchange.com/2014/09/exchange-queue-error-451-440-dns-query.html
Which worked for me! I added the GUID of the network adapter, and messages began flowing again. Strangely, my Exchange 2007 Edge transport also has this enabled with a GUID of zeros, but that works and 2013 doesn’t.
Paul thank for this solution. It just popped up today at my company.
Thanks!
Ex2013sp1 and Win2012. Same problem, same fix.
It’s always troubling to see a fix for a previous version work on a current version and not know exactly why. Just “making it work” isn’t often good enough. I have to know why in order to completely rest easy. :-/
This problem sprang up on our Exchange 2010 server. A slew of complaints about delayed e-mails using our SMTP relay. Paul, your post saved the day! Thanks for publishing this article.
You’re a lifesaver Paul!!
I also ‘enjoyed’ this issue with Exch2010SP8 immediately after migrating the domain controllers 2012 R2.
Gee, another non-sensical problem with another non-intuitive solution. Job security!!
Thanks Paul!
We had a handful of domains that this happening on our Exchange2010 /Server2008R2 servers and your fix worked perfectly.
I’m a novice Exchange admin and I originally tried to change the setting on the Edge Transport server and got an error. I went to the Hubtransport and made the change there and the change sycned to the Edge Transport and all was good after a restart of the MS Exchange Transport service on the Edge server.
Thanks again.
Hi Paul,
From out of nowhere we began to suffer from this problem also. No clue why this suddenly occured. But your post solved the problem for us. Thanx a million!
(Windows 2008 R2 server with Exchange 2010.)
Many thanks. This has been an ongoing issue with our 2007 Exchange server. Made the change and after rebooting Exchange and Edge servers I saw my queues clear up.
I have the same issue on Exchange 2013/Windows 2012 R2.Did as explained but issue still there.
Error: 451.4.4.0 error encounted while communicating with primary target ip address:421 4.4.2 connection dropped due to timwout.Attempting failover to alternet host,but that did not succeed…etc
Need help please.
Thanksyou
I have the same problem on my exchange 2010 SP3 rollup 8, it just happened and did not know what is the cause.
I think it happened after installing the latest rollup update since my server was working with no issues for years
Any way, I have applied the fix and waiting to see if this will happen again
Thank you
I had the same issue on Ex 2013/Windows 2012.
Same fix, worked after restarting the service.
Thanks for the tip.
Thanks very much for the fix – it worked a treat. I am on Exch2010 and Win2008R2. As Yaun says, no service restart required – I just retried the queue and it flushed through fine.
it worked for me without needing to restart the MSExchangeTransport service
Thanks! I found the spot, checked the box, but no change. I can only get the server to send external email if I restart it. Then it works for a little over an hour. I tried restarting only the exchange services, but that didn’t work either. Any ideas?
I am such a NOOB… sorry for the stupid question… Where do I find the “Internet Email Properties” where I can check the “Use External DNS Lookup” setting?
Will this affect my email going through our McAfee Email filtering service?
The Real Person!
The Real Person!
“Internet Email” is just the name of my send connector. Open the properties of your send connector, whatever it is called, and look there.
I don’t imagine it will cause you a problem with your McAfee service but on the other hand if it does at least you will notice quickly.
The same issue on Exchange 2013SP1. Thank you for resolution!
Many thanks Paul for that easy and effective solution
Your solution worked a treat! I had a client who has Server 2012 R2 and Exchange 2010 and emails were very delayed and I couldn’t figure out why. Checking the Queue Viewer, I got the “DNS Query Failed” message. Making the changes your outlined has fixed the issue and the email is sent straight away.
Same issue with Exchange server 2010 and we’re using EOP as smart host instead of MX records and queues were struck on Retry mode on Hub Transport server.
Resolved the problem by removing individual hosts from CAS NLB manager, restarting Exchange transport server and then re-adding hosts again.
Nice – Out of the blue this issue occurred with both our Edge Servers. Following the advice above rectfied the issue. Looks like I have to go & apologise to the Networks Team 🙁
Thanx again Paul!
I begin experiencing this issue with Exchange immediately after migrating the Domain controllers from Windows 2008 R2 to Windows Server 2012 R2.
That’s correct. All machines are using DNS-Servers with 2012R2. Seems to be an incompatibility with EX2010 and WS2012R2 DNS. Another Exchange 2010 is running fine without this setting with an WS2012 (R1) DNS.
The problem is because of the ‘Extention Mechanisms for DNS’ built into Windows DNS Server. You’ve fixed it by using another DNS server. You could have disabled this feature on the Windows DNS Serverby running this from the command line: ‘dnscmd /config /enableednsprobes 0’
See http://support.microsoft.com/kb/832223
The Exchange server is still using exactly the same DNS servers.
Thank you Harry and Paul, this resolved our issue. We had a new firewall installed and it looks like it wasn’t configured properly as in the Microsoft article. Thanks again.
Had the same issue on two different machines with Ex 2010 and W2K8 R2 SP1. A lot of another machines are still working without this “fix”.
Thanks for the information. I have not specifically encountered this issue but now many who do will have a pretty good shot at finding a solution through your blog.
Keep up the great work!
We had the exact same issue here with no reason for it. We did the same thing and it worked for us as well. DNS was fine on all counts. We also routed problem domains out via send connector customization to our Cuda and it sent to our problem domains just fine. Seems to just be Exchange and certain domains with 2008R2.