STARTTLS and Implicit TLS are two ways to encrypt an SMTP connection. STARTTLS opens a plaintext connection (usually on port 587), then issues a STARTTLS command to upgrade it to TLS. Implicit TLS (usually on port 465) wraps the entire connection in TLS from the very first byte, with no plaintext phase at all. In the STARTTLS vs TLS debate, the practical difference is that 465 is encrypted before any data moves, while 587 has a brief unencrypted handshake that a man-in-the-middle could theoretically strip.
I've configured both across dozens of mail servers. For most senders the choice barely matters as long as you enforce encryption. Here is what actually differs.
STARTTLS vs TLS: the core difference
STARTTLS is sometimes called "explicit TLS" or "opportunistic TLS." The connection begins in cleartext on a normal SMTP port. The client asks the server what it supports (EHLO), the server advertises 250-STARTTLS, and the client sends STARTTLS to switch the existing connection to encrypted. Same port, two phases.
Implicit TLS does no negotiation in cleartext. The TLS handshake happens immediately when the socket opens, exactly like HTTPS. There is no plaintext to intercept and no upgrade command to strip.
The historical mess: port 465 was deprecated in 1998, then formally re-blessed for Implicit TLS submission in RFC 8314 (2018). So "465 is dead" advice you'll still find online is wrong. Both ports are current and correct in 2026.
Ports, codes, and terms compared
| Term | Port | When encrypted | RFC | Use case |
|---|---|---|---|---|
| STARTTLS (submission) | 587 | After STARTTLS command | RFC 6409 / 3207 | Authenticated client submission |
| Implicit TLS (submission) | 465 | First byte | RFC 8314 | Authenticated client submission |
| Opportunistic STARTTLS | 25 | After command, may fall back | RFC 3207 | Server-to-server relay |
| Plaintext (legacy) | 25 / 587 | Never | - | Avoid for sending |
Two terms people confuse: "submission" means an authenticated client handing mail to your server to send. "Relay" means one mail server passing mail to another. Ports 587 and 465 are for submission. Port 25 is for relay between servers.
Which one should you use?
For sending your own bulk or transactional mail, both 587 and 465 are correct. My default rule:
- Use 465 (Implicit TLS) when your sending library supports it cleanly. It removes the downgrade-attack surface entirely because there's no plaintext window.
- Use 587 (STARTTLS) when you need broad compatibility. Older libraries and some appliances only speak STARTTLS. This is fine, but you must configure the client to require TLS, not merely offer it.
The danger with 587 isn't STARTTLS itself, it's clients set to "opportunistic" mode. In that mode, if an attacker strips the 250-STARTTLS line from the server's reply, the client shrugs and sends in cleartext. Set your SMTP client to tls = required (or your library's equivalent) and the connection aborts instead of leaking. Done right, 587 and 465 are equally safe for submission.
Whatever you pick, never send authenticated mail over port 25. ISPs block it, and STARTTLS there is opportunistic by design.
Does this affect deliverability?
Directly, no. Mailbox providers don't rank inbox placement on whether you used 587 or 465 to submit. Encryption protects the hop between your app and your sending server, not what Gmail thinks of you.
What affects deliverability is the stuff downstream: IP reputation, authentication, warm-up. If you're weighing infrastructure choices, those matter far more than the TLS port. See dedicated IP vs shared IP, how long IP warm-up takes, and how to reduce your bounce rate.
One indirect link: server-to-server relay on port 25 does use opportunistic STARTTLS, and Gmail and others flag mail received over unencrypted connections with a little red padlock. A well-run sending server presents a valid TLS cert on port 25 so receiving servers encrypt that hop too. That's a server-config detail, not something you control from your app's submission port.
Common setup mistakes
- Mixing port and mode. Setting port 465 but telling the library to use STARTTLS produces a hang or handshake error. 465 = implicit, 587 = STARTTLS. Match them.
- Opportunistic fallback left on. The single most common real-world weakness. Require TLS.
- Trusting self-signed certs blindly. If your client disables cert verification "to make it work," you've thrown away most of the protection. Use a valid cert.
- Using port 25 for submission because a tutorial said so. It'll get blocked by your host the moment you scale.
If you're choosing a provider rather than running your own, this is one less thing to think about. Compare options in Amazon SES vs dedicated SMTP, SendGrid alternatives, and SMTP relay pricing.
How BulkEmailSetup helps
BulkEmailSetup ships dedicated SMTP servers with both port 587 (STARTTLS) and port 465 (Implicit TLS) enabled, valid certs, TLS required by default, and a properly configured port 25 for encrypted server-to-server relay. You get your own warmed IP and managed deliverability at a flat monthly fee, so the encryption details are handled and you just point your app at the host. At sustained volume that flat fee beats per-email pricing; at low volume cheaper pay-as-you-go options win. See pricing for current plans, and is managed SMTP worth it for the honest trade-offs.
Frequently asked questions
What is the difference between STARTTLS and implicit TLS?
STARTTLS starts a plaintext SMTP connection and then upgrades it to encryption with a command, usually on port 587. Implicit TLS encrypts the entire connection from the first byte, usually on port 465, with no plaintext phase. Implicit TLS is harder to downgrade-attack; STARTTLS is more widely supported.
Should I use port 587 or 465 for sending email?
Both are fine for authenticated submission. Use 465 (Implicit TLS) if you want encryption guaranteed from the first byte and your client supports it. Use 587 (STARTTLS) for maximum compatibility, but require TLS so the connection refuses to fall back to plaintext. Avoid port 25 for submission.
Is STARTTLS less secure than implicit TLS?
STARTTLS is vulnerable to a stripping attack where a man-in-the-middle removes the upgrade offer and forces plaintext. This only matters if the client allows plaintext fallback. A correctly configured STARTTLS client that requires TLS is effectively as safe as implicit TLS for submission.
Why is port 25 not used with STARTTLS for sending?
Port 25 is for server-to-server relay, not authenticated client submission. Most ISPs block outbound port 25 to fight spam, and STARTTLS on port 25 is opportunistic, meaning it silently falls back to plaintext. Use 587 or 465 for sending your own mail.
