SMTP 421 4.4.1: no answer from host

421 4.4.1 is a 4xx temporary deferral meaning your sending server attempted to connect to the recipient's mail server but received no response within the expected time — the MX record resolved and a connection attempt was made, but the remote host didn't answer. This is distinct from 4.4.2 (connection established, then dropped) and from DNS-resolution failures (no MX record at all, which produces a different error class entirely).

Who is at fault

Usually the recipient's infrastructure — an overloaded, misconfigured, or temporarily unreachable mail server — though a problem on your own outbound network path or DNS resolution can produce the same symptom.

The exchange

$ Attempting connection to mx.example.com:25
[connection attempt made, no response within timeout]
421 4.4.1 No answer from host (locally generated by sending MTA after timeout)

Note this reply is often generated locally by your own outbound MTA after it gives up waiting, rather than relayed from the recipient's server — which never responded at all.

How the big three word it

This condition is reported almost entirely by your own outbound mail server's log, since the recipient's server never sent anything — it's a timeout, not a reply.

Diagnose it

$ dig MX example.com +short
$ nc -vz mx.example.com 25
$ mtr -rw mx.example.com

Confirm the MX record resolves correctly, then test raw TCP connectivity to port 25 on that host, then check your network path for packet loss if the port test itself hangs.

Fix it, in order

1. Confirm the MX record is correct and currently valid — a stale or misconfigured MX on the recipient's side will produce exactly this symptom.
2. Let the automatic retry queue work. Most occurrences clear within the normal retry window as the recipient's server comes back.
3. Check your own outbound connectivity on port 25 if this is happening broadly across many recipient domains rather than one — some hosting providers block or throttle outbound port 25 by default.
4. If persistent against one specific domain over days, there may be a genuine, longer-term problem with their mail infrastructure — limited action is available from the sending side beyond continuing to retry and, for known contacts, reaching them another way.

A cause worth separating out: DNS resolution failure versus no answer

It's worth drawing a sharper line here, since the fix differs. 4.4.1 specifically means the MX record resolved and a connection attempt was made, but nothing answered within the timeout. If the MX lookup itself fails — no MX record, or a DNS server that doesn't respond — most MTAs generate a different error entirely (commonly referencing DNS or host-resolution failure explicitly in the log, rather than issuing 4.4.1), because the connection attempt was never even made. If your logs show 4.4.1 specifically, you can rule out a DNS problem on the recipient's side and focus on connectivity to a host that is, at least in principle, known and reachable.

An additional diagnostic command

$ dig +trace MX example.com

A full trace from the root servers down, rather than a simple lookup against your resolver's cache, surfaces whether the recipient's own DNS delegation is itself intermittently failing — a cause that looks identical to a simple connection timeout from your side but requires the recipient to fix their nameserver configuration, not their mail server.

How long a genuine no-answer condition typically persists

A truly unreachable host usually resolves within the scope of normal infrastructure maintenance — minutes to a few hours for a routine restart or failover, occasionally a day or more for a more serious outage. Most MTA retry schedules are generous enough (commonly extending to 3–5 days before formally giving up) to ride out all but the most serious recipient-side outages without you needing to do anything beyond letting the queue work. If a specific domain stays unreachable past that point across multiple MX hosts (check for more than one MX record before concluding this), it's worth escalating to the contact through another channel rather than continuing to retry indefinitely.

What not to do

• Don't treat this as a reputation or content issue. The recipient's server never evaluated your message at all; it never answered.
• Don't remove the recipient from your list after one occurrence. This is a connectivity symptom, not evidence of an invalid address.
• Don't confuse it with 421 4.4.2. 4.4.1 means no response ever arrived; 4.4.2 means a connection was established and then dropped. The diagnostic path differs for each.

MailPilot distinguishes connectivity-layer deferrals like this from reputation or content-based rejections in its bounce classification, so a recipient server being briefly unreachable doesn't get misdiagnosed as a problem with your sending domain.