TLS for SMTP: upgrading transport encryption for outbound email

Why transport encryption went mainstream in 2014 and 2015

STARTTLS has been a defined SMTP extension since RFC 3207 in 2002. For the first decade of its existence, adoption was spotty and non-uniform. A sending MTA would offer STARTTLS, a receiving MTA would advertise it, and most of the time the handshake succeeded — but when it did not, the industry norm was to fall back to cleartext and send the message anyway. Email in transit was broadly unprotected.

Two events changed the conversation. The Snowden disclosures in 2013 made large-scale passive interception a concrete concern rather than a theoretical one. And in 2014, Google began publishing its transparency report on SMTP-in-transit encryption, showing month by month what percentage of outbound Gmail messages were being encrypted to which receiving domains. The report made visible what the industry had been content to ignore: meaningful volumes of email were still crossing the public internet in cleartext.

The response was fast. Large receivers upgraded their TLS posture, signed certificates where they had previously run self-signed, and began favoring senders who consistently encrypted. By 2015, STARTTLS success rates at Gmail crossed 80% inbound and are climbing. That shift has real consequences for any sender who wants to look like a modern operator rather than a carelessly configured one.

This article covers the practical side of TLS for outbound SMTP — how STARTTLS actually works, what certificate handling looks like, what the common misconfigurations are, and how to verify that your outbound traffic is being encrypted to the destinations that matter.

The Facebook precedent and the industry shift

Before discontinuing their email service in February 2014, Facebook published a widely-cited analysis showing that by actively working with peer providers to improve STARTTLS support, they had reached 95% of their outbound email encrypted — and not just encrypted, but encrypted with perfect forward secrecy and strict certificate validation. That number set an operational baseline that the rest of the industry took seriously. If one of the world's highest-volume email senders could reach 95% encrypted outbound through targeted work with receivers, anyone could.

Gmail followed with public numbers in the opposite direction — from around 30% of Gmail's outbound being TLS-protected in late 2013 to over 70% by late 2014, climbing further through the first half of 2015. The movement wasn't automatic; it required specific receivers to upgrade their TLS posture, publish real certificates, and support modern cipher suites. The transparency report made the gaps visible and created social pressure to close them.

The cumulative effect of this 24-month arc is that transport encryption has moved from "security-conscious teams do this" to "any operator running SMTP at scale does this or explains why not." The question is no longer whether to deploy TLS; it is how well-configured the deployment is and how well-monitored the outcomes are.

The STARTTLS handshake, in detail

STARTTLS is a runtime protocol upgrade. The SMTP conversation begins in cleartext. The client issues EHLO, the server responds with its capability list, and if both sides support STARTTLS, the client issues the STARTTLS command. The server responds with 220 Ready, and both sides perform a standard TLS handshake over the same TCP connection. Once the handshake completes, the client re-issues EHLO and the rest of the SMTP conversation — authentication, MAIL FROM, RCPT TO, DATA, the message body — happens inside the TLS tunnel.

C: (connects to port 25 or 587)
S: 220 mx.destination.example ESMTP
C: EHLO relay.sender.example
S: 250-mx.destination.example
S: 250-STARTTLS
S: 250-SIZE 52428800
S: 250 PIPELINING
C: STARTTLS
S: 220 Ready to start TLS
(TLS handshake: ClientHello, ServerHello, certificate, key exchange, Finished)
C: EHLO relay.sender.example
S: 250-mx.destination.example
S: 250 AUTH PLAIN LOGIN
(rest of SMTP session runs inside TLS)

Two non-obvious points. First, the re-issued EHLO after the handshake is not a formality. Servers are permitted to advertise different capabilities under TLS than they do in cleartext — authentication, for instance, is commonly only offered post-TLS. A client that reuses the pre-TLS capability list will miss this. Second, the handshake can fail in several distinct ways (certificate validation, protocol version mismatch, cipher negotiation), and how your MTA handles each failure mode is what determines whether messages leak over cleartext.

Opportunistic vs enforced TLS, and why it matters

Server-to-server SMTP traffic historically uses "opportunistic TLS". The client attempts STARTTLS, and if it succeeds, the message goes encrypted. If the handshake fails for any reason — certificate invalid, peer does not advertise STARTTLS, TLS version refused — the client falls back to cleartext and sends the message anyway. The rationale was pragmatic: email must be delivered, and the alternative of refusing to send was considered worse than sending in cleartext.

Enforced TLS — refusing to send when TLS fails — became viable at scale around 2014 because of the ecosystem shift. Google, Yahoo and the large enterprise providers all supported TLS reliably enough that enforcing it on outbound traffic to them stopped producing meaningful delivery failure. For senders who care about the privacy of their outbound traffic, enforcing TLS to specific destinations is now a sensible posture.

The middle ground — and the one most senders operate in — is "opportunistic with logging". STARTTLS is attempted always, successes and failures are logged, and periodic review identifies destinations that are quietly downgrading to cleartext. That visibility is the minimum for any sender who wants to understand their own TLS posture.

On the submission side (port 587), the story is different. Application-to-relay connections should always require TLS and authentication. There is no legitimate reason for an application to send unauthenticated mail to its own relay in 2015, and no legitimate reason for that connection to happen in cleartext. Lock the submission port down tight.

Certificates: what actually gets validated

Historically, MTAs doing STARTTLS have been lax about certificate validation. The server certificate is offered during the handshake, the client verifies the cryptography, and in most opportunistic configurations the client does not validate the certificate name against the destination hostname. The justification was that requiring hostname verification would cause too many delivery failures, since many receivers ran self-signed certificates or certificates for names that did not match their MX records.

That justification is fading. The major receivers now run properly signed certificates with matching hostnames. A sender who validates certificates against a known CA bundle, and treats validation failure as a signal worth investigating, ends up with a cleaner TLS posture than one who does not.

Three things to get right on the sender side. First, the certificate you present for authenticated submission (port 587) should be a real signed certificate, not self-signed. Clients are stricter than servers and will refuse to authenticate over self-signed TLS. Second, the certificate you present for server-to-server outbound should match the MX hostname of your sending infrastructure, so receivers that validate will pass. Third, keep the certificate chain complete and current — missing intermediates cause failures at some clients even when the cryptography is fine.

On cipher suites, the 2015 baseline is to disable SSLv3 (POODLE, 2014), disable RC4 (multiple cryptanalytic attacks since 2013), prefer TLS 1.2, and support forward secrecy via ECDHE key exchange. Mozilla publishes a server-side TLS configuration guide that is a reasonable starting point. TLS 1.1 and 1.0 support remains necessary for compatibility with older receivers; that compatibility-versus-security tradeoff will resolve in favor of security over the next two to three years.

MTA configuration examples

Configuration details vary by MTA, but the shape of a correctly-configured 2015 deployment is consistent: opportunistic TLS on port 25 with logging, enforced TLS on submission port 587, cipher suites restricted to modern choices, SSLv3 and RC4 explicitly disabled, and session tickets configured for reasonable session reuse.

Postfix main.cf — recommended April 2015 TLS posture# --- Inbound (smtpd) ---
smtpd_tls_security_level      = may
smtpd_tls_cert_file           = /etc/postfix/certs/mx.example.com.pem
smtpd_tls_key_file            = /etc/postfix/certs/mx.example.com.key
smtpd_tls_protocols           = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1
smtpd_tls_ciphers             = medium
smtpd_tls_mandatory_ciphers   = high
smtpd_tls_exclude_ciphers     = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK,
                                aECDH, EDH-DSS-DES-CBC3-SHA,
                                EDH-RSA-DES-CBC3-SHA, KRB5-DES, CBC3-SHA
smtpd_tls_loglevel            = 1
smtpd_tls_received_header     = yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache

# --- Outbound (smtp) ---
smtp_tls_security_level       = may
smtp_tls_protocols            = !SSLv2, !SSLv3
smtp_tls_mandatory_protocols  = !SSLv2, !SSLv3, !TLSv1
smtp_tls_ciphers              = medium
smtp_tls_mandatory_ciphers    = high
smtp_tls_CAfile               = /etc/ssl/certs/ca-certificates.crt
smtp_tls_loglevel             = 1
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# --- Submission (port 587) ---
# defined in master.cf:
#   submission inet n - - - - smtpd
#     -o smtpd_tls_security_level=encrypt
#     -o smtpd_tls_auth_only=yes
#     -o smtpd_sasl_auth_enable=yes

# --- Per-destination enforced TLS ---
# Enforce TLS for selected peers by publishing a policy file:
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
# /etc/postfix/tls_policy entries:
#   gmail.com      verify
#   yahoo.com      verify
#   outlook.com    verify

Exim 4.85 — equivalent TLS configuration# Advertise TLS to everyone, encrypt when both sides can
tls_advertise_hosts = *
tls_certificate     = /etc/exim/certs/mx.example.com.pem
tls_privatekey      = /etc/exim/certs/mx.example.com.key

# Disable obsolete protocols
tls_require_ciphers = NORMAL:%COMPAT:-VERS-SSL3.0:-ARCFOUR-128:-3DES-CBC

# Require TLS + AUTH on submission port (587) via a submission listener
# in your configuration:
#   daemon_smtp_ports = 25 : 587
#   tls_on_connect_ports = 465

# Outbound: attempt STARTTLS on all remote_smtp transports
remote_smtp:
    driver              = smtp
    hosts_require_tls   = gmail.com : googlemail.com : yahoo.com : outlook.com
    hosts_avoid_tls     =
    tls_verify_certificates = /etc/ssl/certs/ca-certificates.crt
    tls_verify_hosts    = gmail.com : yahoo.com

PowerMTA v4.5 — TLS configuration on a virtual MTA# /etc/pmta/config
<domain *>
    use-starttls              true
    required-tls-mode         starttls
    tls-verify-mode           optional

    # Disable weak protocols and ciphers
    tls-ciphers               "HIGH:MEDIUM:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!SSLv2:!SSLv3"
</domain>

# Enforce TLS to specific high-value destinations
<domain gmail.com>
    required-tls-mode         verify
    tls-verify-hosts          gmail-smtp-in.l.google.com
</domain>

<domain yahoo.com>
    required-tls-mode         verify
</domain>

Three configuration points worth calling out. First, the explicit !SSLv3 and cipher exclusions are what POODLE taught us: defaults can lag behind known attacks by years, and operators need to pin the configuration explicitly rather than trusting the distribution's defaults. Second, the split between "may" (opportunistic) on port 25 and "encrypt" (enforced) on submission port 587 is the standard 2015 pattern — receivers still occasionally can't do TLS, but submission clients have no such excuse. Third, per-destination TLS policies let you enforce for destinations you know work well (Gmail, Yahoo, Outlook) while leaving opportunistic behavior for everything else; this is how enforced TLS becomes practical at scale without breaking delivery to the long tail.

TLS transport encryption is complementary to — not a replacement for — message-level authentication. Your outbound SMTP traffic should be TLS-encrypted in transit AND DKIM-signed for integrity AND SPF-authorized AND covered by a DMARC policy. These controls protect against different attack surfaces: TLS protects against passive surveillance and manipulation in transit, DKIM protects against message tampering and forgery, SPF and DMARC protect against unauthorized use of your sending domain. The mechanics of setting up the DKIM side of that stack are covered in DKIM signing for transactional email: a practical setup guide.

Monitoring TLS outcomes on outbound traffic

You cannot manage what you cannot measure. The operational work is to know, for each sending day, what percentage of outbound messages were encrypted, which destinations accepted TLS, which downgraded, and which rejected.

Most MTAs log TLS outcomes at the connection level. Postfix writes lines like postfix/smtp[PID]: TLS connection established to mx.destination.example: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384. PowerMTA produces similar detail in its accounting logs. A nightly aggregation of these lines, broken down by receiving domain, reveals the pattern.

The useful outputs: (1) overall percentage of messages sent over TLS, week over week; (2) list of top 50 receiving domains with their TLS success rate, flagging any that drop below 95%; (3) list of cipher suites in use, flagging anything deprecated; (4) list of TLS-failing destinations with the specific failure reason (cert invalid, no STARTTLS, handshake refused). The same monitoring-cadence discipline applies to the broader deliverability picture — TLS posture is one input among many that receivers evaluate when they form an opinion about a sender. The fuller picture, including how receivers weigh transport encryption alongside authentication, engagement, and volume patterns, is covered in sender reputation fundamentals: how inbox providers evaluate senders.

Google Postmaster Tools, which Google launched in July 2015, shows the TLS-sent-to-Gmail percentage on the dashboard — a useful external validation. If your internal numbers say 97% TLS to Gmail and Postmaster Tools says 62%, one of the two is wrong — and it is usually the internal number, because MTAs often count the TLS handshake completing rather than the message actually being delivered.

TLS configuration checklist

• STARTTLS advertised by inbound servers, with a real signed certificate matching the MX hostname.
• Submission port 587 requires TLS and authentication; cleartext submission disabled.
• SSLv3 disabled. RC4 disabled. TLS 1.0 and 1.1 supported where necessary for interoperability but not preferred.
• TLS 1.2 enabled, with ECDHE-based ciphers for forward secrecy.
• Outbound STARTTLS attempted always; failures logged.
• Enforced TLS configured to specific destinations where privacy requirements justify it.
• Certificate chain complete and current; automated renewal monitored.
• TLS success rate monitored per receiving domain, with alerts on regressions.
• Google Postmaster Tools consulted monthly for external validation of Gmail-bound TLS rate.
• Runbook documents common TLS failures and their remediation.

Frequently asked questions

Does TLS affect deliverability? Indirectly but meaningfully. Large receivers consider TLS posture a signal of sender maturity. Consistently encrypted traffic is read as more legitimate than occasional cleartext. The direct impact on reputation is small; the indirect impact on how your sending infrastructure is perceived is real.

Should I use DANE? DNS-Based Authentication of Named Entities is a DNSSEC-protected way to publish expected TLS certificate fingerprints. It is strong but deployment complexity is high, and DNSSEC itself has limited adoption. For most senders in 2015, DANE is worth monitoring but not deploying yet. That calculation will change as DNSSEC adoption grows.

What about MTA-STS? A proposed successor to DANE with lower deployment complexity is circulating in IETF drafts, but the standard is not yet stable. Watch this space over the next year or two.

Does enforced TLS hurt delivery? If applied indiscriminately to all destinations, yes — some legitimate receivers still do not offer TLS. If applied selectively to destinations that are known to support it reliably, the impact is negligible and the privacy benefit is real.

Troubleshooting common TLS failures

These are the failure modes that come up most often in real deployments, what tends to cause each, and what to check first.

For destinations that fail consistently, the usual remediation is to classify them: reliably-TLS destinations get enforced TLS, reliably-cleartext destinations get a policy exception that accepts cleartext (with a note explaining why), and destinations in between stay opportunistic while you watch their trend. Most sending programs end up with a policy table that's mostly opportunistic, a dozen enforced destinations, and a handful of explicit exceptions for receivers that genuinely can't do TLS.

Closing thought

TLS on outbound SMTP has moved from nice-to-have to table stakes in the span of 24 months. The forcing function was a combination of large-scale surveillance awareness and public reporting by the major receivers. Senders who treat TLS as a first-class configuration concern — with proper certificates, monitoring, logging and policy enforcement where justified — operate a noticeably more credible email infrastructure than those who leave STARTTLS in its default opportunistic state. The cost of doing this well is low. The cost of doing it badly, in an industry that is increasingly watching, is higher every year.

Continue your evaluation

If this article maps to the sending layer you are building or operating, the pages below go deeper into the commercial and operational side of the same territory.