SMTP 441 4.4.1: no answer from the remote host

441 4.4.1 is best understood as your own sending system's internal record of a connection timeout, not a reply from the destination. The enhanced status 4.4.1 ("no answer from host") is standard and genuinely defined in RFC 3463 for exactly this situation - a connection attempt that received no response. Some mail transfer agents and client applications attach the base code 441 to this condition as an internal label; that base number itself does not correspond to an RFC 5321 reply code, because there is no reply to have a code - the destination never answered at all.

Who is at fault

This could be either side. A connection timeout with no answer can mean the destination mail server is down, unreachable, or overloaded to the point of not accepting new connections, or it can mean a problem on your own network path (firewall, routing, DNS resolving to a stale IP). Diagnosing which requires testing connectivity independently of your mail application. A useful habit when this occurs repeatedly is testing from more than one network path - your

office network, a mobile hotspot, a cloud instance in a different region - since a timeout that

only occurs from one specific network strongly implicates something on that network (a firewall

rule, an ISP-level block, a routing issue) rather than the destination server itself. A timeout

that reproduces identically from every network you test points the other way, toward the

destination genuinely being unreachable or down, which changes what you should do next -

troubleshoot your own network in the first case, simply wait in the second.

What actually happens (the "exchange" is an absence of one)

$ telnet mx.example.com 25
Trying 203.0.113.77...
telnet: Unable to connect to remote host: Connection timed out

Nothing is ever received over the wire; the client's own timeout fires, and the sending software logs it internally as 441 4.4.1.

How Gmail, Microsoft 365 and Yahoo word this condition when they are the sender reporting the timeout

Interestingly, Yahoo's outbound infrastructure uses the same 441 4.4.1 label internally, which is likely why this pairing has become a de facto standard shorthand even though it is not part of the RFC 5321 base reply table.

Diagnostic commands

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

$ for host in mx1.example.com mx2.example.com; do
    echo "== $host =="; timeout 10 telnet $host 25
  done

$ mtr -rw mx1.example.com

Testing every MX record individually matters - if mx1 times out but mx2 answers normally, the fault is specific to one of the destination's two hosts, not your own network path. If every MX for the domain times out identically, and other domains connect fine from the same network, the destination's infrastructure is the likely cause.

The ordered fix

1. Test connectivity directly with telnet or nc against each MX record for the destination domain, independent of your mail application.
2. Compare against a known-good destination from the same network to rule out a local firewall or ISP-level block.
3. If only this one domain times out, their infrastructure is likely down or unreachable; let your queue retry on its normal schedule.
4. If every destination times out, check your own outbound firewall rules and whether your ISP blocks or throttles port 25/587.
5. Check DNS freshness - a stale cached MX record pointing at a decommissioned IP will produce exactly this symptom.

What not to do

• Do not treat this as a bounce or remove the recipient. No SMTP session occurred, so no judgement about the address was ever made.
• Do not assume it is your fault by default. Test connectivity to other destinations first before concluding your network is the problem.
• Do not keep retrying rapidly. If the destination is genuinely down, rapid retries accomplish nothing and can make your own queue backlog worse.
• Do not flush your DNS cache repeatedly as a first step. Confirm via dig that the MX records themselves are current before assuming a caching issue.

Why this is worth logging even though it resolves itself

A connection timeout that clears on its own after a retry still tells you something: that

particular destination host was briefly unreachable from your network at that specific time. If

you log the domain and timestamp for every timeout, even transient ones, a pattern of repeated

timeouts to the same destination over weeks becomes visible in a way a single occurrence never

will - and that pattern is exactly what distinguishes "their server had a bad five minutes" from

"their server has a chronic reachability problem" worth raising with them directly.

MailPilot monitors connection-level health per destination across its send paths, which distinguishes a one-off unreachable host from a systemic problem with your own outbound network - useful context before concluding a timeout like this reflects on your domain at all.