“smtps” é também o nome de um serviço registado na IANA, com a porta TCP número 465. O serviço destinava-se a ser utilizado pelos Agentes de Transferência de Correio (MTAs), como um ponto de contacto onde estes podiam trocar correio electrónico numa forma encriptada e não em texto simples. Contudo, o registo foi rapidamente revogado, uma vez que os esforços de padronização resultaram numa abordagem alternativa a ser padronizada. O registo nunca foi restabelecido.

Ao descrever o registo do serviço IANA, a capitalização oficial é “smtps”. Ao descrever o protocolo de rede, a capitalização “SMTPS” é frequentemente utilizada (semelhante a como HTTPS é capitalizada).

Port 587 é a porta bem conhecida para submeter correio a um servidor, frequentemente (mas não é necessário que seja) encriptado utilizando STARTTLS. Alguns fornecedores de serviços de correio electrónico permitem aos seus clientes utilizar o protocolo SMTPS para acederem a uma versão encriptada em TLS do serviço de “submissão” na porta 465. Este é um serviço diferente daquele a que o registo original da IANA dedicou a porta (pois costumava ser dedicado ao conteúdo encriptado entregue tal como está / em texto simples, enquanto que actualmente o SMTPS na porta 465 ainda utiliza conteúdo em texto simples, apenas embrulhado dentro do transporte encriptado em TLS – basicamente o mecanismo inverso).

RFC 8314 visa rectificar este problema e integrar o uso da porta 465 como uma porta de “submissão” encriptada em TLS nos bem conhecidos registos de portos publicados pela IANA. O nome do serviço proposto é “submissions”.

Embora já não exista um endpoint oficial registado para o serviço smtps, ainda é possível trocar correio electrónico sobre um transporte encriptado com garantias semelhantes às oferecidas pelos smtps, em particular com a garantia de que ou a troca é bem sucedida, ou não acontece de todo, utilizando o DANE em combinação com o DNSSEC. Muitos servidores de correio electrónico estão configurados para não entregar correio electrónico em segurança, ou para tentar primeiro a entrega segura com o mecanismo STARTTLS, e se isso falhar, por exemplo porque o serviço remoto não o oferece, ou porque um ataque MITM bem sucedido despojou o anúncio da funcionalidade, basta cair de volta à entrega por meios inseguros.