550 5.4.4 DNS Query Failed: How to Diagnose the Real Cause

You send a message, and a bounce comes back: 550 5.4.4 DNS query failed, sometimes followed by unable to route. Most advice online ends with contact your administrator. That is not much use if you are the administrator, or if you just need one email to get through today.

This post is a five-minute DNS triage you can run yourself. It covers the three families of cause behind 5.4.x routing failures: a recipient domain with no usable MX, a broken resolver on your side, and a split-routing setup that sends mail around in circles.

What does 550 5.4.4 DNS query failed actually mean?#

The three digits split into two parts. The 550 is the basic SMTP reply: a permanent failure. The 5.4.4 is an enhanced status code, and RFC 3463 defines X.4.4 as unable to route. In plain terms, the mail system could not determine the next hop because the routing information was unavailable from DNS.

Before an SMTP server can send anything, it must resolve the recipient's domain. RFC 5321 section 5.1 says it looks for an MX record first. If there are no MX records at all, it treats the domain's own A or AAAA record as an implicit MX. If MX records exist but none are usable, or the implicit MX is unusable, the sender must report an error. That error is your bounce.

The exact text varies by vendor and version. Some servers say DNS query failed, others Unable to route or Host or domain name not found. The enhanced code 5.4.4 is the consistent part, and it tells you the problem is in routing, not in the mailbox or the message content.

What are the common causes, and how do I confirm each one?#

Almost every 5.4.4 bounce lands in one of the rows below. The right column is the fix; the middle column is the quick test that tells you whether that row is yours.

Fix 1: How do I check the MX record of the recipient's domain?#

Start with the recipient domain, because that is the most common culprit. You need a terminal on any computer; the recipient's server does not have to be reachable. Replace example.com with the domain after the @ sign.

1. 1

   Look up the MX records

   Run dig MX example.com +short. On Windows use nslookup -type=MX example.com. A healthy domain returns one or more lines such as 10 mail.example.com. An empty result means no MX is published.

2. 2

   Read the status, not just the answer

   Run dig MX example.com without +short and look at the status line. NXDOMAIN means the domain does not exist. NOERROR with an empty answer means the domain exists but has no MX. SERVFAIL means the lookup itself broke, which points at the domain's name servers or at DNSSEC.

3. 3

   Apply the A-record fallback rule

   If there is no MX, run dig A example.com +short and dig AAAA example.com +short. Per RFC 5321, an address record alone is enough for delivery. If those are empty too, the domain cannot receive mail and the bounce is correct.

4. 4

   Check every MX target resolves

   For each hostname in the MX list, run dig A and dig AAAA on it. A target with no address record is unusable. If every target is dead, you get exactly this bounce. Also check the target is not a CNAME, which RFC 5321 places outside the standard.

5. 5

   Check for a null MX

   An MX answer of 0 followed by a single dot is a null MX under RFC 7505. It means the domain deliberately accepts no mail. Do not try to work around it; use another address or channel.

Fix 2: What if my own DNS resolver is the problem?#

If the recipient's records look healthy from your laptop but your server still bounces, test from the sending side. A mail server that cannot reach a working resolver fails on every domain, not just one, so this is the cause to suspect when 5.4.4 appears across unrelated recipients.

1. 1

   Test from the sending server itself

   Log in to the machine that sends the mail and run the same dig MX command there. A result that differs from your laptop points at the server's resolver configuration.

2. 2

   Compare against a public resolver

   Run dig @8.8.8.8 MX example.com and dig @1.1.1.1 MX example.com. If these succeed and the server's default resolver fails, the local resolver is broken, overloaded or filtering.

3. 3

   Check outbound DNS is allowed

   DNS needs outbound UDP and TCP on port 53. Firewall rules, a split-horizon internal DNS server or a recently changed forwarder can silently block it. Ask whoever manages the network what changed first.

4. 4

   Flush stale or negative cache entries

   A resolver can cache a failure after a recipient fixes their records. Flush the cache on the resolver, or wait out the record's TTL, then retry the message.

Fix 3: What if the error is a routing loop (5.4.6)?#

Sometimes the bounce is a close cousin: 5.4.6 routing loop detected. RFC 3463 defines X.4.6 as a message forwarded too many times because of incorrect routing tables or a forwarding loop. Microsoft's documentation lists 5.4.6 for on-premises Exchange in hybrid setups and 5.4.14 for Exchange Online, and says Exchange interrupts the loop after 20 iterations.

A loop usually appears in a split-routing setup: two systems each believe the other is responsible for a domain. The first server forwards to the second, the second forwards back, and neither ever delivers.

1. 1

   Read the Received headers in the bounce

   Open the original headers and look for the same two or three server names repeating. That tells you which systems are bouncing the message between them.

2. 2

   Check how the domain is classified

   Microsoft's first check is that the recipient's domain is an authoritative accepted domain in Exchange Online. In hybrid setups, it also points to the connector to on-premises: it should use smart host routing, not DNS routing. Rerunning the Hybrid Configuration Wizard is its suggested fix.

3. 3

   Look for forwarding rules and aliases

   A mailbox rule that forwards to an address which forwards back creates the same loop with no DNS involved. Check the sender's and recipient's mailbox rules and any shared-alias setup.

4. 4

   Retest after the change

   Send a fresh message, not a retry of the bounced one, and compare headers. Hop count should stop at the final server.

How do I tell which cause I have?#

Work from the cheapest test to the most expensive. The order below follows how often each cause shows up, and it takes about five minutes.

• One recipient domain fails, everything else is fine: run Fix 1. The problem is almost certainly the recipient's DNS or a typo.
• Every domain fails, or every domain outside your own: run Fix 2. The sending side cannot resolve anything.
• The bounce says loop, or headers repeat server names: run Fix 3. DNS is probably fine and your routing config is not.
• The domain worked last week: the recipient changed hosting. Check whether their MX target was decommissioned.
• It fails only for your domain's internal users: suspect split-horizon DNS, where internal and external views of your zone disagree.

How do I stop it happening again?#

If you run the domain that is bouncing, treat DNS as part of your mail configuration, not a one-time setup. Keep a short record of every MX and the host it points at, and re-verify after any migration. The failure that causes 5.4.4 is usually a hostname someone decommissioned while an MX still pointed at it.

Use at least two MX records with different preferences when your provider supports it, and publish a null MX on domains that should never receive mail so senders get a clear answer instead of a retry. Lower the TTL a day before a mail migration so a mistake corrects quickly.

If you are the sender, the cheapest habit is to double-check the domain on any address typed by hand, especially for first-time contacts. A swapped letter in the domain is a more common cause of 5.4.4 than a real outage.

Where does AI Emaily fit in?#

A 5.4.4 bounce is a loop left open: the message you meant to deliver did not arrive, and nobody told the recipient. AI Emaily cannot repair anyone's DNS or change an MX record, and it is not a deliverability tool. We build AI Emaily, so weigh this accordingly.

What it does is the part after the diagnosis. The agent triages your inbox, so failed-delivery notices are surfaced instead of buried, and it drafts the follow-up once you have fixed the address or the record. In Copilot mode nothing sends until you approve it. There is a 7-day free trial; see the pricing page for current details.