aws ses timeout

An "AWS SES timeout" is not an SMTP reply code — it's a client-side connection failure (a TCP connect or read timeout) raised when your application can't complete the handshake with the Amazon SES SMTP endpoint such as email-smtp.us-east-1.amazonaws.com. It is distinct from the SMTP-level 451 Timeout waiting for data from client, which SES returns when an already-open session sits idle too long. This page covers the connection timeout.

What causes an AWS SES timeout?

Per the Amazon SES SMTP troubleshooting guide, timeouts connecting to the SES SMTP interface come from a small set of network causes:

• EC2's default port 25 block. Amazon EC2 throttles outbound (egress) traffic on port 25 for all instances by default. If your app connects to SES on port 25, it will hang and time out until you request removal of that restriction — or, far easier, switch to a port that isn't restricted.
• Security group or network ACL blocking the port. The instance's security group outbound rules, or the subnet's network ACL rules, don't permit the SMTP port you're using.
• No path to the internet. A private-subnet instance with no NAT gateway / internet gateway / VPC endpoint route can't reach the public SES endpoint.
• Wrong endpoint or region. SES SMTP endpoints are regional (email-smtp.<region>.amazonaws.com); pointing at the wrong host or a region you aren't set up in produces a timeout.
• MTU too large. AWS specifically calls out that an oversized network interface MTU can surface as a time-out; setting the MTU to 1500 bytes resolves it.
• Stale long-lived connection. The SES SMTP endpoint sits behind an Elastic Load Balancer; backing EC2 instances are rotated, so a connection held open too long silently becomes invalid.

How do I fix an AWS SES timeout?

1. Use port 587 or 465 instead of 25. Both are valid for SES and neither is subject to the EC2 port 25 restriction. Use 587 (STARTTLS) or 465 (TLS Wrapper / implicit TLS) — SES also exposes 2587 and 2465 as alternates.

2. Test raw TCP connectivity from the sending host, replacing the port as needed:

telnet email-smtp.us-east-1.amazonaws.com 587

If telnet hangs, the network is blocking the port — the connection never reaches SES.

3. Test the TLS handshake if TCP connects but sending still times out:

openssl s_client -connect email-smtp.us-east-1.amazonaws.com:465 -crlf -quiet

4. Open the ports in your VPC. Allow outbound TCP 587/465 (or 25) in the instance security group, allow the same outbound in the subnet network ACL, and — because network ACLs are stateless — allow inbound TCP on the ephemeral range 1024–65535 so return traffic isn't dropped.

5. Confirm internet egress. A private subnet needs a NAT gateway (with a route) or an SES interface VPC endpoint; a public subnet needs an internet gateway and a public/Elastic IP.

6. Set MTU to 1500 bytes on the sending host if timeouts persist after the network checks pass.

7. Recycle SMTP connections. Don't hold one connection open indefinitely — open a fresh connection after a fixed number of messages or elapsed time, and add retry logic with exponential backoff so transient 4xx/network errors are retried rather than dropped.

If you reach SES through Courier, you don't manage SMTP sockets at all — Courier calls the SES API over HTTPS, sidestepping the port 25 block and ELB connection-rotation issues entirely.