SMTP error 4.4.1 No answer from host

What SMTP error 4.4.1 means

Your mail server tried to open a connection to the destination and got silence. Not a refusal, an absence of any reply, reported as 451 4.4.1. The registry allows it only as a transient failure, so the message is still in the queue and being retried: Exchange Online warns the sender after a few hours and gives up after roughly a day, at which point the delay notice becomes a genuine bounce. Silence is the signature of a host that is down or of a firewall dropping packets rather than rejecting them.

Network and routing status
Sent by Your own sending system, reporting on the destination it could not reach
Common

What SMTP error 4.4.1 No answer from host actually means

Everything about this code turns on the difference between no answer and refused. A refused connection is immediate and definite: the far end sends a reset and your server knows it in milliseconds. No answer means your server sent its opening packet and waited out the whole timeout with nothing coming back, and then wrote this report itself. The receiving organisation has no record of the attempt at all, which is exactly why the recipient will tell you their email is working perfectly. What you are diagnosing is a path and a listener, not a policy.

The outbound connection attempt was not answered, because either the remote system was busy, or was unable to take a call. This is useful only as a persistent transient error.
— RFC 3463

How 4.4.1 appears in a bounce

A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists 451 4.4.1 as the pairing for this status.

The leading 4 is the server's verdict rather than part of the code's identity: it marks this as a temporary failure, which means the sending server is still retrying.

What causes SMTP error 4.4.1 on a business phone system

The destination server is down or restartingStill common at smaller organisations running one mail server in a comms room. A power event, a patch reboot or a failed disk takes it offline and every sender in the country queues for them until it returns.
A firewall dropping port 25 rather than rejecting itA drop rule produces exactly this symptom, and it is often applied by country or by sender reputation. Your traffic is being discarded silently while everyone else gets through, which is why the recipient sees nothing wrong.
An MX record pointing at a host that no longer existsThe name still resolves because the DNS record was never cleaned up after a migration or a hardware replacement. The address it resolves to belongs to nothing, or to something that ignores port 25 entirely.
The far end overloaded and not answering new connectionsA server whose connection backlog is full stops accepting new sessions without saying so. From your side it is indistinguishable from a machine that is switched off, and it typically clears on its own once the backlog drains.
Deliberate stalling of unknown sendersSome filtering appliances hold new connections open without responding, or greylist by refusing to complete the handshake, as a cheap way of discouraging bulk senders. Legitimate mail gets through on a later attempt, which is why these faults often resolve themselves.

How to fix SMTP error 4.4.1

Prove whether it times out or is refusedConnect to the destination MX on port 25 from a connection outside your network. A prompt refusal and a long hang are two different faults, and knowing which one you have decides everything that follows.
Resolve the MX and check the address is liveLook up the MX records for the recipient domain and test each in priority order. A record naming a host that does not answer, while a lower-priority one does, is a fault you can report to them precisely.
Work out whether it is one destination or everythingIf mail to every domain produces this, the problem is your own outbound path: an ISP blocking port 25, a broken egress rule, or a smart host that has gone away. If it is one domain, the problem is at their end or on the path between you.
For inbound failures, check your public address and NATWhen senders report this against you, confirm your MX still names your current external address, that port 25 is forwarded to the right internal host, and that your firewall is not dropping traffic from whole regions.
Let the retry window do its work before resendingTell the sender the message is queued rather than lost, and give them the retry period. Resending the same message repeatedly adds copies to the queue and delivers a pile of duplicates the moment the far end returns.

Fixing the underlying problem

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

Questions about SMTP error 4.4.1

How long will Microsoft 365 keep trying before it bounces?

Exchange Online holds a transiently failed message for around 24 hours, sending the user a delay notification a few hours in so they know it has not gone yet. If the destination is still unreachable at the end of that window the message is returned as a hard bounce, and the code in the NDR is usually still 4.4.1.

The recipient insists their email is working. Who is right?

Both of you, probably. Their mail is arriving from senders on other paths and other IP addresses, while your traffic specifically is being dropped or is reaching a host that no longer answers. Ask them to check their firewall for a rule matching your sending address, and to confirm every MX record they publish is live.

Should we resend the message?

No. A 4.x.x code means your own system still has the message and is retrying on a schedule. Resending creates a second copy that will be delivered alongside the first, and it does nothing to shorten the wait.

Could our own firewall be causing this on outbound mail?

It can, though it is less common than the far end being at fault. Outbound filtering, a broken NAT rule or an ISP restricting port 25 will all produce timeouts. The giveaway is that every destination fails rather than one.

Related SMTP status codes

Source. SMTP error 4.4.1 No answer from host 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