451 4.4.0 DNS query failed: fixing Exchange queues stuck in Retry

When Exchange can't work out where to send a message, the delivery queue goes to Retry with 451 4.4.0 DNS query failed and the mail waits there until it expires. The cause is nearly always DNS, but not always the DNS servers you think transport is using. In this post I'll show how to find the resolver Exchange really uses, test lookups the same way, and fix it for good on Exchange Server SE, 2019 or 2016.

Symptoms#

Mail to one or more outside domains isn't arriving, and there's no NDR yet. In Queue Viewer or the Exchange Management Shell, the queue for that destination is in Retry with a LastError such as:

451 4.4.0 DNS query failed
451 4.4.0 DNS query failed. The error was: SMTPSEND.DNS.NonExistentDomain; nonexistent domain
... DNS query failed with error InfoNoRecords

The scope tells you where to look:

• Every external domain is queuing: the problem is your DNS path.
• One domain is queuing while others flow: usually that domain's DNS, or an internal zone that shadows it.
• Hybrid: the next hop is yourtenant.mail.onmicrosoft.com, so internal DNS can't resolve the Microsoft 365 routing domain.
• Internal mail stays in Drafts and the transport queue shows 4.4.0 DNS query failed. Microsoft documents this for Exchange 2013 and 2016 servers whose network adapter isn't set to register its addresses in DNS.

Left alone, senders get a delay notification after four hours and a 550 4.4.7 QUEUE.Expired NDR after two days (the defaults).

Why it happens#

Transport looks up the MX records of the destination domain, then the address records of those hosts. Which DNS servers it asks is a transport setting, not necessarily what nslookup uses:

• By default, the Transport service uses the DNS servers configured on the network adapter for internal and external lookups alike, including outbound remote mail routing.
• You can give each server a fixed list of external DNS servers (ExternalDNSServers), but a send connector only uses it when Use the external DNS lookup settings on servers with transport roles (UseExternalDNSServersEnabled) is on.
• The adapter settings can point at one specific adapter GUID. After a NIC replacement or VM move, that adapter may no longer exist.

Typical root causes: domain controllers without working forwarders or root hints, a firewall blocking UDP or TCP 53, stale addresses in ExternalDNSServers, a public resolver mixed in with internal ones on the NIC (internal names then fail intermittently), or an old internal zone or conditional forwarder for a partner's domain. For single domains, Microsoft also notes that some remote DNS servers ignore AAAA (IPv6) queries or answer them in an unexpected way.

How to fix it#

1. Read the failing queues#

Get-Queue -Server EX01 | Where-Object { $_.LastError -like "*DNS query failed*" } |
    Format-List Identity, DeliveryType, NextHopDomain, Status, MessageCount, LastError

2. See which DNS servers transport uses#

Get-TransportService EX01 | Format-List Name, *DNS*
Get-SendConnector | Format-List Name, AddressSpaces, DNSRoutingEnabled, SmartHosts, UseExternalDNSServersEnabled
Get-NetAdapter | Format-Table Name, InterfaceGuid, Status
Get-DnsClientServerAddress | Format-Table InterfaceAlias, AddressFamily, ServerAddresses

Check that ExternalDNSAdapterGuid and InternalDNSAdapterGuid are either all zeros (all adapters) or match a current InterfaceGuid, and that every DNS server on the adapter, including any IPv6 entries, actually answers.

3. Test the lookup the way transport does#

From the Exchange server, query the same DNS server transport uses:

$dns = "10.0.0.10"
Resolve-DnsName -Name fabrikam.com -Type MX -Server $dns -DnsOnly
Resolve-DnsName -Name mail.fabrikam.com -Type A -Server $dns -DnsOnly
Resolve-DnsName -Name mail.fabrikam.com -Type AAAA -Server $dns -DnsOnly
Resolve-DnsName -Name fabrikam.com -Type MX -Server $dns -TcpOnly

Good looks like this: the MX query returns NameExchange and Preference values, the A query returns an address, and the AAAA query answers quickly. An empty answer is fine; a timeout is not. The -TcpOnly query proves TCP 53 is open for larger responses. Then repeat against a public resolver: if it works there but not internally, the problem is yours; if it fails everywhere, it's the remote domain.

4. Fix the resolver path#

• All domains failing: repair the DNS servers themselves (forwarders or root hints, and firewall rules for UDP and TCP 53). Keep the Exchange server's NIC pointing only at internal Active Directory DNS servers.
• Dedicated resolvers for internet lookups: set them per server and switch the internet connector over, which is the change Microsoft's article describes:

Set-TransportService EX01 -ExternalDNSAdapterEnabled $false -ExternalDNSServers 10.0.0.53,10.0.1.53
Set-SendConnector "Internet" -UseExternalDNSServersEnabled $true

• Adapter GUID mismatch: in the Exchange admin center open Servers › Servers › (your server) › DNS lookups and select the current adapter, or all adapters, for external and internal lookups.
• One domain failing: tell the remote admins. Microsoft's documented workaround is a send connector for just that domain that uses their mail server's IP address as a smart host, with smart host authentication set to None, so no DNS lookup is needed. Remove it once their DNS is fixed, because IP addresses change:

New-SendConnector -Name "Temp - fabrikam.com" -AddressSpaces "fabrikam.com" -DNSRoutingEnabled $false `
    -SmartHosts 203.0.113.25 -SmartHostAuthMechanism None -SourceTransportServers EX01

• Hybrid: make sure internal DNS can resolve the MX record of yourtenant.mail.onmicrosoft.com. See Exchange hybrid mail flow: connectors, TLS and centralized transport.
• Internal mail stuck in Drafts: select Register this connection's addresses in DNS in the adapter's advanced TCP/IPv4 DNS settings, then restart transport.

5. Restart transport and retry the queues#

Restart-Service MSExchangeTransport
Get-Queue -Server EX01 | Where-Object { $_.Status -eq "Retry" } |
    ForEach-Object { Retry-Queue -Identity $_.Identity }

The restart clears results transport cached from the failed lookups. If you added a connector, use Retry-Queue -Identity "EX01\fabrikam.com" -Resubmit $true so the messages are routed again through the new path.

Verify the fix#

• Get-Queue shows the queue gone, or Ready with a falling MessageCount and no LastError.
• The Resolve-DnsName tests from step 3 succeed over UDP and TCP against the resolver transport uses.
• Message tracking shows the messages leaving, with the remote server's 250 acceptance in RecipientStatus:

Get-MessageTrackingLog -Server EX01 -EventId SEND -Recipients user@fabrikam.com -Start (Get-Date).AddHours(-2) |
    Format-Table Timestamp, EventId, Recipients, RecipientStatus -AutoSize

Prevent it next time#

• Monitor DNS forwarders, and document firewall rules for DNS, including TCP 53.
• After NIC changes, VM migrations or IP changes, re-check Get-TransportService | Format-List Name, *DNS*.
• Review internal zones and conditional forwarders for partner domains you no longer host.
• Alert on queues that stay in Retry for more than 30 minutes, long before the 4.4.7 NDR. If DNS resolves but connections fail, continue with 441 4.4.1 and 421 4.4.2: stuck outbound queues.

References#

• 451 4.4.0 DNS query failed Exchange Server error in message queue (Microsoft Learn)
• DNS query failed error when an email message is stuck in the Draft folder (Microsoft Learn)