451 4.4.0 DNS query failed checklist

Symptoms to confirm

Mail to one or more outside domains isn't arriving, and there's no NDR yet.

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

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

Likely causes

Transport looks up the MX records of the destination domain, then the address records of those hosts.

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

Checklist

1. 1

   Read the failing queues

   powershell

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

2. 2

   See which DNS servers transport uses

   powershell

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

   Test the lookup the way transport does

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

   powershell

   $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

4. 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:
   powershell

   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:
   powershell

   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.

   +1 more in the full article.

5. 5

   Restart transport and retry the queues

   powershell

   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.

   Watch out: Don't "fix" this by adding public DNS servers to the NIC of a domain-joined Exchange server. Active Directory lookups then fail intermittently and internal routing breaks. Use ExternalDNSServers for internet lookups instead.

Verify

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