En SMTP, le client envoie EHLO, voit 250-STARTTLS dans la liste des capacités, envoie STARTTLS, puis le handshake TLS se déroule sur la même connexion TCP (port 25 entre serveurs, 587 pour la soumission). Entre serveurs de messagerie, STARTTLS est opportuniste : un attaquant placé sur le chemin peut supprimer la capacité annoncée, et l’expéditeur continue alors en clair ; de plus, les expéditeurs acceptent généralement n’importe quel certificat.
Les solutions viennent des couches de politique : MTA-STS (RFC 8461) et DANE (RFC 7672) permettent à un domaine destinataire d’exiger un TLS authentifié, et TLS-RPT (RFC 8460) signale les échecs. Pour l’accès des clients, la RFC 8314 recommande le TLS implicite (ports 465, 993, 995) plutôt que STARTTLS. Des bogues d’implémentation, comme l’injection de commandes avant la bascule (du texte en clair mis en mémoire tampon puis traité comme s’il était arrivé via TLS), ont touché de nombreux serveurs de messagerie.
openssl s_client -starttls smtp -connect mx.example.com:25 affiche le certificat et les paramètres négociés ; le vérificateur STARTTLS effectue le même test.