SMTP error 5.4.4 Unable to route

What SMTP error 5.4.4 means

The mail system could not work out where to send the message next. In Microsoft 365 this is the classic post-migration bounce, reported to users as 550 5.4.4, and it is nearly always a routing or DNS configuration fault rather than a problem at the far end. A missing MX record, an accepted domain set to the wrong type, a connector left over from a migration or a domain never verified in the tenant produce most of them. The registry allows both classes, so a 4.4.4 is the same condition with the sender still retrying.

Network and routing status
Sent by The mail system choosing the next hop, which on Microsoft 365 is very often your own tenant
Common

What SMTP error 5.4.4 Unable to route actually means

Routing is a decision, and this code says the decision could not be made. The distinction from 5.1.2 matters: 5.1.2 says the destination domain is not a mail domain at all, whereas this says the domain is real and no path to it could be determined. The order in which Exchange Online decides is what catches people out. The tenant checks the recipient domain against its own accepted domains before it ever consults public DNS, so a domain listed as authoritative with no matching mailbox is refused internally and never leaves Microsoft, no matter how correct the public MX record is. Reading the NDR to see which host generated it tells you immediately whose configuration is at fault.

The mail system was unable to determine the next hop for the message because the necessary routing information was unavailable from the directory server. This is useful for both permanent and persistent transient errors. A DNS lookup returning only an SOA (Start of Administration) record for a domain name is one example of the unable to route error.
— RFC 3463

How 5.4.4 appears in a bounce

The leading 5 is the server's verdict rather than part of the code's identity: it marks this as a permanent failure, which means the sending server has given up and returned the message. The same condition reported as 4.4.4 is the other verdict on the identical problem, so a log showing that form has not produced a bounce yet.

RFC 3463 is explicit about which verdicts this code can carry: “This is useful for both permanent and persistent transient errors.”

What causes SMTP error 5.4.4 on a business phone system

The recipient domain publishes no MX recordA zone rebuilt after a hosting change, or one that only ever had an A record, gives the sender nothing to route to. A lookup that returns only the zone's own start of authority record is the textbook example named in the definition.
An accepted domain set to authoritative when mail should relay onwardsThe single most common cause on Microsoft 365. The tenant believes it holds every mailbox in the domain, so when an address has no mailbox it refuses rather than sending the message out. Half-finished migrations leave domains in this state routinely.
A connector still pointing at a decommissioned serverOutbound connectors configured during hybrid coexistence keep sending mail to an on-premise smart host after that server has been switched off or renamed. The tenant has a route, follows it, and finds nothing at the end of it.
A domain that was never verified in the tenantAdding a domain in the admin centre does nothing until the verification record is in DNS and the domain shows as verified. Until then, connectors and remote domain entries scoped to it have no effect and mail for it cannot be routed.
A missing or incorrect remote routing address in a hybrid setupOn-premise Exchange delivers to a cloud mailbox using the tenant routing address on the mail-enabled user object. If it is absent, wrong or points at a domain that has been removed, the on-premise server has no next hop to choose.
Split-brain DNS answering internally with a zone that has no MXAn internal zone created for the public domain so that internal names resolve will shadow the real one. The mail server queries internally, gets an incomplete answer and cannot route, while everything looks fine from outside.

How to fix SMTP error 5.4.4

Resolve the recipient domain's MX from outside your networkQuery a public resolver rather than an internal one so you see what the rest of the world sees. If no MX exists, the recipient has a DNS problem and nothing at your end will deliver the message.
Check the accepted domain type in the Exchange admin centreAuthoritative means every mailbox for that domain lives in the tenant. Internal relay means some live elsewhere and mail should be passed on. Set it to match where the mailboxes genuinely are, and remember that a partially migrated domain needs internal relay until it is finished.
Review every connector and what it points atCheck the smart host names still resolve, that the certificate name a connector expects still matches, and that nothing is scoped to a domain you have retired. Connectors created by a migration tool and forgotten cause a great many of these bounces.
Run a message trace and read which host made the decisionThe trace shows the last hop and the reason it stopped. A hostname from your own tenant in the diagnostic block means the fault is yours to fix, while a name belonging to the recipient means the routing decision failed on their side.
Check the remote routing address on hybrid recipientsThe mail-enabled user on-premise needs a routing address on the tenant's own mail domain, and it is the field most often left wrong when a mailbox has been moved by hand. After any change to certificates or external hostnames, rerun the hybrid configuration wizard rather than editing connectors individually.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 5.4.4

We finished a migration and now some external addresses bounce. Where do we start?

With the accepted domain type. If the domain is set to authoritative but some mailboxes are still on the old system, the tenant refuses those addresses instead of relaying them onward. Switch it to internal relay, point the relay at the remaining server, and complete the migration before switching it back.

Is this our fault or the recipient's?

The NDR tells you. Look at the reporting host in the diagnostic information: a name belonging to your own tenant or server means the routing decision failed before the message left you, while a name belonging to the recipient means their system could not decide where to put it.

It worked for two years and stopped overnight. What changes cause that?

A DNS change at the recipient, a domain renewal that lapsed, an expired certificate on a connector, or somebody decommissioning a server that a connector still names. All four are invisible until the next message tries to route.

Does this mean the address does not exist?

No. A non-existent mailbox is 5.1.1 and a domain that takes no mail at all is 5.1.2. This code means the system could not find a path, which is a configuration question rather than a statement about the recipient.

Related SMTP status codes

Source. SMTP error 5.4.4 Unable to route is defined in RFC 3463 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes