5.4.4: no route to the recipient's domain

What the bounce means

A 5.4.4 status, which usually appears with a 550-style reply though the three-digit code varies by server, means your mail server resolved the recipient's domain in DNS but could not find a usable route to deliver mail to it. In practice that is one of two DNS states:

• No MX record and no fallback. The domain publishes no MX records, and there is no A record to fall back on, so there is nowhere to even attempt a connection.
• MX records pointing at dead names. The domain publishes MX records, but the hostnames they point at do not resolve. The route exists on paper and goes nowhere.

Either way your server has nothing to connect to, and because the failure is structural rather than momentary, it is classed as permanent: the message is dropped, not queued.

It is usually their DNS, not yours

The reflex on any 5.x.x bounce is to audit your own configuration, but 5.4.4 describes the receiving domain's DNS. The classic cause is a corporate migration: a company moves mail providers or restructures its DNS zone, and the MX records get dropped or left pointing at the old provider's decommissioned hostnames. Mail from everyone, not just you, starts bouncing, and the recipient often has no idea because their outbound mail still works fine.

Verify it from the outside before acting. Query the recipient domain's MX records with any DNS lookup tool: if the answer is empty, or the hostnames it returns do not themselves resolve, you are looking at the broken route your server saw, and the fix belongs to whoever runs that domain's DNS. Tell the recipient through another channel; a domain in this state is unreachable for every sender, and the report is a favor.

When it is your side after all

Two configurations on the sending side can produce the same code. A DNS resolver that is failing or returning bad answers for MX lookups makes healthy domains look routeless. And an internal routing rule, such as a smarthost or an address-book entry that pins a domain to a specific relay, fails with no route when that relay is decommissioned. The scope of the failure is the tell: one destination bouncing while everything else flows is their DNS; many unrelated destinations bouncing at once is your resolver or your routing table.

Not the same as 5.1.2

5.4.4 is easy to confuse with 5.1.2, domain not found, but they describe different failures. With 5.1.2 the domain does not exist in DNS at all, and the overwhelmingly common cause is a typo in the address. With 5.4.4 the domain exists and resolves; what is broken is specifically its mail routing. A typo gets fixed by correcting the address and resending. A broken route gets fixed only by the domain's owner repairing their DNS.

Frequently asked

Is 5.4.4 my problem or the recipient's?

Usually the recipient's. 5.4.4 means your server looked up their domain's mail routing in DNS and found nothing usable: no MX record and no fallback, or MX records pointing at names that do not resolve. That is their DNS to fix. Verify with an MX lookup of your own before assuming anything on your side.

What is the difference between 5.4.4 and 5.1.2?

5.1.2 means the domain itself does not exist in DNS at all, which usually indicates a typo in the address. 5.4.4 means the domain exists and resolves, but its mail routing is broken: there is no usable route to hand the message to. One is a bad address; the other is a real domain with broken mail DNS.

Will retrying fix a 5.4.4 bounce?

No. 5.4.4 is a permanent failure, so your server has already dropped the message and will not retry. Sending again only helps after the domain's mail routing is repaired. If you need to reach the recipient before then, use another channel and let them know their mail DNS looks broken.

Can my own server cause a 5.4.4?

Rarely, but yes. A DNS resolver on your side that fails MX lookups, or an internal routing rule pointing a domain at a relay that no longer exists, produces the same code. The tell is scope: one destination failing points at their DNS; many unrelated destinations failing points at your resolver or routing configuration.