SMTP Ports 25, 465 and 587: Which One Should You Use?

Every time you configure a mail client, a website contact form, a scanner or an application to send email, you are asked for an SMTP port. Pick the wrong one and you get timeouts, certificate errors or "relay access denied". The confusion is understandable: there are three standard SMTP ports plus one unofficial one, they have overlapping histories, and advice online is often out of date. Here is what each port is actually for today.

Two different jobs: relay and submission

SMTP (Simple Mail Transfer Protocol) is used for two distinct tasks, and the ports split along the same line:

• Relay (server to server): your provider's mail server delivers a message to the recipient's mail server. This is defined in RFC 5321 and uses port 25.
• Submission (client to server): your mail app, website or device hands a message to your own provider's server, logging in with a username and password, so the provider can send it on. This uses port 587 or 465.

Most configuration questions are about submission. If you are setting up an app, a mail client or a device, you almost certainly want 587 or 465, not 25.

The ports at a glance

Port 25: for mail servers, not for apps

Port 25 is how the internet's mail servers talk to each other, and it is still essential for that. Your MX records point to servers that listen on port 25 to receive mail. Encryption is negotiated with STARTTLS when both sides support it.

For sending from an application or device, port 25 is a poor choice:

• It is widely blocked outbound. Many ISPs block it on residential and some business connections, and many cloud providers block or restrict outbound port 25 on virtual machines by default, because compromised machines use it to send spam directly.
• Mail sent directly from an arbitrary server without proper reverse DNS, SPF and reputation is likely to be filtered or rejected.

If your web server's mail mysteriously never arrives, a blocked port 25 is a frequent cause. Switch to authenticated submission through an email provider on 587 or 465 instead.

Port 587: the standard submission port

Port 587 is defined for message submission in RFC 6409. The client connects in plain text, the server advertises STARTTLS, the client upgrades the connection to TLS, and only then does it log in and send. A correctly configured client refuses to continue if the upgrade fails. You can watch the exchange with OpenSSL:

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

Port 587 is supported by practically every email provider and client, and it is the right default when in doubt.

Port 465: submission over implicit TLS

Port 465 has an odd history. It was briefly registered for SMTP over SSL in the 1990s, then reassigned, while many providers carried on using it anyway. RFC 8314, published in 2018, formally assigned port 465 for message submission over implicit TLS and recommends implicit TLS over STARTTLS for submission. With implicit TLS, encryption begins immediately on connection, with no plain-text phase that could be tampered with:

openssl s_client -connect smtp.example.com:465 -crlf

So 465 is not deprecated, despite what older articles say. Both 465 and 587 are valid; use whichever your provider documents and your software supports.

Port 2525: a fallback

Port 2525 is not an official standard. Some transactional email services listen on it as an alternative for customers whose networks block 587 and 465. Use it only if your provider documents it and the standard ports are blocked.

Which port should you use?

• Mail apps (Outlook, Thunderbird, phone mail apps): 587 with STARTTLS, or 465 with SSL/TLS, as your provider specifies.
• Website contact forms and web applications: 587 or 465 to a transactional email service or your mailbox provider, with authentication. Use an app password or API credentials, not a staff member's main password.
• Printers and scanners (scan to email): 587 if the device supports STARTTLS properly; otherwise check whether your provider offers a dedicated relay option for devices.
• Your own mail server receiving from the internet: 25 inbound, as the MX target.
• Your own mail server sending to the internet: 25 outbound, from a server with correct reverse DNS and reputation, or relay through a provider on 587.

Troubleshooting connection problems

1. Check the port is reachable. From the machine that sends, try Test-NetConnection smtp.example.com -Port 587 in PowerShell or nc -vz smtp.example.com 587 on Linux. To test whether a port on your own server is open from the internet, use our port checker.
2. Match the encryption to the port. "SSL/TLS" goes with 465; "STARTTLS" goes with 587. Mixing them up causes hangs or protocol errors.
3. Check authentication. Many providers now block basic username-and-password sign-in for some accounts and require OAuth or app passwords.
4. Check the certificate. The host name you connect to must match the server's certificate; connecting by IP address will produce errors.
5. Confirm your sending domain's DNS so that delivered mail passes SPF, DKIM and DMARC, using the SPF, DKIM and DMARC checker.

Key takeaways

• Port 25 is for server-to-server delivery and is often blocked outbound; do not use it from apps.
• Ports 587 (STARTTLS) and 465 (implicit TLS) are both current standards for authenticated submission.
• Match the encryption setting to the port, and always authenticate.
• Port 2525 is an unofficial fallback offered by some providers.