5.4.4: Unable to route: no mail server found for the domain

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code: varies; the enhanced code is the part that identifies the problem.
• Enhanced code 5.4.4: “Unable to route” in the IANA registry (RFC 3463), in the group network and routing status (RFC 3463 §3.5).

Your mail system could not work out where to deliver the message: DNS gave it no usable mail server for the recipient's domain. The address may be spelled correctly, but the domain is not set up to receive mail.

What it means

RFC 3463 §3.5 defines X.4.4 as "unable to route": the mail system could not determine the next hop because the routing information was not available from the directory server, which for Internet mail is DNS. The RFC gives a DNS lookup that returns only an SOA record as an example. The code can be permanent (5.4.4) or transient (4.4.4). The bounce comes from whichever system was trying to route the message, which is often your own sending server or relay rather than the recipient's.

How a server finds the destination

RFC 5321 §5.1 sets the steps:

• Look up the domain's MX records.
• If there are no MX records at all, treat the domain itself as the mail host, using its address records.
• If MX records exist, use only the hosts they name, and each must resolve to an address record.
• If MX records exist but none is usable, or the fallback host is unusable, report an error.
• If DNS returns a temporary error, queue the message and retry.

A 5.4.4 is the "report an error" outcome.

Common causes

• The domain has neither MX records nor address records.
• The MX record points to a host name that does not resolve, for example after a mail provider change.
• The MX target is an IP address or an alias (CNAME). RFC 5321 §5.1 expects a host name that has its own address record.
• The domain is a typo of a real domain, and the typo exists only as a bare registration.

How to fix it

If you are the sender:

1. Check the domain for typos.
2. Run dig MX example.com, then dig A and dig AAAA on each host it returns. If nothing resolves, the bounce is correct.
3. A 4.4.4 that keeps appearing can point to DNS trouble on your side; check your server's resolver.

If the domain is yours:

1. Publish MX records that name your mail provider's host names, exactly as the provider documents them.
2. Make sure every MX host has an A or AAAA record.
3. After a change, wait for the old records to expire, then send a test from an outside account.

What to do with the address

If the domain has no mail setup at all, remove the address. If the domain belongs to a working business whose DNS broke recently, hold the address and try again in a few days before deciding.

Related codes

• 553 5.1.2: The recipient domain does not exist or takes no mail
• 556 5.1.10: The recipient domain publishes a null MX: it takes no mail
• 4.4.7: The message expired in the queue

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.