STARTTLS upgrades an existing plain-text connection to TLS after the handshake begins, while implicit TLS (often called SMTPS or IMAPS) requires the entire session to start encrypted on a dedicated port. For modern SMTP submission use STARTTLS on port 587; for legacy or strict clients, implicit TLS on port 465 remains valid when the server supports it.
Why the distinction matters for deliverability and security
Email still moves over the public internet. Without encryption, credentials and message content travel in the clear. The two common ways to add TLS to SMTP (and IMAP) create different operational and security trade-offs that affect client configuration, firewall rules, and compliance.
Misconfiguring the method is a frequent cause of connection failures, especially when developers follow outdated documentation that still lists port 465 as the only “secure” option or when corporate firewalls block one port but not the other.
How STARTTLS works
With STARTTLS the client connects to a clear-text port (usually 587 for submission or 25 for relay). After the initial SMTP greeting the client issues the STARTTLS command. The server responds, a TLS handshake occurs, and the rest of the session—including AUTH and message transfer—runs inside the encrypted tunnel.
- Port 587 is the standard submission port recommended by RFC 6409.
- Port 25 can also offer STARTTLS for server-to-server traffic.
- The same pattern applies to IMAP on port 143.
Because the connection starts unencrypted, a network observer can see the initial banner and the STARTTLS command. Once the handshake completes, everything is protected. Properly configured servers refuse AUTH before the upgrade.
How implicit TLS works
Implicit TLS (historically called SSL) expects the TLS handshake to begin the moment the TCP connection is established. There is no clear-text phase and no STARTTLS command. The client must know in advance that the port requires encryption.
- SMTP uses port 465 (SMTPS).
- IMAP uses port 993 (IMAPS).
- POP3 uses port 995.
This model is simpler for some clients and firewalls because the entire conversation is encrypted from the first byte. The downside is that the port must be dedicated to TLS; mixing clear-text and encrypted traffic on the same port is impossible.
Which one should you use?
Current best practice for client-to-server submission is STARTTLS on port 587. It is the port designated by the IETF for message submission and is widely supported by providers, including ArawaMail. Implicit TLS on 465 is still offered by many servers for compatibility with older clients and with environments that prefer an always-encrypted port.
| Aspect | STARTTLS (port 587) | Implicit TLS (port 465) |
|---|---|---|
| Encryption start | After STARTTLS command | Immediately on connect |
| Standard status | Preferred for submission (RFC 6409) | Still widely supported |
| Firewall friendliness | Often open; clear-text phase visible | Dedicated encrypted port |
| Client configuration | Require TLS / STARTTLS | SSL/TLS from the start |
For server-to-server relay, STARTTLS on port 25 is common when both sides support it. Opportunistic TLS (trying STARTTLS and falling back) improves confidentiality but is weaker than mandatory TLS.
Configuration guidance for applications and clients
When you configure an application or mail client:
- Prefer port 587 with STARTTLS (sometimes labeled “TLS” or “STARTTLS”).
- If the library or client only offers “SSL”, try port 465 with implicit TLS.
- Always require a valid server certificate; do not disable certificate verification in production.
- For IMAP, use port 993 (implicit) or 143 with STARTTLS.
In Laravel or other frameworks that use Symfony Mailer / SwiftMailer, the transport scheme often encodes the choice:
smtp://user:[email protected]:587?encryption=tls
# or
smtps://user:[email protected]:465ArawaMail’s outbound submission endpoints support both patterns so teams can choose the method that matches their existing client libraries and network policies. See the related guide on SMTP ports 25, 465, and 587 for the full port landscape.
How we evaluated the options
This comparison is based on the current RFCs (RFC 3207 for STARTTLS, RFC 8314 for the recommendation of implicit TLS on dedicated ports, and RFC 6409 for submission), observed behavior of major providers, and the practical constraints of application libraries and corporate firewalls. We prioritize configurations that (1) encrypt credentials before they leave the client and (2) align with the ports that are least likely to be blocked or rate-limited.
Common mistakes to avoid
- Using port 25 for client submission — many networks block it and it is intended for relay.
- Disabling certificate checks “to make it work.”
- Assuming “SSL” always means port 465; some UIs use the term generically.
- Leaving AUTH available on the clear-text phase of a STARTTLS connection.
Correct TLS configuration is one piece of the larger authentication picture that includes SPF, DKIM, and DMARC. Once the transport is encrypted, make sure the domain itself is properly authenticated so receiving servers trust the messages.
FAQ
Is STARTTLS less secure than implicit TLS?
No. Once the handshake completes, both provide equivalent encryption. The difference is only in how the session begins. Mandatory STARTTLS (server rejects AUTH before upgrade) closes the main risk.
Which port should my application use with ArawaMail?
Port 587 with STARTTLS is the recommended default. Port 465 with implicit TLS is available for clients that require it.
Does IMAP follow the same rules?
Yes. IMAP uses STARTTLS on 143 or implicit TLS on 993. The same security considerations apply.
What about opportunistic TLS?
Opportunistic STARTTLS (try encryption, fall back to clear text) improves confidentiality for many messages but is not a substitute for mandatory TLS on submission ports where credentials are involved.