„smtps” jest również nazwą usługi zarejestrowanej przez IANA, z portem TCP o numerze 465. Usługa ta była przeznaczona do użytku przez agentów przesyłania poczty (MTA), jako punkt kontaktowy, w którym mogli oni wymieniać wiadomości e-mail w formie zaszyfrowanej, a nie w postaci zwykłego tekstu. Rejestracja została jednak szybko cofnięta, ponieważ w wyniku działań standaryzacyjnych znormalizowano alternatywne podejście. Rejestracja nigdy nie została przywrócona.

Przy opisie rejestracji usługi IANA, oficjalną wielkością liter jest „smtps”. Przy opisie protokołu sieciowego często używa się wielkich liter „SMTPS” (podobnie jak HTTPS).

Port 587 jest dobrze znanym portem do przesyłania poczty do serwera, często (ale nie musi) szyfrowanym przy użyciu STARTTLS. Niektórzy dostawcy usług poczty elektronicznej umożliwiają swoim klientom korzystanie z protokołu SMTPS w celu uzyskania dostępu do szyfrowanej przez TLS wersji usługi „wysyłania” na porcie 465. Jest to inna usługa niż ta, do której port ten był przeznaczony w oryginalnej rejestracji IANA (ponieważ był on przeznaczony dla zaszyfrowanej treści dostarczanej w postaci „as-is”/”plain text”, podczas gdy dzisiejszy SMTPS na porcie 465 nadal używa treści plaintext, tylko opakowanej w szyfrowany transport TLS – w zasadzie mechanizm odwrotny).

RFC 8314 ma na celu naprawienie tego problemu i zintegrowanie użycia portu 465 jako szyfrowanego portu „submission” TLS z dobrze znanymi rejestracjami portów opublikowanymi przez IANA. Proponowana nazwa usługi to „submissions”.

Pomimo że nie istnieje już żaden oficjalny zarejestrowany punkt końcowy dla usługi smtps, nadal możliwa jest wymiana wiadomości e-mail za pośrednictwem szyfrowanego transportu z gwarancjami podobnymi do tych oferowanych przez smtps, w szczególności z gwarancją, że albo wymiana zakończy się bezpiecznie, albo w ogóle nie dojdzie do skutku, dzięki zastosowaniu DANE w połączeniu z DNSSEC. Wiele serwerów poczty elektronicznej jest skonfigurowanych tak, aby albo w ogóle nie dostarczać poczty elektronicznej w sposób bezpieczny, albo najpierw próbować bezpiecznego dostarczania za pomocą mechanizmu STARTTLS, a jeśli to się nie powiedzie, na przykład dlatego, że zdalna usługa nie oferuje takiej możliwości, lub dlatego, że udany atak MITM pozbawił ogłoszenie tej funkcji, po prostu powrócić do dostarczania za pomocą niezabezpieczonych środków.