SMTP TLS

Implicit TLS

Implicit TLS negotiates the TLS handshake before any SMTP command is exchanged, so no part of the session is ever in the clear. Port 465 carries this mode, and it is commonly called SMTPS.

RFC 8314 recommends implicit TLS for message submission and registers 465 for submission over TLS. That recommendation reversed an earlier position that had deprecated the port, which is why older documentation calls 465 obsolete.

Nothing about the SMTP conversation itself changes. The commands, responses and authentication mechanisms are identical to a cleartext session, with the entire exchange wrapped in the TLS layer.

Implicit TLS is the safer choice wherever a client can be made to speak it, because it removes a decision from the connection. There is no window in which the session is unencrypted and no capability line for anything on the path to tamper with, so the failure mode is a refused connection rather than a quietly downgraded one. A refused connection gets noticed. A downgraded one does not.

Explicit TLS with STARTTLS

Explicit TLS starts as a cleartext connection and upgrades in place. The client issues STARTTLS, the server accepts, and both sides renegotiate the connection as an encrypted one before any credential is sent.

STARTTLS is defined in RFC 3207 as an SMTP service extension. It runs on the submission port 587 for clients and on port 25 for server-to-server relay.

Once the upgrade completes, both sides discard anything negotiated before it. RFC 3207 requires the client to reissue EHLO after the handshake, because the server's advertised capabilities before encryption cannot be trusted.

The word doing the work in that requirement is trusted. Everything the server said before the handshake was said in the clear, which means it was said by whoever happened to be on the path. Reissuing EHLO is not tidiness, it is the client throwing away a set of claims it has no reason to believe, and a client that skips it is authenticating against capabilities an attacker was free to write.

On our own relay we did not leave this to negotiation. TLS and exact SMTP authentication are mandatory on the inbound forwarding path, TCP 2525 is firewall-restricted to our API host, and unsigned or replayed requests are rejected outright alongside arbitrary destinations, extra recipients and multiple forwarding hops. Mandatory is a different posture from opportunistic: there is no cleartext path to fall back to, so there is nothing to strip.

Port 25 and relay traffic

Port 25 is the port for server-to-server mail transfer rather than client submission. Its traffic may be unencrypted or may upgrade through STARTTLS, depending on what both servers support.

Encryption on relay is opportunistic by default. A sending server that offers STARTTLS and finds a receiver that does not support it will generally deliver in the clear rather than fail, which is a deliberate design decision favoring delivery over confidentiality.

Client submission does not belong on port 25. Networks and hosting providers block it widely to limit compromised machines sending directly, so an application configured to submit there frequently sees a timeout with no error.

Downgrade attacks and the protocols that prevent them

Opportunistic STARTTLS is vulnerable to stripping. An attacker positioned on the path can remove the STARTTLS capability from the server's response, and a client that treats encryption as optional will continue in cleartext without warning.

MTA-STS addresses this for receiving domains. Defined in RFC 8461, it lets a domain publish a policy stating that its mail servers support TLS and that senders should refuse to deliver if a valid encrypted connection cannot be established.

DANE provides the same guarantee through DNSSEC. Defined in RFC 7672, it publishes the expected certificate association in DNS, so a sending server can detect a substituted or stripped connection.

TLS reporting closes the loop. RFC 8460 defines a mechanism for receiving domains to collect reports of connection failures from senders, which is how a stripping attack becomes visible rather than silent.

A TLS problem usually presents as a system reporting success, and that is the pattern worth internalizing. We hit our own version of this on branded tracking domains, on the link side rather than the mail side. Our health check treated a resolving CNAME as proof the domain was ready, so a hostname could be marked verified while TLS was not actually usable, and the links we shipped inside emails then failed the handshake at the recipient. Every indicator we had was green, and the reader still got an error.

Underneath it was a category error in what we were measuring: DNS correctness is not the same claim as live TLS readiness, and we had been treating one as evidence of the other. The fix was to probe the endpoint over verified HTTPS rather than infer it, and to require both conditions before marking a domain ready.

That checker now feeds the same trends layer that watches the rest of our sending health. It tracks spam-rate and per-provider placement trends, monitors DNSBL blocklists through Spamhaus DQS, and gates degradation alerts behind hysteresis thresholds so one bad day does not page anyone or read as a crisis.

I bring up a tracking-link bug on a page about SMTP because the failure is structurally identical, and it is the one I would warn a team about. Nothing in either case reported an error, DNS resolved, the check passed, and the encrypted connection that was supposed to happen did not. Opportunistic STARTTLS fails the same quiet way, which is exactly why MTA-STS and TLS reporting exist: they convert a silent absence into a signal somebody receives.

Protocol versions and ciphers

TLS 1.2 and TLS 1.3 are the versions in current use. RFC 8996 deprecates TLS 1.0 and TLS 1.1, so a server still offering them is running protocol versions the IETF has formally retired.

TLS 1.3 removes the older key exchange and cipher options that made downgrade and weak-cipher attacks practical. Forward secrecy is mandatory in it, so a later compromise of the server key does not expose previously captured sessions.

Certificate validation is a separate question from encryption. A session can be encrypted against an unvalidated or self-signed certificate, which protects against passive capture but not against an active attacker presenting their own certificate.

Disabling certificate validation to make a connection work is the most common bad fix in this area, and it is worth naming as such. It converts a loud failure into a silent vulnerability, and because mail keeps flowing afterwards nobody revisits it. The certificate error was information about the connection. Turning it off deletes the information and leaves the condition.

The surrounding authentication is worth reading alongside the transport question. SPF, DKIM and DMARC all have to be aligned, and Google's sender guidelines put the DMARC floor for anyone sending 5,000 or more messages a day at p=none, provided the From domain is aligned with either the SPF domain or the DKIM domain. Transport encryption and domain authentication answer different questions, but neither is a setting you get to treat as optional once volume is involved.

None of this is something I want a person hand-configuring, and it is not something an AI agent should have to reason about either. It is why we built Nitrosend as an MCP server rather than another SMTP client library: your agent calls one send action, and the SMTP transport is Nitrosend's job rather than something re-derived per integration. That is the actual case for an AI-native sender over hand-rolled SMTP: not that we run a bigger relay than everyone else, but that the agent sending your email should not need to know any of what is on this page to get it right. Nitrosend runs inside Claude, ChatGPT, Cursor, Codex and any MCP client for exactly that reason, including as a listed plugin in ChatGPT's plugin directory.

Go deeper