From Wikipedia, the free encyclopedia

SMTPS (Simple Mail Transfer Protocol Secure) is a method for securing the SMTP using transport layer security. It is intended to provide authentication of the communication partners, as well as data integrity and confidentiality.

SMTPS is neither a proprietary protocol nor an extension of SMTP. It is a way to secure SMTP at the transport layer, by wrapping SMTP inside Transport Layer Security (TLS). Conceptually, it is similar to how HTTPS wraps HTTP inside TLS.

This means that the client and server speak normal SMTP at the application layer, but the connection is secured by SSL or TLS. This happens when the TCP connection is established, before any mail data has been exchanged. Since whether or not to use SSL or TLS is not explicitly negotiated by the peers, services that speak SMTPS are usually reachable on a dedicated port of their own.

Difference between SMTPS and smtps[edit]

"smtps" is also the name of an IANA-registered service, with the TCP port number 465. The service was intended for use by Mail Transfer Agents (MTAs), as a point of contact where these could exchange email in an encrypted form rather than in plaintext. The registration was quickly revoked, however, as standardization efforts resulted in an alternate approach. The registration has never been reinstated.

When describing the IANA service registration, the official capitalization is "smtps". When describing the network protocol, the capitalization "SMTPS" is often used (similar to how HTTPS is capitalized).

Port 587 is the well-known port for submitting mail to a server, frequently (but not required to be) encrypted using STARTTLS. Some email service providers allow their customers to use the SMTPS protocol to access a TLS-encrypted version of the "submission" service on port 465. This is a different service from what the original IANA registration dedicated the port to (for it used to be dedicated to encrypted content delivered as-is / in plain text, whereas nowadays' SMTPS on port 465 still uses plaintext content, only wrapped within TLS-encrypted transportation-basically the reverse mechanism).

RFC 8314 corrected this problem (a special exception was made to assign TCP-465 to two use cases simultaneously) and integrated the use of port 465 as a TLS-encrypted "submission" port into the well-known port registrations published by IANA. The service is named as submissions.

While there is no longer any officially registered endpoint for the SMTP service, it is still possible to exchange email over an encrypted transport with similar guarantees as those offered by smtps, in particular with the guarantee that either the exchange succeeds securely, or does not happen at all, by using DANE in combination with DNSSEC. Many email servers are configured to either not deliver email securely at all, or to first try secure delivery with the STARTTLS mechanism. If that fails, for example, because the remote service does not offer it, or because a successful MITM-attack has stripped announcement of the feature, it simply falls back to delivery by insecure means.


In early 1997, the Internet Assigned Numbers Authority registered port 465 for smtps.[1] Late 1998 this was revoked when STARTTLS was standardized.[2] With STARTTLS, the same port can be used with or without TLS. The use of well-known ports for mail exchanges communicating with SMTP was discussed in particular at the time.[3] Port 465 currently shows[4] as registered for both Source-Specific Multicast[5] and submissions.

RFC 8314 "Cleartext Considered Obsolete: Use of TLS for Email Submission and Access"[6] proposed to recognize port 465 for implicitly encrypted email submission officially. And the IANA registration was updated 2017-12-12 using a special IESG approval accordingly.

See also[edit]


  1. ^ "NEW DRAFT: Regularizing Port Numbers for SSL". w3. 1997-02-07. Retrieved 2013-07-27.
  2. ^ Hoffman, Paul (1998-11-12). "Revoking the smtps TCP port". ietf-apps-tls (Mailing list). Internet Mail Consortium. Archived from the original on 2015-06-03. Retrieved 2016-10-22.
  3. ^ Paul Hoffman (1997-06-01). "Do we need IMAP / TLS or POP / TLS?". Internet Mail Consortium. Archived from the original on 2009-08-19. Retrieved 2009-09-16.
  4. ^ "Port Numbers". Internet Assigned Numbers Authority. 2009-09-14. Retrieved 2018-08-22.
  5. ^ "SSM". Cisco Systems. Archived from the original on 2013-01-10. Retrieved 2009-09-16.
  6. ^ "Cleartext Considered Obsolete: Use of TLS for Email Submission and Access". Retrieved 13 February 2018.