Skip to content

SMTP egress (ports 25/465/587) through NAT Gateway silently dropped, even after EC2 email-sending limits were removed

0

I'm hitting an SMTP egress problem that I've narrowed down to the NAT Gateway path specifically, and I'd appreciate help understanding why.

ENVIRONMENT (region eu-west-1)

  • EKS workloads (pods + nodes) in private subnets that egress to the internet through a NAT Gateway.
  • Several EC2 instances in public subnets that egress directly via the Internet Gateway using their own Elastic IPs.

SYMPTOM

Outbound TCP to SMTP submission ports 25, 465, and 587 is SILENTLY DROPPED from anything egressing via the NAT Gateway:

  • SYN is sent, no SYN-ACK and no RST come back, the connection just hangs and times out.
  • This happens to every external mail server I test (Gmail SMTP, Office 365 SMTP, and the regional Amazon SES SMTP endpoint).
  • On the IDENTICAL path/host, port 2587 (SES alternate submission port) connects in well under a second, and general egress (HTTPS/443 to non-mail hosts) works fine.
  • So only ports 25/465/587, only via the NAT Gateway, are blackholed.

WHAT WORKS vs WHAT DOESN'T

  • From the EC2 instances (direct IGW egress, instance Elastic IPs): SMTP 587 connects fine.
  • From the EKS pods/nodes (NAT Gateway egress): SMTP 587 times out. Same region, same account, same destinations — the only difference is whether the traffic leaves via an instance's own EIP (works) or via the NAT Gateway (blocked on 25/465/587).

STEPS I'VE ALREADY TAKEN TO RULE OUT MY OWN CONFIG

  1. EC2 email-sending limits ("remove email sending limitations") were already lifted for the account/region — confirmed because all the direct-IGW instances send on 587 successfully.
  2. Ruled out IP reputation: I replaced the NAT Gateway's Elastic IP with a brand-new allocation. A fresh, never-used IP is STILL blocked on 25/465/587 via the NAT.
  3. Ruled out a Kubernetes/CNI/pod issue: tested from the EKS node host itself (not a pod) — same block. So it's the node→NAT→internet path, not anything in the pod network.
  4. Security Groups on the node/ENI: egress is all-protocols to 0.0.0.0/0 (no port restriction).
  5. Network ACLs on the subnet: egress allows all to 0.0.0.0/0; ingress allows the TCP ephemeral return range (1024-65535). No port-specific deny.
  6. Route table: private subnets route 0.0.0.0/0 to the NAT Gateway (active). NAT Gateway is "available", connectivity type public.
  7. No Traffic Mirroring, no Gateway Load Balancer, no egress-only Internet Gateway, and no interface VPC endpoints that could intercept SMTP (only an S3 Gateway endpoint, which is unrelated).

QUESTION

Is outbound SMTP (25/465/587) throttled or blocked for NAT Gateway egress separately from EC2 instance/IGW egress — i.e., does the standard "remove email sending limitations" only cover traffic egressing from EC2 instance Elastic IPs and NOT traffic egressing via a NAT Gateway? If so, how do I get the SMTP egress restriction lifted for the NAT Gateway path, given the instance-EIP removal doesn't appear to cover it?

I've confirmed there is no Security Group, NACL, route table, or VPC-level interception on my side; the silent drop (timeout, no RST) is consistent with an upstream throttle that's specific to the NAT Gateway egress path.

asked a month ago66 views

1 Answer
1

You are completely right that this is an account/region-level setting, but you are hitting a very common, "frustrating" regarding how this limit is actually applied in the backend.

How I solve it in my case

AWS Support workflow again specifically for new EIPs:

  1. Open a new case (or reopen the previous one if possible) using the Request to remove email sending limitations form.
  2. Explicitly provide the new Elastic IP of your NAT Gateway.
  3. If you need external mail servers to accept your traffic without dropping it due to spam policies, use this same ticket to request a Reverse DNS (PTR) record for that new NAT Gateway EIP.
  4. Be prepared to nudge them: Don't be surprised if you have to reply to the ticket or re-open it more than once. AWS Support is notoriously inconsistent with this specific legacy SMTP block, and it often takes a second attempt to get a technician to properly flag the new EIP in the backend.

-> https://repost.aws/knowledge-center/ec2-port-25-throttle

-> https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html#port-25-throttle

EXPERT

answered a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.