SMTP Ports 25, 465, and 587: What Is the Difference?

SMTP has three ports in common use: 25, 465, and 587. They all speak the same protocol. The differences are about who uses them and when encryption starts.

The short version

Port	Used for	Encryption	Login required
25	Server-to-server delivery	Plaintext, STARTTLS optional	No
465	Client and app submission	TLS from the first byte (implicit TLS)	Yes
587	Client and app submission	Plaintext, STARTTLS required	Yes

Port 25: between mail servers

When Gmail delivers a message to you@yourcompany.com, it looks up your domain's MX record and connects to your mail server on port 25. This is the backbone of how mail moves across the internet, and any server that accepts incoming mail must keep port 25 open.

Port 25 is not meant for sending from your laptop or your app. Home broadband and most cloud providers (AWS, Alibaba Cloud, etc.) block outbound port 25 by default, because compromised machines love to use it for spam. That is the usual cause of "works on my machine but times out on the server."

Port 465: encrypted from the first byte

Port 465 uses implicit TLS: after the TCP connection is established, the first thing that happens is a TLS handshake, before any SMTP commands are exchanged. There is no plaintext phase, so there is no window for a man-in-the-middle to strip the encryption.

It has a complicated history. Port 465 was assigned to SMTPS in the 1990s, then revoked, and the industry shifted to port 587 with STARTTLS. RFC 8314 in 2018 officially rehabilitated port 465 for mail submission and recommended preferring implicit TLS.

Port 587: upgrade in progress

Port 587 connects in plaintext, then the client sends STARTTLS, upgrades to TLS, authenticates, and sends the message. As long as the client refuses to continue if the server doesn't support STARTTLS, the security is equivalent to port 465. The risk is that older clients sometimes silently fall back to plaintext when they encounter a server that doesn't advertise STARTTLS.

Which one to use

• Configuring a mail client: use 465, SSL/TLS.
• Sending from application code: prefer the HTTP API; if you need SMTP, use 465.
• Running your own inbound server: port 25 must be open to receive mail from the internet.

Rovela's public-facing servers publish ports 25 (inbound delivery) and 465 (submission). Port 587 is not published — two submission ports that offer identical capability is one more thing to defend, and the implicit TLS port is the better one to keep.

Client settings for Rovela mailboxes:

Incoming  IMAP  mx.rovela.dev  993  SSL/TLS
Outgoing  SMTP  mx.rovela.dev  465  SSL/TLS
Username  full email address
Password  a credential created in Mailboxes → Credentials

Common errors

Connection timeout: the outbound port is probably blocked by your cloud provider. Test with nc -vz mx.rovela.dev 465 first. If port 465 is blocked, switch to the HTTP API on port 443.

wrong version number: the TLS mode is set incorrectly. Port 465 needs "SSL/TLS"; port 587 needs "STARTTLS". They are not interchangeable. In nodemailer, port 465 maps to secure: true, port 587 to secure: false.

535 Authentication failed: the username must be the full email address, and the password is a per-device credential, not the Rovela dashboard login password.

Why the HTTP API beats SMTP for application code

The API runs on port 443, which no cloud provider blocks. One request returns the message ID, and later you can receive delivery and bounce events via webhook. SMTP works, but once the message is sent there is no feedback.

curl -X POST https://api.rovela.dev/emails \
  -H "Authorization: Bearer re_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{"from":"Acme <hello@yourdomain.com>","to":"you@example.com","subject":"Hi","html":"<p>Hi</p>"}'

Further reading: Setting up your mail client, Self-hosted mail: Postfix and Dovecot, Sending email via the API.