Email encryption in transit comes in two flavours, and the difference is about when the TLS handshake happens. With STARTTLS the connection starts in plaintext and is upgraded to TLS partway through. With implicit TLS the connection is encrypted from the very first byte, before any mail commands are exchanged. Three ports carry SMTP — 25, 465 and 587 — and knowing which uses which model, and what each is actually for, clears up most mail-security confusion.
How STARTTLS works
On a STARTTLS connection the client opens a plaintext TCP session and the server greets it. The server advertises its capabilities in response to the EHLO command, and if it supports encryption one of those capabilities is STARTTLS. The client then issues the STARTTLS command, the two sides perform a TLS handshake over the existing connection, and everything after that — a second EHLO, the sender and recipient addresses, the message itself — travels encrypted. The port stays the same; the connection is upgraded in place.
How implicit TLS works
Implicit TLS skips the plaintext preamble entirely. The client connects and immediately begins a TLS handshake; no mail command is ever sent in the clear, because the SMTP conversation only starts once the tunnel is already established. This is the same model HTTPS uses on port 443. Because there is nothing to strip and no plaintext capability negotiation to tamper with, implicit TLS is not vulnerable to the downgrade attack that plagues opportunistic STARTTLS.
Port 25 — server-to-server relay
Port 25 is the original SMTP port and it is where mail servers hand messages to each other. When a message leaves your provider bound for another organisation, the sending server looks up the recipient domain's MX records and connects to the receiving server on port 25. Here STARTTLS is used opportunistically: TLS is used if the receiving server offers it, but if STARTTLS is missing or the handshake fails, the sender typically falls back to plaintext rather than refuse to deliver. That fallback keeps the global mail system interoperable, but it is also the weak point that MTA-STS and DANE exist to close. Port 25 is for relay between servers; it is emphatically not the port your mail client should use to send.
Most residential ISPs and many cloud providers block outbound connections on port 25 entirely, precisely because it is unauthenticated relay and was historically the favourite channel for malware and spam sending directly from infected machines. That block is a big part of why the submission ports exist as a separate, authenticated path: a legitimate user's device should never be speaking raw port 25 to the world. If you find yourself needing outbound 25 from an ordinary host to send mail, that is usually a sign the configuration is wrong — you want submission on 465 or 587 to a real outbound server, which then relays on 25 from an address the internet trusts.
Port 587 — client submission with STARTTLS
Port 587 is the modern submission port, defined so that a mail user agent — your phone, Outlook, a script — can hand a new message to its own outgoing server for onward delivery. Submission requires authentication: you log in, then send. Port 587 uses STARTTLS, so the client connects in plaintext, issues STARTTLS, and only then authenticates and submits over the encrypted channel. The crucial difference from port 25 is policy: a properly configured submission server should require STARTTLS and refuse to accept credentials or mail over an unencrypted connection, so there is no silent downgrade to worry about the way there is with opportunistic server-to-server relay.
Port 465 — client submission with implicit TLS
Port 465 was once deprecated, then formally reinstated as the port for message submission over implicit TLS. It does exactly what 587 does — authenticated submission from a client — but with TLS from the first byte instead of a STARTTLS upgrade. For a mail client, 465 and 587 are both correct, secure choices today; the practical difference is only the handshake model. Many providers offer both and let users pick. Because 465 has no plaintext phase, it removes an entire class of misconfiguration where a client is willing to fall back to sending in the clear.
Submission versus relay, and which to choose
The mental model is simple. Submission is a person's device handing a brand-new message to their own provider, and it always authenticates — that is ports 587 and 465. Relay is one server passing an already-accepted message to another organisation's server, unauthenticated, driven by MX records — that is port 25. Mail clients should be configured for 465 or 587, never 25. Server-to-server delivery has no choice but to use 25, which is why the ecosystem layers policy on top of it.
That policy is the important sequel to this topic. Opportunistic STARTTLS on port 25 can be silently stripped by an on-path attacker, downgrading an encrypted delivery to plaintext without either side noticing. MTA-STS Studio covers the SMTP MTA Strict Transport Security policy that lets a receiving domain tell senders to require TLS and refuse to fall back. And while you are hardening a mail domain, verify your message-signing setup with DKIM Studio, because transport encryption protects the channel, not the authenticity of the message inside it. This site's tester connects to your MX hosts and confirms that STARTTLS is offered, the certificate is valid and in date, and the negotiated TLS version is 1.2 or 1.3.