SMTP port 25 vs 465 vs 587: which one to use, and why the answer is almost always 587

Every mailer’s configuration screen has a port field, and three numbers are the only ones that ever go in it. They are not interchangeable. They were defined at different times for different jobs, and choosing the wrong one produces failures that look like something else: a connection that hangs, a message that leaves your server in plaintext, or a workflow that works from your laptop and fails in production.

The three jobs

Port 25 is for transfer. When one mail system hands a message to another, the receiving system’s server is listening on 25. This is the port a receiver’s MX host accepts on, and it is the port a relay uses on its way out. There is no authentication in this exchange, because the receiver is accepting mail for its own users from the whole internet.

Port 587 is for submission. When a user or an application hands a message to its own mail system for delivery, that is submission, and RFC 6409 gave it its own port precisely so it could have different rules from transfer: authentication required, encryption expected, and the ability for the relay to fix up headers on the way in. This is the port your application should use.

Port 465 is submission over implicit TLS. Same job as 587, but the connection is encrypted before any SMTP command is sent, rather than upgraded partway. It was briefly registered for this in the 1990s, withdrawn, used anyway by everyone for twenty years, and then formally reinstated by RFC 8314 in 2018.

The distinction between transfer and submission is the whole reason there are two ports. An application is not a mail system. It has no reputation, no reverse DNS, no retry queue, and no bounce handling. It should hand its mail to something that has all of those, and the port for that is 587.

What goes wrong on 25

Applications end up on port 25 because a tutorial from 2009 said so, or because a mail server on the same box is listening there. Three things follow.

It is blocked. Nearly every cloud and hosting provider blocks outbound port 25 by default, because a compromised VM sending spam directly is the most common abuse they see. Some allow it on request. Most do not. Code that opens a connection to port 25 works in local development and times out in production, and the error is “connection timed out”, which points at nothing.

There is no authentication. A relay listening on 25 either accepts from anyone, which makes it an open relay that will be blocklisted within hours, or restricts by IP, which breaks the moment infrastructure moves.

The message leaves as the box. Delivering direct from an application server on port 25 means the receiving side sees your VM’s IP, with whatever reverse DNS the provider gave it, on a range that receivers already treat as suspect. The message may arrive. It will be judged on the worst possible evidence.

587 or 465: pick one, either is fine

Both are correct. The difference is how the encryption starts.

On 587, the client connects in plaintext, the server advertises STARTTLS, the client issues it, and the connection upgrades before credentials are sent. On 465, the TLS handshake happens first, and SMTP begins inside it.

The argument for 465 is that there is no plaintext phase to attack. An adversary on the path can strip the STARTTLS advertisement from a 587 conversation, and a badly configured client will carry on unencrypted. The argument for 587 is that it is the port every mailer, framework and relay documents first, and a correctly configured client refuses to continue without TLS anyway.

The configuration that matters is not the port. It is this:

Port:        587
Encryption:  STARTTLS  (required, not opportunistic)

or

Port:        465
Encryption:  SSL/TLS   (implicit)

The word to look for in your mailer is required. Opportunistic STARTTLS means “encrypt if the server offers it, otherwise carry on”, and that is the setting the downgrade attack exists for. Require TLS, and a stripped advertisement becomes a connection error rather than a plaintext send.

The mismatch that hangs

The single most common SMTP misconfiguration is pairing the wrong encryption mode with the port: implicit TLS on 587, or STARTTLS on 465. The connection opens, each side waits for the other to speak in a protocol the other is not speaking, and the mailer sits there until a timeout, reporting nothing useful.

If your mailer connects and hangs, check this pairing before anything else. Then check credentials.

A working configuration

Five values, from whatever relay you use:

Host:      smtp.your-relay.example
Port:      587
Security:  STARTTLS (required)
Username:  the relay's generated username
Password:  the relay's generated password

Test from the machine that will actually send, not from your laptop. Outbound port blocking is per network, and the whole point of the test is to find out whether this network allows this port. The n8n post walks through the same five fields inside a workflow tool, where the failure mode is the same and quieter.

Where Pharos fits

The Pharos relay listens on smtp.pharosinfra.net:587 with STARTTLS, and the credentials are created per sending domain in the dashboard, so an application or a framework mailer needs the five values above and nothing else. If a network blocks 587, the same messages go through the HTTP API on 443 with identical authentication, events and logging on the other side.