SMTP TLS and STARTTLS for email
Every email sent between mail servers travels over SMTP. Whether that connection is encrypted depends on SMTP TLS — a set of mechanisms that protect mail in transit and contribute to the trust profile of the sending server.
What is SMTP TLS?
SMTP TLS refers to the use of Transport Layer Security to encrypt the connection between mail servers during email delivery. When two mail servers communicate using SMTP, TLS provides a secure, encrypted channel that protects message content from interception in transit.
SMTP TLS operates at the transport layer — between servers — not at the message layer. It does not authenticate the identity of the message author or guarantee that the message will reach the inbox. It protects the confidentiality and integrity of the data as it travels between servers.
All major mail providers and hosting platforms support SMTP TLS. Sending servers that do not offer STARTTLS or that have broken TLS configurations are increasingly associated with legacy infrastructure or poorly maintained sending setups.
What is STARTTLS?
STARTTLS is the SMTP extension that upgrades a plain-text SMTP connection to TLS encryption. When a sending server connects to a receiving server, it first establishes a plain TCP connection on port 25. The receiving server advertises STARTTLS in its EHLO response if it supports TLS upgrades.
If the sending server supports STARTTLS, it sends the STARTTLS command and the two servers negotiate a TLS session before any message data is transmitted. The SMTP conversation then continues inside the encrypted channel.
STARTTLS operates on the standard SMTP port 25 and on port 587 for message submission. Unlike SMTPS (port 465), which uses an implicit TLS connection from the start, STARTTLS begins as plain text and upgrades. Both are in use for different parts of the mail delivery chain.
Why SMTP TLS matters for deliverability
SMTP TLS is widely expected by major mail providers. Gmail, Outlook, and most large receivers use TLS for inbound SMTP connections and report on TLS usage in their postmaster tools and TLS-RPT reports.
A server that does not offer STARTTLS, or that presents a broken TLS configuration — expired certificate, hostname mismatch, or unsupported cipher suites — is a negative signal in the overall deliverability profile. It does not automatically cause mail to be rejected or sent to spam, but it reduces the trust level associated with that server.
TLS support is also a marker used by spam filtering systems to distinguish reputable sending infrastructure from low-quality or suspect sources. Reputable senders consistently support TLS with valid, current certificates.
Opportunistic TLS vs enforced TLS
Most SMTP TLS in use today is opportunistic. The sending server will attempt TLS if the receiving server advertises STARTTLS support, but will fall back to plain text if TLS is not available or fails to negotiate. Opportunistic TLS provides encryption when possible without breaking mail delivery.
Opportunistic TLS has a key limitation: a network attacker performing a downgrade attack can strip the STARTTLS advertisement, causing the sending server to deliver plain text without either party being aware. This is a known limitation of SMTP STARTTLS without additional enforcement.
Enforced TLS is available through two complementary standards. MTA-STS allows a domain to publish a policy requiring mail delivery over validated TLS — senders that support MTA-STS will refuse to fall back to plain text or accept invalid certificates. DANE uses DNSSEC-secured DNS records to pin the TLS certificate, but requires DNSSEC and sees more limited adoption in practice.
TLS certificates and hostname validation
A valid TLS certificate is required for a meaningful TLS session. Receiving servers inspect the certificate presented by the connecting server and may apply different levels of scrutiny depending on their configuration.
The key certificate checks are: whether the certificate is signed by a trusted certificate authority; whether the certificate has not expired; and whether the certificate's Common Name or Subject Alternative Name matches the hostname announced in the EHLO greeting.
A certificate that is self-signed, expired, or that has a hostname mismatch creates a configuration inconsistency. With opportunistic TLS, many receivers will still accept the connection rather than drop the mail, but the error is a negative signal and is surfaced in TLS-RPT reports.
Senders using MTA-STS or DANE enforcement must present a valid, trusted certificate that matches their published policy — otherwise delivery fails.
Common SMTP TLS problems
STARTTLS not advertised. The sending or receiving server does not offer STARTTLS at all, meaning all connections from that server are plain text.
Expired TLS certificate. The certificate has passed its expiry date. Receivers logging TLS events will flag this as an error.
Hostname mismatch. The certificate's Common Name or Subject Alternative Name does not match the EHLO hostname. A common misconfiguration on servers where the hostname and certificate were set up independently.
Self-signed certificate. The certificate is not signed by a trusted CA. With opportunistic TLS many receivers still accept this, but it is an anomaly that reduces confidence in the server's configuration.
TLS version or cipher too old. Receivers may reject connections that only support very old TLS versions or weak cipher suites.
STARTTLS advertised but consistently fails. The server advertises STARTTLS but the TLS handshake fails, causing sending servers to either retry plain text or abandon delivery.
SMTP TLS vs SPF, DKIM, and DMARC
SMTP TLS and the message-level authentication standards operate at different layers and serve different purposes.
SMTP TLS encrypts the transport connection between servers. It protects data in transit but says nothing about the identity of the message author or whether the domain owner authorised the sending server.
SPF checks whether the sending IP is authorised to send mail for the MAIL FROM domain. DKIM verifies that the message has not been altered in transit and that a particular domain signed it. DMARC ties SPF and DKIM together and specifies how receivers should handle messages that fail alignment.
None of these standards replace each other. A well-configured sending server should have valid TLS for transport security and valid SPF, DKIM, and DMARC for message authentication. Each layer addresses a different aspect of trust.
How to fix SMTP TLS issues
Obtain or renew a valid TLS certificate from a trusted certificate authority. Let's Encrypt provides free, widely trusted certificates and is supported by most mail server software.
Ensure the certificate covers the mail server hostname. The Common Name or a Subject Alternative Name should match the EHLO hostname your mail server announces.
Enable STARTTLS in your mail server configuration. For Postfix, set smtpd_tls_cert_file, smtpd_tls_key_file, and smtpd_tls_security_level to may or higher. For Exim, configure tls_advertise_hosts. Other mail servers have equivalent settings.
Keep TLS configuration current. Disable TLS 1.0 and 1.1 if still enabled. Prefer TLS 1.2 or 1.3 and use strong cipher suites.
Consider implementing MTA-STS and TLS-RPT. MTA-STS signals that your domain requires TLS from senders, and TLS-RPT provides reports on TLS delivery errors to your domain.
Verify with an SMTP TLS checker after changes. Confirm STARTTLS is advertised, the certificate is valid and trusted, and the hostname matches before treating the issue as resolved.
How MXFend can help
SMTP TLS Checker — connects to your mail server on port 25, performs the full SMTP handshake, and checks STARTTLS support, TLS certificate validity, certificate hostname, expiry date, and cipher details. The most direct tool for inspecting your TLS configuration.
Email Security Score — combines SMTP TLS, blacklist, SPF, DKIM, DMARC, MX, BIMI, MTA-STS, and TLS-RPT into a single weighted audit.
Blacklist Checker — tests your sending IP against major DNS blacklists. TLS problems often accompany other configuration issues that contribute to blacklist listings.
MTA-STS Checker — verifies whether your domain has a valid MTA-STS policy published to enforce TLS on inbound delivery.
TLS-RPT Checker — checks whether your domain publishes a TLS-RPT policy for receiving TLS error reports from other mail servers.
Frequently asked questions
What is SMTP TLS?
SMTP TLS is the use of Transport Layer Security to encrypt the connection between mail servers during email delivery. It protects message content from interception in transit. Most SMTP TLS in use today is opportunistic — encryption is applied when both servers support it.
What is STARTTLS in email?
STARTTLS is an SMTP extension that upgrades a plain-text SMTP connection to TLS encryption before any message data is transmitted. The sending server initiates the upgrade with the STARTTLS command after the receiving server advertises support for it in the EHLO response.
Does SMTP TLS affect email deliverability?
A missing or broken SMTP TLS configuration — no STARTTLS, expired certificate, or hostname mismatch — is a negative trust signal for receiving mail servers. It does not automatically cause mail to go to spam, but it contributes to a lower trust profile alongside other signals. Major providers expect servers to support TLS.
Is SMTP TLS the same as SPF, DKIM, or DMARC?
No. SMTP TLS encrypts the transport connection between servers. SPF, DKIM, and DMARC are message authentication standards that verify the sender's identity and protect against spoofing. They operate at different layers and do not replace each other. A fully configured mail server should have all four in place.
How do I test SMTP TLS for my mail server?
Use an SMTP TLS checker — such as the MXFend SMTP TLS Checker — to connect to your mail server, verify STARTTLS support, and check the TLS certificate for validity, expiry, and hostname match. You can also connect manually using OpenSSL: openssl s_client -starttls smtp -connect yourdomain.com:25