The SMTP protocol carries your emails from a client or application to the recipient’s server, and every connection goes through a specific port. For submission from an email client or a sending script, use port 587 with STARTTLS by default. Port 465 runs on implicit TLS and remains an equally valid alternative. Port 25 handles server-to-server transfer and is blocked by most ISPs and cloud hosting providers. Port 2525 comes in handy when 587 is filtered by a third-party network. This guide shows how to verify the right port in 2 minutes with a single command.
The 4 SMTP ports and their real-world use
Each port corresponds to a specific role in the sending chain, set by protocol standards. Port 25 is the historical port of the protocol, reserved for server-to-server transfer (MTA to MTA): a mail server relaying a message to another mail server uses it, never an email client or application submitting a message. Port 587 was standardized in 2007 (RFC 4409, since replaced by RFC 6409) specifically for authenticated submission, with encryption activated after connection via the STARTTLS command. Port 465 has a more turbulent history. Assigned in the 1990s for SMTP over SSL, it was considered obsolete for nearly 20 years in favor of 587, then officially reinstated. RFC 8314, published by the IETF in January 2018, restores port 465 as the official port for submission over implicit TLS and presents it as the recommended long-term technical direction, ahead of 587.
RFC 8314 describes the use of cleartext for message submission and access as outdated and recommends encryption from the moment the connection opens rather than activating it mid-exchange (IETF, January 2018).
Port 2525 is not standardized by the IETF at all. It’s a fallback for when a network filters 587 and 25, and most commercial email routers support it, though the port isn’t guaranteed to work with every provider.
STARTTLS vs. implicit TLS: the practical difference
STARTTLS opens the connection in cleartext, then the client sends the STARTTLS command to switch to an encrypted channel before exchanging credentials and message content. Implicit TLS encrypts from the very first TCP handshake: no data travels in cleartext, not even during negotiation. RFC 8314 justifies this choice by the interception risk during the brief cleartext window that precedes the STARTTLS command, a window an active network attacker can exploit to force an unencrypted connection. A misconfigured client can send an SMTP password unprotected if the server doesn’t reject attempts without STARTTLS. That’s the entire distinction between the two mechanisms from a connection security standpoint.
Why port 25 is blocked outbound
The block is deliberate: it’s part of a policy against outbound spam. Consumer ISPs filter outbound connections on port 25 from their routers to stop compromised devices on their network from relaying spam directly to the internet. The reasoning is the same on the cloud side: according to AWS’s official documentation, outbound traffic on port 25 is blocked by default for all EC2 instances and Lambda functions, unless an explicit removal request is approved through a support ticket. Major hosting providers apply comparable restrictions on parts of their shared hosting lineup. The failure is systematic. An application hosted on a VPS or a consumer router that tries to send directly on port 25 fails regardless of how well its DNS configuration or content is set up. The solution isn’t to bypass this block but to submit the message on 587 or 465, ports that these same networks leave open.
Which port to use depending on your provider
The table below lists only the ports accepted for submission. For your provider’s exact server address, check our guide on finding your email’s SMTP server.
| Provider | Accepted ports | Note |
|---|---|---|
| Gmail | 587, 465 | 587 recommended by Google, authentication required on both |
| Outlook / Microsoft 365 | 587 | 465 not supported by the Microsoft 365 SMTP relay |
| Yahoo | 587, 465 | Two-factor authentication requires an app password |
| AT&T | 465 | Only officially recommended port for the consumer webmail relay; 587 exists only on business-tier accounts, separate from the consumer account |
| Xfinity/Comcast | 465 | 587 not consistently offered depending on the plan |
| Verizon | 465, 587 | 465 recommended first, 587 as a fallback if the network blocks direct SSL |
| T-Mobile | 587, 465 | 587 STARTTLS works notably on iOS, 465 SSL as an alternative |
| GoDaddy | 465, 587 | 465 over direct SSL, 587 over STARTTLS depending on the mail plan |
| IONOS | 587, 465 | 587 STARTTLS recommended first by the provider |
Testing whether an SMTP port is open
Two commands are enough to confirm a port responds before blindly changing a configuration. With OpenSSL installed, run openssl s_client -connect smtp.example.com:587 -starttls smtp from a terminal. A response starting with 220 followed by the server name confirms the port is listening and accepts the STARTTLS negotiation. Without OpenSSL, telnet works for a basic test: telnet smtp.example.com 587. Output showing 220 mail.example.com ESMTP ready means the TCP connection is established. If the prompt stays blank for several seconds then closes, the port is being filtered somewhere between your machine and the server, often by a local firewall or a consumer router. This test takes under 2 minutes and saves you from guessing blindly which part of the chain is actually blocking delivery.
Understanding SMTP connection errors
3 messages come up most often when a send fails. Each points to a different cause.
- Connection timed out: the TCP connection never completes. The port is blocked by a firewall, a home router, or a cloud security rule before it even reaches the mail server. Test another port (587 if 25 fails, 2525 if 587 also fails) rather than changing the credentials.
- Connection refused: the target machine responds but nothing is listening on that specific port. The SMTP server exists, but the service isn’t configured on that port number or runs on a different network interface. Check which port is actually open with the openssl command shown above before changing the client configuration.
- Must issue a STARTTLS command first: the server requires encryption and the client is trying to send credentials in cleartext. The setting to fix is client-side security, STARTTLS on 587 or SSL/TLS on 465. The port number is correct.
An error message mentioning a timeout or a refusal almost always concerns the port or the firewall, never the email content. A message mentioning authentication or encryption concerns the connection’s security setting, independent of the port number. This distinction saves you from reconfiguring SPF, DKIM, DMARC, or the message content when the problem actually sits one layer down, at the transport level.
If your own server stays filtered despite a correctly open port on the client side, routing through an SMTP relay bypasses the block without touching your infrastructure.
The right port opens the connection. It guarantees nothing about the rest of the journey: messages that send normally but end up in the spam folder point to the sender domain’s authentication and to how clean the sent contact list is.
