STARTTLS on MX hosts

Offer STARTTLS on every MX host with a certificate that matches its hostname and a current TLS configuration, so incoming mail can be encrypted.

What it is

STARTTLS is the SMTP extension that upgrades a plaintext connection on port 25 to TLS. A receiving MX host advertises it in its EHLO response and the sending server switches to TLS before it transmits the message.

Why it matters

Without it, every message to your domain crosses the internet in plaintext. Mailbox providers flag unencrypted delivery to users, and MTA-STS and DANE cannot work on a host that does not offer TLS.

How to implement

Advertise STARTTLS on every MX host, including backup MX hosts and any run by a filtering provider. Serve a certificate that matches the MX hostname, not only the mail domain, with the complete intermediate chain.

Apply the same TLS parameters as for a website: TLS 1.2 and 1.3 only, no insecure renegotiation, no 0-RTT, extended master secret, a sound cipher order, and adequate certificate key and signature algorithms. The Website Specification’s HTTPS and TLS page has the full checklist.

Mail differs from the web in one respect. Delivery between servers is opportunistic: a sender that cannot negotiate TLS, or does not trust the certificate, falls back to plaintext, and there is no HSTS to stop it. MTA-STS and DANE are what make TLS mandatory for your domain. STARTTLS is the prerequisite for both.

CAA for MX hosts

Publish CAA records for the domain your MX hostnames live under, naming the CAs allowed to issue their certificates. This applies when the MX hosts sit under a different domain than your website.

RPKI for the prefixes your mail servers announce is covered in The Website Specification’s RPKI page.

Common mistakes

  • Offering STARTTLS on the primary MX but not on a backup MX, which attackers and misrouted mail then use.
  • Serving a self-signed or expired certificate, or one for the mail domain instead of the MX hostname.
  • Omitting the intermediate certificate, so stricter senders cannot build the chain.
  • Keeping TLS 1.0 or 1.1 enabled for old senders long after they are gone.
  • Assuming STARTTLS alone protects delivery when nothing requires senders to use it.

Verification

Connect with openssl s_client -starttls smtp -connect mx.example.com:25 for each MX, confirm STARTTLS appears after EHLO, and check the certificate name, chain, and expiry. Run a TLS scanner or Internet.nl’s mail test against every MX host and compare the results with the website checklist.

Sources

  1. RFC 3207 — SMTP Service Extension for Secure SMTP over TLS — IETF
  2. RFC 8996 — Deprecating TLS 1.0 and TLS 1.1 — IETF
  3. RFC 9325 — Recommendations for Secure Use of TLS and DTLS — IETF
  4. RFC 8659 — DNS Certification Authority Authorization (CAA) Resource Record — IETF