SMTPS on port 465 isn’t actually a separate protocol, but rather SMTP tunneled over TLS from the very beginning.
Let’s watch a real SMTPS transaction unfold. Imagine we’re sending an email from sender@example.com to recipient@another.com using a client configured for SMTPS.
C: EHLO smtp.example.com
S: 250-smtp.example.com
S: 250-STARTTLS
S: 250-8BITMIME
S: 250-SIZE 52428800
S: 250 HELP
C: STARTTLS
S: 220 TLS go ahead
< TLS handshake occurs here. The client and server negotiate cipher suites, exchange certificates, and establish an encrypted channel. >
C: EHLO smtp.example.com
S: 250-smtp.example.com
S: 250-8BITMIME
S: 250-SIZE 52428800
S: 250 HELP
C: AUTH LOGIN
S: 334 VXNlcm5hbWU6 (Username:)
C: <base64-encoded username>
S: 334 UGFzc3dvcmQ6 (Password:)
C: <base64-encoded password>
S: 235 Authentication successful
C: MAIL FROM:<sender@example.com>
S: 250 2.1.0 Ok
C: RCPT TO:<recipient@another.com>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Subject: Test SMTPS
C:
C: This is a test email sent over SMTPS.
C: .
S: 250 2.0.0 Ok: queued as 12345ABCDEF
C: QUIT
S: 221 2.0.0 Bye
Notice how the STARTTLS command is issued before any authentication or mail commands. This is the key difference from the more common STARTTLS on port 587. On port 465, the connection is established on that port expecting TLS from the outset. The client initiates a TLS handshake immediately, and only after the handshake is complete does the server present its standard SMTP EHLO response. The STARTTLS command shown in the trace is actually a formality after the TLS tunnel is already established; it’s the server confirming that it supports TLS, which it’s already using.
The primary problem SMTPS on port 465 solves is providing a secure channel for sending email without requiring the client to explicitly initiate a TLS negotiation after connecting. This was an earlier, and now largely superseded, method compared to STARTTLS on port 587. The main advantage was simplicity for clients that only needed one port for secure SMTP. However, it also led to confusion because it wasn’t an officially standardized extension to SMTP in the same way STARTTLS became. The IANA eventually reassigned port 465 for "URL RLS" and recommended port 587 for "mail submission" with STARTTLS. Despite this, many legacy systems and some mail providers still support SMTPS on 465 for backward compatibility.
To set this up, you’ll typically configure your mail server software (like Postfix or Sendmail) to listen on port 465 and immediately initiate a TLS handshake.
For Postfix, this involves:
- Enabling the
smtpd_tls_wrappermode: This tells Postfix to expect TLS on the specified port from the moment the connection is made. - Specifying the port in
master.cf: You’ll add an entry for the SMTPS service. - Configuring TLS certificates: Ensure you have valid certificate and key files.
Here’s a snippet for master.cf:
smtps inet n - y - - smtpd
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
And in main.cf, you’d ensure your smtpd_tls_cert_file and smtpd_tls_key_file are correctly set, for example:
smtpd_tls_cert_file=/etc/ssl/certs/my_mail_server.crt
smtpd_tls_key_file=/etc/ssl/private/my_mail_server.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls=yes
smtpd_tls_security_level=may
The smtpd_tls_wrappermode=yes is the crucial setting here. It instructs Postfix’s SMTP server daemon (smtpd) to immediately begin the TLS handshake upon accepting a connection on this port, rather than waiting for a STARTTLS command. This is what differentiates it from STARTTLS on port 587, where the initial connection is plaintext until the STARTTLS command is issued.
The most surprising thing is that the STARTTLS command, when observed on port 465 after the TLS handshake, is technically redundant. The connection is already encrypted. The server is essentially acknowledging that it can do TLS, which it’s already doing. This is a historical artifact of how SMTPS was implemented before STARTTLS became the standard for secure submission on port 587.
Once you have SMTPS running, the next challenge is understanding the nuances of mail submission versus relaying, which often involves configuring SASL authentication and potentially different client restrictions.