Pedro Paiva

Email learning series

Email transport security: what TLS protects

By Pedro Paiva

Our application can send a welcome email through HTTPS and still have unanswered questions about later connections. TLS protects a particular connection. Each new connection has its own protection and identity checks.

Draw the boundaries

Application
  | HTTPS API, or SMTP submission with validated TLS
  v
Sending service (TLS terminates here)
  | SMTP transfer: separate TLS session, if negotiated
  v
Receiving server (TLS terminates here)
  | Internal delivery and storage: provider-specific protections
  v
Mailbox service
  | IMAP/POP over TLS or webmail HTTPS: another TLS session
  v
Reader's client

The sending and receiving services can read the message while handling it. TLS on a network connection doesn’t encrypt stored message content. Encryption at rest protects storage under the provider’s model. End-to-end message encryption, such as S/MIME or OpenPGP, is a different mechanism with different key management and metadata limits.

STARTTLS and implicit TLS

With STARTTLS, SMTP begins in plaintext, advertises the extension in EHLO, then upgrades the connection. After a successful TLS handshake the client issues EHLO again; pre-TLS capability knowledge is discarded. The upgrade must happen before sending authentication secrets or sensitive message data on a connection requiring TLS.

With implicit TLS, the TLS handshake happens immediately after connection, before SMTP commands. Port 465 is commonly used for implicit-TLS submission; port 587 commonly uses STARTTLS. RFC 8314 recommends protected submission and access, with a transition preference for implicit TLS. Server-to-server delivery remains a different operational environment, usually on port 25.

Encryption alone doesn’t prove the peer is the intended server. Validated submission checks the certificate chain, hostname and validity according to the applicable rules. Disabling verification to “fix” a certificate error discards that identity protection. Use supported TLS versions and current TLS recommendations rather than treating every old TLS negotiation as equally secure.

For SES SMTP, follow the regional endpoint and TLS configuration instructions. SES API submission uses HTTPS instead. Neither first-hop choice by itself guarantees all onward hops use TLS.

Why opportunistic transfer has limits

Server-to-server SMTP often uses opportunistic STARTTLS: attempt encryption when offered, but allow plaintext delivery if it isn’t available and no enforced policy prohibits fallback. This improves privacy over plaintext-only operation but can be exposed to STARTTLS stripping or downgrade. Opportunistic deployments may also lack strict certificate identity validation.

Compare three connection policies:

Connection Required evidence Failure behavior
Validated application submission TLS plus expected certificate identity Fail rather than send credentials or data insecurely.
Opportunistic SMTP transfer TLS if available, implementation-dependent identity checks May fall back absent a stronger policy.
Policy-enforced transfer TLS plus identity satisfying the applicable policy Defer/fail when requirements cannot be met.

Policies strengthen the receiving hop

MTA-STS lets a receiving domain publish a discovery TXT record at _mta-sts and serve an HTTPS policy at https://mta-sts.DOMAIN/.well-known/mta-sts.txt. The policy lists permitted MX patterns and an expiry period. Supporting senders in enforce mode require TLS and validated certificates matching the allowed destination. Testing mode reports problems without demanding enforcement.

MTA-STS needs working HTTPS policy hosting, correct MX patterns and certificates, and sender support. Cached enforce policies help resist downgrade, while first discovery and cache expiry have important limits. Don’t claim that unauthenticated DNS discovery alone makes every first connection downgrade-proof.

TLS reporting, RFC 8460, publishes a report destination using _smtp._tls. It collects aggregate information about failures such as certificate or policy problems. Reporting provides visibility; it does not itself require encryption or block a transfer.

DANE for SMTP uses TLSA records at names such as _25._tcp.mx1.example.net. DNSSEC authenticates the DNS routing and TLSA information under the rules in RFC 7672; supporting senders use the authenticated association to verify TLS peers. Ordinary unsigned DNS with a TLSA-shaped record isn’t equivalent. The receiving domain needs a correctly validated DNSSEC chain and appropriate TLSA deployment, and the sender needs DANE support.

All three concern the sending-server-to-receiving-server hop. They don’t protect provider storage, internal processing, every later relay, or content after a reader downloads it. Nor does TLS establish that the message’s author is honest. Diagnose transport policy separately from sender authentication and spam filtering.

References