What SMTP TLS protects, and what you need to observe
With SMTP STARTTLS, the conversation starts unencrypted. After EHLO, the server may offer the STARTTLS extension. If the client accepts, the TLS handshake comes first. Only after it completes successfully does the subsequent SMTP conversation use TLS. The offer alone does not establish an encrypted connection. RFC 3207, sections 3–4
On narrow screens, scroll the table sideways.
| Observation | What it establishes | What it does not establish |
|---|---|---|
The complete EHLO response contains STARTTLS. | The contacted service offers this upgrade. | That the handshake succeeds or the certificate is trusted. |
| A TLS handshake completes. | This connection negotiated the displayed TLS parameters. | That the client correctly checked names and the chain of trust. |
| The explicitly configured certificate verification succeeds. | The connection meets this check with this name, trust store and time. | That every other sender uses the same check or policy. |
| A timeout, connection error or incomplete EHLO response occurs. | The relevant checking stage was not conclusively observed. | That STARTTLS is absent or a message was delivered unencrypted. |
For SMTP TLS, the Email Security Check examines no more than three distinct MX hosts with the lowest numeric preference on port 25 from its checking environment. This samples inbound transport; additional equally preferred hosts and all backup preference levels remain unmeasured. The sample establishes neither all MX servers and network routes nor outgoing sending, submission or an actually delivered message. Always read a finding together with its coverage and any error status.
TLS protects each connection, not automatically the message throughout its journey. Mail servers may process and store content after receiving it. Transport TLS also does not confirm the identity in the visible From. Other mechanisms and checks address that: SPF, DKIM and DMARC.
Why offering STARTTLS alone does not prevent a downgrade
An attacker on an unprotected transport path may try to strip the STARTTLS offer. With purely opportunistic sending, the response to absent or failed TLS depends on sender configuration; fallback to plaintext may be possible. An MTA-STS policy already effectively applied in enforce mode, or successfully validated and usable DANE data, changes the supporting sender's decision. It must not simply bypass the requirements by using plaintext. The precise effect depends on policy, cache, DNSSEC and validation. MTA-STS and DNS security/DANE explain these conditions.
With a hosted mail service, the provider often operates TLS software, certificates and renewal. You still need to know the correct service, available settings and evidence. With your own server, you take on these tasks yourself or explicitly assign them to an operator.
On narrow screens, scroll the table sideways.
| Task | Clarify with the managed service | Document for your own server |
|---|---|---|
| Receiving and sending | Which hosts and directions does the provider operate? | Responsible MTA instances, listeners and outbound transport routes. |
| Protocols and algorithms | Which requirements apply, and which settings are available? | Software and TLS library versions, effective settings. |
| Certificate and renewal | Who renews and loads the certificate? | Issuer, names, renewal route and loading by the service. |
| Logs and diagnostics | Which events and reports are accessible? | Log source, time, target and the specific checking stage observed. |
Ports 25, 587 and 465 serve different purposes
On narrow screens, scroll the table sideways.
| Port | Usual role | Start of the connection | Key limit |
|---|---|---|---|
25 | SMTP transport between mail servers | SMTP, optionally upgraded with STARTTLS. | TLS requirements follow the sender's policy; this is not a submission login. |
587 | Submission from a mail client or application to the sending service | SMTP with STARTTLS. | The client and service must require TLS before actual submission if this route is to be protected. |
465 | Submission with implicit TLS | The TLS handshake starts before the SMTP conversation. | TLS must be negotiated first; the client must also verify server identity. |
Correctly implemented submission on port 587 with mandatory STARTTLS and implicit TLS on port 465 can provide comparable security. Choose according to the sending service's documented settings. The label “SSL” in a mail client often means implicit TLS and is not a recommendation to enable old SSL protocols. RFC 8314, section 3.3
Do not apply a submission service's TLS requirement indiscriminately to publicly referenced MX reception on port 25. RFC 3207 prohibits making STARTTLS a general prerequisite for local delivery there. Sender-side enforcement of a transport policy is a separate matter. RFC 3207, section 4
Schematic flows · not a measured connection
When SMTP starts under TLS
STARTTLS: SMTP first, then TLS
25 Mail server transport · 587 Submission
- TCP connection and SMTP before TLS
The server greets; the client sends
EHLO. - STARTTLS offered
The client sends
STARTTLS; the server replies220. - TLS handshake
220indicates readiness, not yet success. - If the handshake succeeds: SMTP under TLS
Send
EHLOagain; thenMAIL FROM,RCPT TOandDATAover the TLS connection.
Implicit TLS: TLS from the start
465 Submission
- TCP connection
- Immediate TLS handshake
The SMTP conversation has not started yet.
- If the handshake succeeds: SMTP under TLS
If STARTTLS is not offered or the handshake fails, the policy applied determines what follows. This does not establish automatic plaintext delivery. TLS protects this connection, not the message's entire journey.
Read the example STARTTLS exchange as a protocol transcript
Explanatory example, not a recorded test or a real message.
1 Client -> Server: TCP connection to mx.example.com:25
2 Server -> Client: 220 mx.example.com ESMTP
3 Client -> Server: EHLO client.example.net
4 Server -> Client: 250-mx.example.com
250-STARTTLS
250 SIZE 52428800
5 Client -> Server: STARTTLS
6 Server -> Client: 220 Ready to start TLS
7 Client <-> Server: TLS handshake
8 Client -> Server: EHLO client.example.net [after successful TLS handshake]
9 Client -> Server: MAIL FROM / RCPT TO / DATA [over established TLS]After the upgrade, SMTP state is reset. The client should send EHLO again and use the extensions now offered. The earlier plaintext response does not reliably describe the session after the upgrade. Likewise, a 220 response to STARTTLS indicates readiness for the handshake, not evidence of its success.
Assess the TLS version and cipher suite separately
TLS 1.3 is the current protocol generation; its current specification is RFC 9846 of July 2026. TLS 1.2 remains relevant for existing interoperability requirements. For submission and mail access, RFC 8314 and its update RFC 8997 require support for TLS 1.2 or later. This specific requirement does not apply indiscriminately to every SMTP receiver on port 25.
On narrow screens, scroll the table sideways.
| Version | Assessment |
|---|---|
| TLS 1.3 | Offer it for current services; consider the library, authentication and peers. |
| TLS 1.2 | Use suitable algorithms for existing peers where needed. |
| TLS 1.0 / 1.1 | Must no longer be negotiated under RFC 8996. |
| SSLv2 / SSLv3 | Obsolete protocols; keep them disabled for the setup described here. |
In TLS 1.3, the cipher suite specifies the AEAD algorithm and hash function. Key exchange and signature algorithms are negotiated separately. Examples of standardised TLS 1.3 suites are TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 and TLS_CHACHA20_POLY1305_SHA256. These examples are neither a complete configuration nor a BSI recommendation list. RFC 9846
For TLS 1.2, ECDHE with AEAD algorithms is a suitable starting point for configuring the particular system. Observe current standards: RFC 10015 of July 2026 prohibits, among other things, finite-field DHE and RSA key exchange in TLS 1.2. This does not prohibit RSA authentication in an ECDHE-RSA suite or concern DHE in TLS 1.3. Do not retain an old cipher string unchanged solely because it was once recommended. RFC 10015, sections 2–4
BSI TR-02102-2 contains its own dated recommendation profile. Its 2026-01 edition, for example, gives different TLS 1.3 recommendations from the protocol examples above. If you need this profile, also check groups, signatures, key lengths and applicable periods. One successful connection shows neither every offered suite nor full fulfilment of such a profile.
Certificates: which identity is checked, and how?
In PKIX-based verification, the name and chain of trust must fit the connection. For MTA-STS, the sending MTA requires, among other things, a valid PKIX chain to a root it trusts and the matching MX name in the subjectAltName extension. A displayed issuer name or Subject CN alone does not establish this. RFC 8461, section 4.2
Verification rules · not an observed result
Two separate trust models
PKIX
The client checks:
- Validity period: The certificate must be valid at the time of verification.
- Server name: The required service identity must match the permitted certificate names. For MTA-STS, this is the MX hostname in the SAN.
- Trust: An acceptable chain must lead to a locally accepted trust anchor.
- Certificates served: The server supplies the leaf certificate and required intermediates. The correct set depends on the chain, not a minimum count.
DANE-EE · Certificate Usage 3
DANE is a different trust model. With DANE-EE and Certificate Usage 3, an appropriately validated DNSSEC/TLSA combination authenticates the certificate or public key. The usual PKIX checks of CA chain, certificate name and expiry date are not required; this method explicitly excludes the expiry period from validation. This can also work with a self-signed certificate. The exception does not apply generally to every TLSA usage type or to MTA-STS. RFC 7672, section 3.1.1
A usable TLSA binding authenticated through DNSSEC must match the presented certificate or key. Do not extend this exception to DANE-TA with Usage 2.
Under usual DNS name matching, a wildcard such as *.example.com covers exactly one leftmost name level: mx.example.com, but neither example.com nor mx.eu.example.com. The relevant protocol's identity rules govern this; current general TLS rules use SAN identities rather than a CN fallback. RFC 9525, section 6
A self-signed or expired certificate therefore does not mean “equivalent to plaintext”. Negotiated encryption and the authentication actually applied are decisive. For interoperability, however, consider all intended peers and their trust models.
Targeted checking with OpenSSL
The following example uses the documented OpenSSL 3.5 options. Replace the example host with your own or an authorised service. It was not executed here.
openssl s_client -connect mx.example.com:25 -starttls smtp \
-servername mx.example.com -verify_hostname mx.example.com \
-verify_return_error -brief-servername sends SNI as a hint for certificate selection. -verify_hostname requests the specified name check. -verify_return_error makes verification errors abort the checking attempt; without it, the diagnostic tool may continue despite such errors. Also document the trust store used. This check fully reproduces neither MTA-STS with policy retrieval nor DNSSEC/DANE validation. For MTA-STS, explicitly inspect the SAN instead of inferring every protocol requirement from an OpenSSL name match. OpenSSL: s_client
Submission often uses a different hostname. Use the name given by the sending service:
openssl s_client -connect smtp.example.com:465 \
-servername smtp.example.com -verify_hostname smtp.example.com \
-verify_return_error -brief
openssl s_client -connect smtp.example.com:587 -starttls smtp \
-servername smtp.example.com -verify_hostname smtp.example.com \
-verify_return_error -briefDo not suppress error output. A timeout or a connection blocked by the local network does not prove absent TLS support. The examples demonstrate neither sign-in nor message sending.
Renew certificates automatically and load them into the service
Let's Encrypt provides publicly trusted certificates through ACME. ACME is a suitable automation route, but not a general SMTP or legal requirement. Choose a process the operator can maintain over time.
Identify the required names first. A certificate for example.com does not cover the MX mx1.example.com merely because that host receives the domain's email. Conversely, the domain itself may be the actual service name. The reference identity used is decisive.
The following Certbot example assumes a self-managed service, a suitable Certbot installation and administrative access. For standalone HTTP-01 validation, port 80 must be available locally and publicly reachable for the requested name. If that is impossible, choose a suitable documented challenge method; a DNS plugin needs its own configuration.
sudo certbot certonly --standalone --key-type ecdsa \
--cert-name mx1.example.com -d mx1.example.com \
--email admin@example.com --agree-tosReplace the example names and contact address. Check ECDSA support among intended peers; an RSA certificate may be a different compatibility choice. Certificate keys and TLS key exchange are different things.
After issuance, connect the service to the correct files: cert.pem contains the leaf certificate, chain.pem the intermediates, fullchain.pem both, and privkey.pem the private key. The key must remain protected and readable by the responsible service. The required file format and loading procedure depend on the MTA.
For an already suitably configured Postfix installation under systemd, a successful deploy hook can trigger a reload. One possible script in Certbot's /etc/letsencrypt/renewal-hooks/deploy/ directory is:
#!/bin/sh
set -eu
systemctl reload postfixInstall it with appropriate ownership and executable permissions; use it only if the service name and reload procedure fit your system. A new certificate on disk does not yet prove that the running service is serving it.
sudo certbot renew --dry-runA dry run checks the renewal route but does not run deploy hooks by default. --run-deploy-hooks can explicitly include them; after a successful dry run, Certbot uses the active certificate, not the test certificate. Check the hook's effects before using this option. Even exit status 0 from certbot renew does not alone prove new issuance or a successful reload: no certificate may simply be due for renewal yet. Certbot: usage and hooks
Operational sequence with separate checkpoints
Renewed, loaded and actually served
Request issuance in good time. Only a verified result supports the next step; each checkpoint may fail separately.
- Was a new certificate issued?
If not, investigate issuance and the need for renewal. A successful command invocation alone is insufficient.
- Are the certificate and key correctly provisioned?
Check file format, association and access permissions against the service's requirements. If not, correct provisioning.
- Has the service loaded the new certificate?
Check the intended loading procedure. A reload failure remains a separate failure even when issuance succeeded.
- Does the endpoint actually serve the new certificate?
Verify separately at the intended endpoint. The new file on disk is not yet evidence of this.
A dry run does not execute deploy hooks without an explicit option. With DANE, TLSA publication, key rollover and cache lifetimes must fit together. This is not a fixed 90-day loop.
Do not rely on a hard-coded “every 90 days” schedule. As at 13 September 2026, Let's Encrypt describes 90 days for classic, 45 days for tlsserver and 160 hours for shortlived. The announced shortening of classic provides for 64 days from 10 February 2027 and 45 days from 16 February 2028. Profiles, the ACME client and renewal scheduling must work together; the validity actually issued remains decisive. Current profiles, announced schedule
CA/B lifetimes: consider issuance date and scope
The CA/B Baseline Requirements apply to publicly trusted TLS server certificates within their scope. They are not a universal lifetime rule for every private PKI or DANE certificate. Under the current version 2.3.0, the following maximums apply to newly issued certificates:
On narrow screens, scroll the table sideways.
| Issuance date | Maximum certificate lifetime | Maximum reuse of domain/IP validation |
|---|---|---|
| Before 15 March 2026 | 398 days | 398 days |
| From 15 March 2026 | 200 days | 200 days |
| From 15 March 2027 | 100 days | 100 days |
| From 15 March 2029 | 47 days | 10 days |
Validation reuse and certificate lifetime are different periods. The stages do not retroactively shorten older certificates. A CA may issue shorter certificates, as the Let's Encrypt profiles show. Automation therefore becomes more useful operationally; this creates no mandated dependence on Certbot or ACME. CA/B Forum, sections 4.2.1 and 6.3.2
Postfix and Exim: the same task, different settings
The table maps documented configuration roles. It is not a tested configuration. Before changing anything, check the installed version, TLS library and direction: in Postfix, smtpd_ typically denotes the receiving SMTP server, while smtp_ denotes the outgoing SMTP client.
On narrow screens, scroll the table sideways.
| Task | Postfix | Exim |
|---|---|---|
| Offer STARTTLS for reception | smtpd_tls_security_level = may for the opportunistic server role. | tls_advertise_hosts; default *, with suitable TLS configuration. |
| Outbound TLS requirement | smtp_tls_security_level, with a destination-specific policy if needed. Values include none, may, encrypt, dane, dane-only, fingerprint, verify and secure; their meanings differ. | hosts_try_tls and hosts_require_tls in the SMTP transport; consider verification conditions separately. |
| Provision certificates | From 3.4, smtpd_tls_chain_files is preferred; these files contain the key, corresponding certificate and required chain in the documented order. The older approach uses smtpd_tls_cert_file. | tls_certificate, with the certificate content required by Exim or the TLS library. |
| Connect the private key | With the older file approach, smtpd_tls_key_file; with smtpd_tls_chain_files, part of the described file. | tls_privatekey; restrict access to the responsible service. |
| Cipher selection | smtpd_tls_ciphers for opportunistic TLS, smtpd_tls_mandatory_ciphers for mandatory TLS; tls_medium_cipherlist does not cover TLS 1.3. | tls_require_ciphers depends on the library; with OpenSSL it controls selection before TLS 1.3, while GnuTLS uses its priority syntax. |
| MTA-STS for sending | An external resolver can be integrated through smtp_tls_policy_maps; check interaction with DANE separately. | Current Exim documentation describes no built-in MTA-STS client. Publishing your own receiving policy is independent of this. |
| DANE for sending | smtp_tls_security_level = dane or dane-only and smtp_dns_support_level = dnssec, with working DNSSEC validation. | DANE support in the build (SUPPORT_DANE=yes) and hosts_try_dane or hosts_require_dane, with a suitable resolver. |
| TLS-RPT events and sending | Supported since 3.10; collection and report sending require additional components such as libtlsrpt, a collector and report generator. | Documentation provides events including dane:fail; this is not yet complete collection and sending of TLS-RPT reports. |
| Diagnostic logging | For example, smtpd_tls_loglevel = 1 and smtp_tls_loglevel = 1, appropriate to server and client. | TLS-related log_selector entries and, where applicable, event handling; choose a scope suited to the version. |
An encrypt value does not automatically mean full server authentication. Likewise, an MTA-STS resolver must not silently replace a working DANE decision. Primary evidence: Postfix TLS, Postfix TLS-RPT, Exim TLS.
TLS-RPT: failure reports are a different observation
An active checking attempt and a TLS-RPT report answer different questions. Wolf's DNS/SMTP check does not analyse TLS-RPT reports. TLS-RPT collects participating sending systems' information about their delivery attempts during the reporting period. A DNS record alone proves neither that these systems report nor that a report was received or analysed. An empty inbox does not prove error-free delivery.
On narrow screens, scroll the table sideways.
| Result type | What it means in the report |
|---|---|
starttls-not-supported | The reporting sender did not find the required STARTTLS support. |
certificate-host-mismatch | The name did not meet certificate verification requirements. |
certificate-expired | The certificate had expired at the time of the relevant check. |
certificate-not-trusted | The certificate could not be accepted under the trust model used. |
validation-failure | A general validation error outside the more specific types; analyse the additional reason. |
The first four types appear in RFC 8460 section 4.3.1; validation-failure is the general type from section 4.3.3. The table explains reporting terminology and is not a measurement matrix for a real system. Such an error alone does not establish an attack.
Policy errors sit alongside these: for example, tlsa-invalid, dnssec-invalid and dane-required for DANE, and sts-policy-fetch-error, sts-policy-invalid and sts-webpki-invalid for MTA-STS. In particular, sts-webpki-invalid concerns PKIX authentication during HTTPS retrieval of the MTA-STS policy, not the SMTP server's certificate chain in general. RFC 8460, section 4.3
Do not confuse REQUIRETLS with TLS-Required: No
The SMTP extension REQUIRETLS carries a requirement for onward delivery of a message. The message field TLS-Required: No, by contrast, requests that receiving-side TLS policies be bypassed for this message; available TLS should still be attempted. If both are present, the REQUIRETLS requirement takes precedence. These mechanisms depend on the participating systems and their support; an MX handshake does not test them along the whole route. RFC 8689
Postfix has supported TLS-Required: No since 3.10 and the SMTP extension since 3.11. These are different version dependencies. Do not infer a promise for an arbitrary hosted sending service. Postfix REQUIRETLS
Keep technical evidence within its limits
Document the host, port, direction, time, checking environment, trust model used and observed result. Preserve errors and unresolved checking stages as such. Logs and TLS-RPT may support an investigation but alone prove neither a particular attack nor a message's complete transport route. The section on header findings helps assess specific messages; the threat overview distinguishes sender attacks.
Legal and contractual requirements have their own scope. For example, section 30 BSIG requires covered entities to take appropriate, risk-based measures; that does not mandate one particular protocol for every organisation. BSI TR-03108 describes a specific requirements profile for email service providers, with further organisational and technical requirements. A TLS scan, certificate or cipher string is not full evidence of conformity. Section 30 BSIG, BSI TR-03108, version 2.0
Article 32 GDPR also includes encryption within appropriate, risk-based measures; it does not turn an SMTP TLS finding into blanket data protection approval. The interpretation of these German and European sources is neither approval for other markets nor evidence that a reporting obligation has been triggered. GDPR, article 32
Frequently asked questions
Does an offer of STARTTLS already mean encrypted email delivery?
No. The TLS handshake must succeed first; authentication needs separate assessment. A checking session without sending a message does not prove delivery. A timeout or incomplete response means the measurement is unresolved, not automatically that TLS is absent or plaintext was used.
Which TLS versions should a mail server offer?
TLS 1.3 is appropriate for current services; TLS 1.2 may be needed for interoperability with existing peers. RFC 8996 prohibits negotiating TLS 1.0 and 1.1. The specific minimum requirement in RFC 8314/8997 applies to submission and mail access. A single handshake does not capture a server's full version selection.
Does the new 200-day limit apply to my old certificate too?
The CA/B stage applies to publicly trusted TLS server certificates within its scope newly issued from 15 March 2026. It does not retroactively shorten previously issued certificates. The planned maximum is 100 days from 15 March 2027 and 47 days from 15 March 2029. Your issuer may already use shorter lifetimes.
Can SMTP TLS work with a self-signed certificate?
Encryption is possible. Whether server authentication succeeds depends on the trust model. MTA-STS requires a suitable PKIX check; an arbitrary self-signed certificate does not satisfy it. DANE-EE(3) can authenticate a self-signed certificate through a validated TLSA binding. These cases must not be equated.
How do I prevent renewal from interrupting mail operation?
Automate issuance in good time, check failures and connect the MTA's intended loading procedure. Then check the certificate actually served. A fixed 90-day schedule or a successful Certbot command alone is insufficient evidence. With DANE, a key change must match the TLSA binding and its cache lifetimes.
What happens if a certificate expires?
It depends on the policy applied. A sender effectively applying MTA-STS in enforce mode must not use an MX invalid in that way for delivery; later attempts may follow. With DANE-EE(3), certificate expiry is not a validation criterion. Opportunistic senders without the corresponding PKIX check may behave differently again. An error does not prove that a message was transmitted in plaintext instead.
What does the Wolf check examine here?
From its checking environment, on port 25, no more than three distinct MX hosts with the lowest numeric preference, using the checking stages stated in the result. Additional equally preferred hosts and all backup preference levels remain unmeasured. It therefore tests neither every MX and network route nor outgoing sending, submission, end-to-end encryption or a real message. Incomplete stages remain unresolved.
Sources and further guidance
The primary sources linked above were checked on 13 September 2026 for the statements identified. Further background: SMTP, RFC 5321, submission, RFC 6409, submission identity, RFC 7817, TLS 1.0/1.1, RFC 8996, update to RFC 8314, RFC 8997 and BSI TR-02102-2, edition 2026-01.
Previous chapter: MTA-STS and TLS-RPT. Next chapter: BIMI.
Use the available domain check
The free Email Security Check lets you examine your own or an authorised domain without registration. The SMTP TLS part is the described sample of no more than three distinct MX hosts with the lowest numeric preference on port 25. A sufficiently clear free finding may be enough for your next step; the entire mail route requires additional, appropriately bounded evidence.