SMTP 421 4.4.3: routing server failure or no answer from host

421 4.4.3 is a temporary failure meaning the server that accepted your connection has a routing problem. Unlike a connection timeout where you never reach the server at all, here the SMTP session starts normally - the server answers your connection and often progresses partway through the transaction - but then fails specifically because it cannot route the message onward to wherever it needs to go next, whether that is an internal mail store, a downstream relay, or another server in a multi-hop delivery chain.

Who is at fault

This is a receiving-infrastructure fault, specifically in the receiving organisation's internal mail routing or DNS configuration. Common causes: a stale or broken MX/internal routing table entry, a downstream relay that is unreachable, or a DNS resolution failure for a host the receiving server itself depends on. Multi-hop delivery chains - where an organisation's edge mail gateway forwards to an internal

relay, which forwards again to the actual mailbox server - are where this fault most often

originates, because each additional hop is another opportunity for a routing table entry to go

stale after an infrastructure change. Large enterprises and managed-service mail deployments are

more likely to run this kind of multi-hop architecture than a small business on a single hosted

mailbox platform, which is part of why 4.4.3 shows up disproportionately against larger

organisations' domains rather than smaller ones.

The exchange

220 mx1.example.com ESMTP
EHLO mail.yourdomain.com
250-mx1.example.com
250 SIZE 26214400
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<recipient@example.com>
250 2.1.5 OK
DATA
354 Start mail input
421 4.4.3 mx1.example.com: routing server failure, closing connection

The connection was accepted and progressed through several commands before the routing failure surfaced and the server closed the session.

How Gmail, Microsoft 365 and Yahoo word the same condition

Microsoft 365's wording is particularly informative because it exposes the cascading nature of the fault - their edge transport server tried to reach a downstream target and got a secondary routing failure, which is precisely the mechanism 4.4.3 is describing.

Diagnostic commands

$ dig +short MX example.com
mx1.example.com.
10 mx2.example.com.

$ dig +short mx1.example.com
203.0.113.14

$ swaks --to recipient@example.com --from sender@yourdomain.com --server mx2.example.com
<~  250 2.0.0 Ok: queued as 7A1E309

Testing the secondary MX record directly is the most useful diagnostic step: if mx2 accepts the message cleanly while mx1 fails with 4.4.3, the problem is isolated to one of the destination's own mail hosts, and your queue's normal MX-fallback behaviour should already route around it on retry.

The ordered fix

1. Confirm your own MTA tries all MX records for the domain, not just the lowest-priority one, before giving up.
2. Test each MX host individually to isolate whether the routing fault is specific to one host in a multi-host setup.
3. Let the queue retry on its normal schedule - internal routing faults at the receiving organisation are typically fixed by their own admin within hours.
4. If it persists across all MX hosts for more than a day, contact the recipient through another channel.
5. Check your own DNS cache is current for the destination's MX records, in case you are retrying against a stale, decommissioned host while a corrected record has already propagated.

What not to do

• Do not assume your own domain or authentication is the cause. The fault description is specifically about the receiving server's internal routing, unrelated to your SPF/DKIM/DMARC status.
• Do not keep retrying only the failing MX host if the domain has a secondary one listed - your queue should already be trying both, but confirm it is.
• Do not suppress the recipient address. This is an infrastructure fault on their end, not a judgement about the address.
• Do not escalate send volume to "push through." A routing failure on their side will not be resolved by sending more traffic at it.

What a persistent routing failure across both MX hosts usually means

If both the primary and secondary MX records for a domain return the same 4.4.3 routing failure

over an extended period, the cause is less likely to be a single broken host and more likely a

shared piece of infrastructure both hosts depend on - a central DNS resolver, a shared downstream

relay, or a network path common to the whole mail environment. That is useful to mention if you do

reach the recipient through another channel, since it points their admin toward a shared-dependency

fix rather than having them check each mail host individually.

MailPilot's inbox-placement checks test delivery across a broad seed-inbox network per provider, which means an isolated routing fault at one of a domain's multiple mail hosts shows up as a localized placement issue rather than a verdict on your sending domain generally.