Resolving AWS Port 25 Throttling: A Practical Guide

AWS Port 25 throttling is a common reason email works on a developer laptop but times out, stalls, or fails immediately after deployment to Amazon EC2. The important distinction is that this is usually an outbound network restriction—not an SMTP authentication, DNS, or application-code failure.

What AWS Port 25 throttling actually means

Port 25 is the traditional SMTP relay port used for server-to-server email delivery. A mail transfer agent (MTA) historically connected from one mail server to another server’s port 25, looked up through MX records, and attempted delivery directly.

AWS restricts outbound port 25 traffic from EC2 by default when the destination is a public IPv4 address or any IPv6 address. In practical terms, an application running on an EC2 instance may be unable to open a TCP connection to a public SMTP server on port 25 even when its security group, network ACL, local firewall, credentials, and email code all appear correct.

This restriction exists to reduce abuse. Unrestricted outbound SMTP from disposable or compromised cloud instances is useful to spammers, malware operators, and botnets. The result is that cloud providers generally treat direct port-25 email delivery as a higher-risk use case than web traffic or authenticated email submission.

The word throttling can be slightly misleading. Developers often expect an SMTP response such as 421 4.7.0 or a rate-limit message. In many cases, the connection never reaches the SMTP server at all. Your application instead sees a TCP connect timeout, a socket timeout, or a connection error before it can issue EHLO, authenticate, or submit a message.

That distinction determines the fix:

• A network-level port 25 restriction prevents the initial TCP connection.
• An SMTP provider limit normally returns an SMTP reply after connection.
• An HTTP API rate limit normally returns an HTTP response such as 429 Too Many Requests.
• A DNS or authentication problem lets the connection succeed but causes delivery or reputation problems later.

Do not try to solve a blocked outbound connection by changing SPF records, rotating SMTP credentials, or increasing your application retry count. Those may be important mail tasks, but none can make a blocked TCP port reachable.

Confirm that port 25 is the real problem

Before changing infrastructure, identify where the failure occurs. A fast, controlled test from the same EC2 instance, container host, or workload network that sends production mail is more useful than testing from your local machine.

Test the raw TCP connection

Use nc (netcat) to test whether a TCP handshake can be established:

nc -vz -w 5 smtp.example-provider.com 25

Replace smtp.example-provider.com with the SMTP hostname you actually use. A successful connection usually reports that the port is open or succeeded. A timeout strongly suggests that something on the network path is dropping or blocking the traffic.

For a comparison test, run the same command against port 587:

nc -vz -w 5 smtp.example-provider.com 587

And, if your provider supports implicit TLS, test port 465:

nc -vz -w 5 smtp.example-provider.com 465

If port 25 times out but 587 or 465 connects from the exact same host, AWS Port 25 throttling is the leading explanation. If every port fails, investigate security groups, network ACLs, a corporate egress firewall, a restrictive NAT or proxy configuration, incorrect DNS resolution, or a provider-side outage.

Test SMTP with TLS rather than only TCP

A successful TCP connection is necessary but not sufficient. You also need to verify the TLS mode required by the SMTP endpoint.

For SMTP submission over STARTTLS on port 587:

openssl s_client \
  -starttls smtp \
  -connect smtp.example-provider.com:587 \
  -servername smtp.example-provider.com \
  -crlf

For implicit TLS on port 465:

openssl s_client \
  -connect smtp.example-provider.com:465 \
  -servername smtp.example-provider.com \
  -crlf

A healthy STARTTLS session typically displays a server certificate and eventually an SMTP greeting such as:

220 smtp.example-provider.com ESMTP ready

After the greeting, you can type:

EHLO test.example.com

The server should return one or more 250- capability lines. On a submission endpoint, capabilities may include STARTTLS, AUTH, and message-size limits. Do not send real credentials through an untrusted terminal session or paste them into tickets, chat tools, shell history, or shared logs.

Separate timeouts from SMTP replies

An application log might show one of several very different failure patterns:

Error: connect ETIMEDOUT 203.0.113.50:25

Connection timed out while opening SMTP socket

SMTP 421 4.7.0 Try again later

SMTP 535 5.7.8 Authentication credentials invalid

HTTP 429 Too Many Requests

The first two occur before SMTP is established and fit a port-25 path problem. A 421 reply means you did reach an SMTP server, but it is temporarily unavailable or declining the session. A 535 means the endpoint was reachable and rejected authentication. HTTP 429 means an API endpoint received your request and applied an application-level rate limit.

Treat these as separate incidents. Conflating them creates long troubleshooting sessions and unnecessary configuration changes.

The fastest fix: use 587, 465, or HTTPS

For most application email, requesting unrestricted port 25 is not the best first move. Modern transactional email services are designed for authenticated message submission, usually through SMTP submission ports or an HTTPS API.

Use port 587 with STARTTLS when available

Port 587 is the standard submission port for authenticated mail clients and applications. The usual flow is:

1. Open a TCP connection to the provider’s SMTP hostname on port 587.
2. Send EHLO.
3. Confirm the server advertises STARTTLS.
4. Send STARTTLS and complete TLS negotiation.
5. Send EHLO again inside the encrypted session.
6. Authenticate with the credentials or token format required by the provider.
7. Submit the message using MAIL FROM, RCPT TO, and DATA.

The connection-encryption option in your library must match this flow. In many frameworks, port 587 uses a setting called STARTTLS, tls, or secure: false plus a separate STARTTLS option. The exact names vary by library, so verify the library documentation instead of copying configuration flags from another runtime.

A common mistake is enabling implicit TLS for a port-587 endpoint. That can produce TLS handshake errors even though the network is working perfectly.

Use port 465 only for implicit TLS endpoints

Port 465 generally starts TLS immediately after the TCP connection. There is no plaintext SMTP greeting before the TLS handshake. In application libraries, this mode is often represented by a setting such as secure: true or use_ssl: true.

Do not assume every provider supports 465, and do not assume that port 465 and 587 accept the same authentication mechanism. Check the endpoint documentation for the service you use.

Prefer a REST API when the application supports it

An email REST API usually sends over HTTPS on port 443. That avoids port-25 restrictions entirely and often gives your application more explicit request and response semantics, idempotency support, structured error bodies, and easier observability.

For example, an API client can distinguish a rejected request from a queued message using an HTTP status code and response payload. SMTP can do this too, but API integrations commonly fit modern application logging, tracing, and retry middleware more naturally.

A provider that offers both a REST API and SMTP relay gives you an operational choice: keep existing SMTP-compatible software working through a submission port, while new application code can use HTTPS. Review your provider’s API and SMTP setup guides for the endpoint-specific hostnames, ports, TLS modes, and credential formats rather than guessing them.

Do not silently fall back to direct-to-MX delivery

If an SMTP relay becomes unreachable, some teams are tempted to bypass it and send directly to recipient MX hosts on port 25. On AWS, that often runs straight into the same restriction. Even if port 25 is approved, operating direct delivery creates substantial additional responsibilities: IP reputation, reverse DNS, feedback-loop handling, bounce processing, abuse prevention, queue management, retry scheduling, TLS behavior, and recipient-specific policies.

For most product email—password resets, receipts, notifications, invitations, and account alerts—an authenticated relay or API is the more reliable design.

Requesting removal of the port 25 restriction

There are valid reasons to request removal of AWS Port 25 throttling. You may operate a legitimate MTA, run a mail gateway, relay mail from a controlled network, or have a specialized integration that cannot use another port. AWS allows customers to request removal of the restriction.

However, approval should be treated as one piece of a complete email-operations plan, not a shortcut around deliverability engineering.

Prepare the request before opening it

AWS will want confidence that your system has a legitimate email use case and will not create spam or abuse risk. Prepare a concise, specific description covering:

• The AWS Region and the public IP addresses, Elastic IP addresses, instances, or workloads involved.
• Whether you will send directly to recipient MX hosts or to a known relay.
• The type of messages you send, such as transactional receipts, security alerts, or customer notifications.
• How recipients opt in, if the workload includes non-transactional mail.
• Expected daily volume, peak hourly volume, and anticipated growth.
• How you process bounces, complaints, unsubscribe requests, and abuse reports.
• How you prevent account compromise and unauthorized SMTP relay use.
• The domain names, reverse-DNS plan, and authentication records you control.

Avoid vague requests such as “our application needs email” or “please unblock SMTP.” A clear operational description is more useful because it demonstrates that you understand the security and reputation implications of direct email infrastructure.

Understand the scope of your design

A port-25 removal request does not automatically make a mail system deliverable. It also does not replace email-provider quotas, recipient-domain filtering, or application-level throughput limits.

You still need to configure the network route, decide whether the MTA uses a stable egress IP, set reverse DNS, publish domain authentication records, protect credentials, and keep a bounded retry queue. If your application sends through a third-party relay on 587 or 465, none of that requires direct outbound port 25 in the first place.

Do not build a production launch around uncertain timing

Do not schedule a critical launch on the assumption that a request will be approved immediately. Build a fallback path before your campaign, migration, or transaction flow depends on it. Usually that means configuring the application for port 587 or an API over 443, then treating direct port 25 as an explicit architectural requirement rather than an emergency workaround.

Check your AWS network path too

Port 25 restrictions are not the only reason an SMTP connection can fail. Your own AWS network controls may independently block mail submission ports.

Security groups and network ACLs

Security groups are stateful virtual firewalls attached to AWS resources. For an application initiating an SMTP connection, you need outbound TCP access to the provider’s destination port—commonly 587 or 465, and only 25 if your design truly needs it.

A simple outbound rule may allow TCP 587 to 0.0.0.0/0, but a more restrictive environment may allow outbound email only to approved destination IP ranges. That is harder to maintain because SMTP providers can use multiple IP addresses or change infrastructure. If you allow by destination address, confirm the provider publishes stable ranges and has a process for notifying customers of changes.

Network ACLs are stateless. If you use restrictive ACLs, remember that an outbound TCP connection also requires the response traffic to return through ephemeral ports. A rule that allows outbound traffic to TCP 587 but blocks inbound ephemeral response ports can look like an SMTP timeout.

NAT gateways, proxies, and container networking

Instances in private subnets generally reach the public internet through a NAT gateway, NAT instance, firewall appliance, or egress proxy. Test from the workload itself, not only from a bastion host in another subnet.

For container workloads, verify the egress path for the task or pod. An EC2 host may reach port 587 while a container is restricted by a Kubernetes NetworkPolicy, a service mesh egress policy, a Docker firewall rule, or a separate route table. Serverless workloads can have their own VPC configuration and egress behavior as well.

IPv4 and IPv6 can behave differently

A hostname may resolve to both A and AAAA records. If your SMTP client prefers IPv6 and the provider publishes an IPv6 address, the client may try IPv6 first. AWS documentation states that outbound port 25 is blocked to public IPv4 and IPv6 destinations by default, so an IPv6 path does not bypass the restriction.

For other ports, IPv4 and IPv6 can still differ because of your route tables, egress-only internet gateway, firewall policy, DNS behavior, or provider endpoint support. Use dig, nslookup, or getent ahosts to inspect the addresses your SMTP hostname returns:

dig +short A smtp.example-provider.com
dig +short AAAA smtp.example-provider.com

Then test the actual address family your application uses where practical.

Set DNS and identity records correctly

Changing from port 25 to port 587 solves connectivity, not inbox placement. Whether you use a managed relay or operate your own MTA, recipients evaluate sender identity, alignment, IP reputation, content, and recipient engagement.

SPF: authorize legitimate senders

SPF is published as a TXT record for the envelope sender domain. A simple example for a self-hosted sender using one static IPv4 address is:

example.com. IN TXT "v=spf1 ip4:198.51.100.42 -all"

198.51.100.42 is a documentation-only example address; replace it with the actual sending address. The -all mechanism states that senders not matched by the preceding mechanisms should fail SPF.

If you send through an email provider, it will normally give you a provider-specific SPF mechanism—often an include: value—or it may use a custom return-path domain. Do not invent or reuse an include: mechanism from another vendor. Copy the exact value supplied for your account and ensure you have only one SPF TXT record for a given domain.

SPF has a DNS-lookup limit, so stacking many services into one record without reviewing the result can lead to permerror. Tools such as MXToolbox can inspect an SPF record, but they do not replace understanding which services are genuinely authorized to send.

DKIM: sign mail with your domain

DKIM uses a public key in DNS and a corresponding private key held by the service that signs messages. A generic TXT-style DKIM record looks like this:

selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=BASE64_PUBLIC_KEY"

The p= value must be the full public key generated for that selector, without placeholders. Many managed email services instead ask you to create one or more CNAME records that point to provider-hosted DKIM records. Both approaches can be valid; publish the exact record type, hostname, and value your sending system specifies.

Use a selector that can be rotated. For example, s2026a._domainkey.example.com lets you introduce a new selector later without immediately removing the old public key. Keep old selectors available until messages signed with them have aged out of recipient systems and queues.

DMARC: monitor before enforcing

DMARC is published at _dmarc beneath the visible From-domain. A conservative monitoring record is:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

This example requests aggregate reports at dmarc-reports@example.com and uses strict alignment for DKIM and SPF. Strict alignment is not automatically appropriate for every architecture, especially if a vendor uses a subdomain for return paths or DKIM signing. Confirm that either the aligned SPF identity or aligned DKIM identity matches the domain in the visible From: header before moving to an enforcing policy.

A sensible rollout is:

1. Start with p=none and review aggregate reports.
2. Identify all legitimate senders, including support tools, CRMs, application relays, and marketing platforms.
3. Fix missing SPF authorization, DKIM signing, and alignment issues.
4. Move gradually to p=quarantine or p=reject only when legitimate sources are covered.

DMARC does not guarantee inbox placement. It does, however, help domain owners control unauthorized use of their From domain and gives valuable visibility into which systems are sending mail that claims to be from them.

Reverse DNS, forward DNS, and HELO identity

If you operate your own MTA from EC2, use a stable Elastic IP rather than an ephemeral public IP. Configure a forward DNS record such as:

mail.example.com. IN A 198.51.100.42

Then configure the reverse DNS (PTR) for that Elastic IP to point back to the same hostname:

198.51.100.42 -> mail.example.com

AWS requires the corresponding forward A record before creating reverse DNS for an Elastic IP. Your MTA’s EHLO or HELO name should normally be a real, forward-resolving hostname such as mail.example.com, rather than localhost, an internal EC2 hostname, or an unrelated domain.

This is sometimes called forward-confirmed reverse DNS: the IP maps to a hostname, and that hostname maps back to the same IP. It is not the only deliverability signal, but a missing or mismatched PTR is a common weakness in self-hosted email setups.

Configure the application for resilient sending

A correct port and DNS setup can still fail under routine network conditions. Email is an asynchronous system, so your application should queue, classify, retry, and observe sends rather than treating every request as a synchronous guarantee of inbox delivery.

Use bounded retries with exponential backoff

Retry transient network failures and SMTP 4xx responses, but do it deliberately. A reasonable strategy is exponential backoff with jitter, a finite maximum attempt count, and a dead-letter or manual-review path.

For example:

• Attempt 1: immediately.
• Attempt 2: after roughly 1 minute plus jitter.
• Attempt 3: after roughly 5 minutes plus jitter.
• Later attempts: progressively longer intervals within your delivery window.
• Final failure: stop retrying, record the reason, and alert or review as appropriate.

Never retry permanent failures indefinitely. SMTP 5xx replies generally indicate a permanent failure for the current message or recipient, although the exact meaning depends on the enhanced status code and server text. A malformed address, an unauthorized sender, or invalid credentials will not become valid after 100 retries.

Avoid duplicate sends

A network timeout does not always mean the receiving SMTP server failed to accept the message. Your client might time out after sending DATA while the server successfully queued the message. Blindly retrying can create duplicate password resets, receipts, or customer notifications.

Use a durable message ID in your application, record state transitions, and use provider-supported idempotency mechanisms where available. At minimum, distinguish “not attempted,” “connection failed before submission,” “accepted by relay,” and “final delivery event unknown.”

Keep credentials out of source code

Store SMTP credentials and API keys in a secrets manager or encrypted deployment configuration. Rotate them if they are exposed. Scope access narrowly: an application that sends transactional mail should not have broad infrastructure permissions merely because it needs to connect to an SMTP relay.

Also validate the TLS certificate hostname. Do not disable certificate verification in production just to make a test pass. A working encrypted connection to the wrong endpoint is not a successful email configuration.

Troubleshoot common misleading symptoms

The symptom tells you where to look. Use this table as a first-pass triage guide.

A successful SMTP handoff is not inbox delivery

SMTP 250 after DATA means the receiving relay accepted responsibility for the message. It does not prove the recipient saw it in their inbox. The relay can later defer, bounce, suppress, route to spam, or receive a downstream rejection.

Capture provider webhooks, bounce notifications, complaint events, and message identifiers where available. Your application should be able to answer: Was the message accepted by the relay? Was it delivered? Did it bounce? Was it deferred? Did the recipient complain? Without event tracking, teams often mistake a deliverability issue for an AWS networking issue.

Use external tests carefully

Mail testing services such as mail-tester.com can help inspect authentication, content, and common configuration signals. MXToolbox can help query SPF, DKIM, DMARC, MX, and blacklist-related information. These tools are useful for diagnosis, but a single score is not an inbox-placement guarantee.

Test with real mailbox providers too. Send controlled messages to accounts at major recipient domains, inspect the full headers, confirm SPF/DKIM/DMARC results, and compare the visible From domain, Return-Path domain, DKIM d= domain, and sending IP. Do this only with addresses you control and test traffic that reflects your real message format.

Choose the right architecture for the workload

The best solution depends on what you are actually building.

Transactional application email

For password resets, verification links, invoices, receipts, alerts, and account notifications, use an authenticated SMTP relay over 587 or 465, or use a REST API over 443. Keep the sending path separate from web-request handling by placing mail jobs in a queue. This design avoids a direct dependency on port 25 and reduces operational burden.

Self-hosted mail transfer infrastructure

If you operate a true MTA for a legitimate reason, request removal of the port-25 restriction and treat the server as production email infrastructure. Use stable IP addresses, reverse DNS, authentication records, authentication and abuse controls, alerting, logs, queue monitoring, reputation monitoring, and tested incident procedures.

Do not expose an unauthenticated open relay. A secure relay requires recipient restrictions, sender controls, authentication where appropriate, rate limits, abuse monitoring, and regular patching. An open relay can quickly damage your IP reputation and create severe abuse and cost exposure.

Hybrid setups

Some organizations retain an internal MTA for local routing, application compatibility, or policy enforcement while sending public mail through a managed relay. In that setup, the internal hop can use private addressing and port 25, while the public submission hop uses port 587, 465, or HTTPS. This can preserve legacy workflows without making every application responsible for direct internet email delivery.

The key is to document the boundary: which host owns the queue, which domain signs DKIM, which system handles bounces, which egress IP appears to recipients, and which team responds to abuse or delivery incidents.

A practical resolution checklist

Work through this order to avoid changing unrelated variables:

1. Reproduce the failure from the production workload’s network.
2. Test the same SMTP hostname on ports 25, 587, and 465 where supported.
3. If port 25 alone fails, switch the application to 587 with STARTTLS, 465 with implicit TLS, or an HTTPS API.
4. Verify security-group egress, network ACL return traffic, NAT/proxy rules, routes, and container or serverless egress policies.
5. Test TLS with openssl s_client; do not rely only on an application error message.
6. Verify credentials and TLS mode only after the network connection succeeds.
7. Publish and validate SPF, DKIM, and DMARC for the visible From domain and return-path architecture.
8. If operating your own MTA, assign a stable Elastic IP, configure matching forward and reverse DNS, and use a valid HELO/EHLO hostname.
9. Add durable queues, bounded retries, event handling, duplicate prevention, and alerting.
10. Request port-25 restriction removal only when direct SMTP relay is a deliberate requirement.

Conclusion

AWS Port 25 throttling is usually straightforward once you diagnose it at the correct layer. A port-25 timeout from EC2 is fundamentally different from an SMTP rejection, bad credentials, a DNS failure, or an API rate limit.

For most transactional-email applications, the quickest and most durable solution is authenticated SMTP submission on port 587 or 465, or a REST API over HTTPS on port 443. If your architecture genuinely requires direct server-to-server SMTP, request removal of the restriction—but pair that request with stable IPs, reverse DNS, domain authentication, secure relay controls, queue management, and deliverability monitoring.

FAQ

Is AWS blocking inbound port 25 or outbound port 25?

The AWS restriction discussed here concerns outbound port 25 traffic from EC2 to public destinations. Inbound SMTP is a separate firewall, routing, and mail-server configuration question.

Can I use port 587 instead of port 25 on AWS?

Yes, if your SMTP provider supports it. Port 587 commonly uses STARTTLS and authenticated message submission, making it the preferred option for many application-email integrations.

Does switching to port 587 improve deliverability?

It fixes a connectivity problem; it does not itself improve inbox placement. Deliverability still depends on authentication, alignment, sending reputation, recipient engagement, content, bounce handling, and complaint rates.

Why does port 25 work from my laptop but not from EC2?

Your laptop and EC2 instance use different networks with different outbound policies. A successful local test does not prove that the EC2 egress path permits outbound SMTP on port 25.

Should I request port 25 removal for transactional email?

Usually no. Use a managed SMTP relay on 587 or 465, or an HTTPS email API, unless you have a specific operational requirement to run direct SMTP delivery or a mail relay from AWS.