Connection refused — the recipient's mail server did not answer
Retrying later can work — at a lower rate, not the same one.
The reply
ConnectionRefusedError: [Errno 111] Connection refusedThe recipient's domain publishes a mail server, but that server would not accept a connection. This is the receiving side's problem, and it is usually temporary.
What it means
The MX lookup succeeded, so there was somewhere to go; the TCP connection to port 25 was then refused, reset or timed out. Nothing about the message was ever transmitted. Most often the server is down, restarting, or firewalled against the sending address — and a correctly configured sender treats this as a deferral and retries.
Why it happens
- The receiving mail server is down or restarting.
- An MX record pointing at a host that no longer runs a mail service.
- A firewall on the receiving side blocking port 25 from your address or from cloud ranges generally.
- The recipient's provider rate-limiting connections from your IP at the network layer.
- A misconfigured MX record pointing at the wrong host entirely.
What to do
- Let the retry schedule do its work — a transient outage clears on its own.
- If it persists for days on one domain, the MX record is probably wrong; tell the recipient, because they cannot see it from inside.
- Test the connection yourself to the MX host on port 25 to confirm what a retry will meet.
- Check that your outbound port 25 is not being blocked by your own provider, which produces the same symptom for every destination at once.
- If it fails for every domain rather than one, the problem is on your side — start with your own network.
Questions
Is this my fault?
Almost never, if it affects one recipient domain. If it affects every destination, your own provider is probably blocking outbound port 25 — a common default on cloud instances.
Will it retry?
Yes. This is a temporary condition and the message stays queued until it delivers or the retry window ends.