What is SMTP TLS and how STARTTLS protects email in transit

SMTP TLS is what keeps email encrypted as it moves between mail servers. When it's missing or misconfigured, your inbound messages can cross the internet in plain text - here's how it works and how to check yours.

Every email your domain receives arrives over SMTP, and SMTP started life with no encryption at all. TLS was bolted on later through a command called STARTTLS, and today it protects most mail in transit - but only when every MX host is configured to use it correctly. This guide explains what SMTP TLS is, how STARTTLS negotiates it, where it goes wrong, and how SecRift checks yours.

What is SMTP TLS?

SMTP TLS is transport encryption for email. When one mail server delivers a message to another, TLS wraps that connection so the content and metadata can't be read by anything sitting on the network in between.

The mechanism is called STARTTLS. A sending server connects to your MX host in plain text on port 25, then upgrades the same connection to TLS before handing over the message. It's the SMTP equivalent of the padlock on a website, with one important difference: for server-to-server mail it is opportunistic. The sender uses TLS if it's offered and quietly continues in plain text if it isn't. That trade-off is what SMTP TLS gets right - and what policies like MTA-STS and DANE exist to reinforce.

How SMTP TLS works

A delivery over STARTTLS runs through a fixed sequence:

• Connect. The sending server opens a plain-text connection to your MX host on port 25 and reads the greeting banner.
• EHLO. It introduces itself, and your server replies with a list of supported extensions. If STARTTLS is in that list, encryption is available.
• Upgrade. The sender issues STARTTLS, and both sides perform a TLS handshake on the existing connection.
• Certificate. During the handshake your MX host presents its certificate, and a TLS version and cipher suite are negotiated.
• Deliver. Only now does the actual message - envelope, headers, and body - travel across the encrypted channel.

Two things get decided in that handshake and matter for security. The protocol version should be TLS 1.2 at minimum and ideally TLS 1.3. The cipher suite should provide forward secrecy, so that recording today's traffic can't decrypt it later even if the server key leaks, and authenticated encryption to prevent tampering.

Why SMTP TLS matters

Mail between servers routinely carries exactly what an attacker wants: password resets, invoices, contracts, internal threads. Without transport encryption, anyone able to observe the network path - a compromised router, a hostile ISP, a shared network segment - can read all of it as it passes.

Strong SMTP TLS on every MX host closes that window. It's also the foundation the stricter policies build on. MTA-STS tells senders to refuse delivery when TLS or the certificate doesn't check out, and DANE pins your certificate through DNSSEC - but both assume your MX hosts already present a valid, name-matched certificate over a modern protocol. If the underlying TLS is weak, those policies have nothing solid to enforce.

Common SMTP TLS mistakes

• STARTTLS missing on a backup MX. The primary host encrypts, but a secondary or fallback MX doesn't advertise STARTTLS, so mail routed through it travels in cleartext.
• Deprecated protocol versions. TLS 1.0 and TLS 1.1 are prohibited by RFC 8996 yet still enabled on many mail servers.
• Certificate problems. Expired certificates, self-signed certificates, or a name that doesn't match the MX hostname all break the moment a sender enforcing MTA-STS tries to validate them.
• Weak keys or old signatures. RSA keys under 2048 bits or SHA-1 signatures no longer meet baseline strength.
• Ciphers without forward secrecy. Static RSA key exchange means one leaked key retroactively decrypts every past session.
• A non-FQDN greeting. A server that identifies itself with a bare hostname instead of a fully qualified domain name is a configuration hygiene signal worth fixing.

How SecRift checks SMTP TLS

SecRift connects to every MX host the way a sending server would, completes the STARTTLS handshake, and breaks the result into five findings:

• MX discovery - confirms the domain publishes MX hosts to evaluate. A null MX record is recognized as "does not accept mail" and the scan is skipped rather than penalized.
• STARTTLS support - checks that every MX host advertises and accepts STARTTLS, so no inbound path falls back to plain text. It also flags a host that greets with a non-FQDN hostname.
• TLS protocol version - rewards TLS 1.3 across all hosts, accepts TLS 1.2 as the minimum, and flags deprecated TLS 1.0/1.1 or a broken SSLv3.
• Certificate validity - verifies each certificate is trusted, name-matched, time-valid, and backed by an adequate key. Expired, self-signed, mismatched, or missing certificates are called out because they break MTA-STS enforcement.
• Cipher quality - confirms every host negotiates a modern AEAD suite with forward secrecy, and flags CBC-only suites, static RSA key exchange, or outright broken ciphers like RC4 and 3DES.

Each finding comes with a plain-language summary and, where something is wrong, one concrete fix. SecRift only measures what your servers actually negotiate, so the result reflects the transport security a real sender would get.

SMTP TLS pairs naturally with TLS-RPT, which collects reports when a sending server can't reach you securely - so you hear about failures instead of guessing.

Run a free scan on any domain at secrift.com and see your SMTP TLS posture in seconds.