4.4.1: connection to the recipient's mail server timed out

What the bounce means

A 4.4.1 status means your mail server tried to connect to the recipient's mail server and the connection timed out: nothing answered on the other end before your server stopped waiting. The exact wording varies by server, and the three-digit SMTP reply it is paired with varies too; the enhanced code 4.4.1 is the reliable part to search on.

Because it is a temporary failure, your server does not drop the message. It goes back into the outbound queue and gets retried automatically, usually on a backoff schedule over hours and then days. That is why most people never see a raw 4.4.1 at all: the bounce that finally lands in their inbox is the 4.4.7 expiry issued days later, after every retry hit the same wall. If you are reading a 4.4.1 now, it is most likely quoted inside that expiry report, or a delay warning your server sent while still retrying.

Why it is almost always the receiving side

A timeout says nothing about your message and everything about the path to theirs. The common causes all live on the recipient's side:

• Their mail server is down or unreachable. A crashed service, a dead host, or a network outage between you and them.
• Their server is overloaded. It is up but accepting connections too slowly, so yours gives up waiting.
• A firewall is silently dropping the connection. A misconfigured rule on their edge that eats inbound port 25 traffic instead of refusing it produces exactly this: silence, then timeout.

In all three cases there is nothing to fix on your side. Your server keeps retrying, and when their infrastructure recovers the mail goes through on the next attempt.

When the timeout is actually yours

The exception is when everything you send times out, not just mail to one domain. That pattern points at your own sending path:

• Your outbound port 25 is blocked. Many cloud and residential networks block outbound SMTP by default. Your server dials out, nothing ever connects, and every destination looks down.
• Your DNS resolver is serving a stale MX. If the recipient's domain recently moved mail providers and your resolver is still handing back the old MX target, you are faithfully timing out against a server that no longer takes their mail.

How to work out whose side it is

The question to answer is: can anything else reach that mail server? If a colleague on a different network, or a second mail service you use, can deliver to the same domain while your server times out, the problem is on your path. If nobody can get through, it is theirs. Two more quick reads: if your server is timing out against every domain, suspect your own outbound before anything else; and if it is one domain only, and has been for days, contact the recipient through another channel, because their mail infrastructure is likely down and their own team may not know yet.

Frequently asked

Is 4.4.1 a permanent bounce?

No. 4.4.1 is a temporary failure: your server could not reach the recipient's server on this attempt, so it keeps the message in its queue and retries automatically. It only becomes final if every retry fails until the queue gives up, which produces a separate 4.4.7 expiry bounce.

Should I resend the message after a 4.4.1?

Not immediately. Your server is already retrying on its own schedule, and a manual resend just adds a second copy to the same queue. If the recipient's server recovers, both copies arrive. Resend only after a final expiry bounce tells you the original was dropped.

Is a 4.4.1 timeout my fault or the recipient's?

Usually the recipient's: their mail server is down, overloaded, or behind a firewall that is dropping connections. It becomes your problem when mail to every domain times out, which points at your own server's outbound connectivity, a blocked port 25, or a DNS resolver handing back stale answers.

Why did I get a different bounce days after the 4.4.1?

That later bounce is the expiry. After repeated timeouts your server stops retrying, typically after a few days, and issues a 4.4.7 delivery-expired bounce that summarizes the failure. The 4.4.1 was the per-attempt error; the 4.4.7 is the queue giving up on it.