SMTP

SMTP timeout error

An SMTP timeout error is a TCP/socket-level failure where the connection stalls before the SMTP conversation finishes. Learn the real causes and how to fix it.

Updated Jul 1, 2026

The short answer

An SMTP timeout error means your client opened (or tried to open) a connection to the mail server but the SMTP conversation stalled before completing — it is a TCP/socket failure, not a numbered SMTP reply code. Usual causes are a blocked outbound port (commonly 25), a firewall, wrong host/port, or a slow/unresponsive server. Fix it by testing connectivity with telnet/openssl and switching to port 587 or 465.

An "SMTP timeout error" is not a standard SMTP reply code. There is no 3-digit SMTP code named "timeout." It is a transport-level (TCP/socket) failure: your client either couldn't open a connection to the mail server in time, or opened one but never received an expected response, so the library aborted. Libraries surface it under names like ETIMEDOUT / ESOCKET (Nodemailer), socket.timeout (an alias of TimeoutError since Python 3.10) in Python smtplib, or "Connection timed out." The one genuine SMTP reply in this area is server-side: 451 Timeout waiting for data from client (Amazon SES), returned when an idle client holds a connection open too long.

What causes an SMTP timeout error?

  • A blocked outbound port. Port 25 is the classic culprit — most ISPs and cloud providers block or throttle it to fight spam. Amazon EC2 restricts port 25 by default; you must request removal of the limit or use another port.
  • A firewall, security group, or antivirus dropping outbound SMTP packets silently (the connection never establishes, so it times out rather than being refused).
  • Wrong host or port — e.g. pointing port 465 (implicit TLS) at a STARTTLS-only endpoint, or vice versa, so the handshake hangs.
  • A slow or unresponsive server, or your client's configured timeout being shorter than the server needs. RFC 5321 §4.5.3.2 tells clients to allow generous waits (5 min for the initial 220 greeting and for MAIL/RCPT, up to 10 min for the final DATA dot) because busy servers may delay under load, and a premature timeout after DATA could cause duplicate delivery. In practice, slow replies are also often caused by spam/virus/content scanning, though that is not the RFC's stated rationale.
  • Network-layer problems — high latency, an MTU mismatch (AWS recommends setting MTU to 1500 bytes), or a long-lived connection that the server's load balancer recycled out from under you.

How do I fix an SMTP timeout error?

  1. Test raw connectivity to the port. From the sending host:
telnet email-smtp.us-east-1.amazonaws.com 587
# or, for an implicit-TLS endpoint:
openssl s_client -connect smtp.example.com:465 -crlf

A 220 greeting means the path is open and the problem is in your code/credentials. A hang or "Connection timed out" confirms a network/firewall/port block.

  1. Switch ports if 25 is blocked. Use 587 (STARTTLS) or 465 (implicit TLS) — both are valid submission ports per RFC 8314; neither is deprecated. On EC2, ports 465/587 are not throttled, or request removal of the port-25 limit.
  2. Open the firewall / security group for outbound traffic on the port you chose, and confirm no antivirus or proxy is intercepting it.
  3. Verify host, port, and TLS mode match. Don't mix implicit TLS (465) with STARTTLS (587) settings.
  4. Raise your client timeouts if the network is slow. Nodemailer defaults are connectionTimeout 120000 ms, greetingTimeout 30000 ms, socketTimeout 600000 ms — increase them in the transport config:
nodemailer.createTransport({
host: "smtp.example.com",
port: 587,
connectionTimeout: 60000,
greetingTimeout: 30000,
socketTimeout: 300000,
});
  1. Add retry logic and recycle connections. SMTP needs several round trips, so transient network errors are normal; retry with backoff, and open a fresh connection after a batch rather than reusing one indefinitely (long-lived connections get dropped when the provider's load balancer rotates instances).

Tip: if you're hitting timeouts because your own outbound port is blocked, sending through an API-based provider (or Courier, which fans out to SES/SendGrid/etc. over HTTPS) sidesteps SMTP port restrictions entirely.

FAQ

Common questions

No. There is no numbered SMTP reply code called "timeout." It is a TCP/socket-level failure where the connection stalls before the SMTP exchange completes, reported by client libraries as ETIMEDOUT, ESOCKET, or socket.timeout. The closest real SMTP reply is the server-side 451 'Timeout waiting for data from client.'

One API, every provider

Stop debugging raw provider errors

Courier connects to your email, SMS, and push providers, handles retries and failover, and surfaces delivery errors in plain language.

Reply-code definitions per RFC 5321 §4.5.3.2. Last reviewed Jul 1, 2026. Courier is not affiliated with third-party providers; error behavior may vary by implementation.