Home » Exchange Server » Messages Queuing with Error 451 4.4.0 DNS Query Failed

Messages Queuing with Error 451 4.4.0 DNS Query Failed

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.

hub-transport-dns-02

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.

hub-transport-dns-01

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.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server

49 comments

  1. Skip McCurdy says:

    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.

  2. Jason says:

    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!

  3. Manuel Kukla says:

    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”.

  4. Harry Caray says:

    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

  5. Khan says:

    I begin experiencing this issue with Exchange immediately after migrating the Domain controllers from Windows 2008 R2 to Windows Server 2012 R2.

    • Manuel Kukla says:

      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.

  6. DaveW says:

    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!

  7. Ahmad Mazhar says:

    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.

  8. Binh Tang says:

    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.

  9. DeeJay B says:

    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?

    • “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.

  10. Jay Derrett says:

    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.

  11. Dead101 says:

    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

  12. Dominic Kolandi says:

    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

  13. Sam says:

    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.

  14. Fred says:

    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.)

  15. Greg Schultz says:

    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.

  16. Steve (calming down now) says:

    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!!

  17. Chris Robles says:

    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.

  18. T. Hernlund says:

    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. :-/

  19. TS says:

    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.

  20. Gary Mclean says:

    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

  21. Mekkano says:

    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.

  22. Lux says:

    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

  23. Joe Corea says:

    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.

  24. Michael Schechter says:

    Thanks, Paul. This was the fix for us, too. Incidentally, we had migrated over to this server with your swing instructions. Kudos.

  25. Rob Pelletier says:

    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…

  26. Biff says:

    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.

  27. Cory says:

    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!

  28. Srinivas says:

    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

  29. David says:

    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

  30. Wade Wellborn says:

    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.

  31. Lincoln Maximo Alves (Brasil) says:

    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!

  32. Lincoln Maximo Alves (Brazil) says:

    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!

  33. Martin says:

    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!

Leave a Reply

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