dotvitals

Mail server does not offer STARTTLS

HighConfirmedemail.smtp-tls.no-starttls

What this check looks for

Your mail server does not offer encryption, so mail sent to this domain crosses the internet in plain text where anyone on the path can read it.

Why it matters

Every message and every attachment is readable in transit, including password resets and invoices. Gmail, Outlook and others mark such mail as unencrypted to the sender, and a sender with MTA-STS or a TLS-required policy will refuse to deliver at all.

When the check passes, your report says: “The mail server offers STARTTLS, so mail arrives encrypted”.

What it costs your score

When this check fails it removes 25 points from your Email transport score, before the status, confidence and repeat multipliers are applied. Email transport carries a weight of 8 in the overall score.

It shares the email-transport.smtp-tls family ceiling of 40 points: however many findings that family produces, together they cannot remove more than that from Email transport. One underlying problem showing up in several places is still one problem.

Severity
high
Default confidence
confirmed
Status when triggered
fail
Deduction
25 points
Family cap
email-transport.smtp-tls · 40
Category
Email transport
Module
Email smtp tls
Fix owned by
mail provider
In the ruleset since
2026.09

How the whole score is calculated

How to fix it

Enable STARTTLS on ‹mx host› with a certificate valid for that hostname.

Without it, mail to this domain is transmitted in clear text and enforcing senders will not deliver at all.

  1. Obtain a certificate covering ‹mx host› — a free ACME certificate is sufficient and is what most mail servers use.

  2. Point your MTA at it: Postfix smtpd_tls_cert_file / smtpd_tls_key_file with smtpd_tls_security_level = may; Exim tls_certificate / tls_privatekey.

  3. Reload the mail server and confirm the greeting now advertises STARTTLS.

  4. Renew automatically — an expired certificate here breaks delivery from enforcing senders.

How to confirm it worked

  • openssl s_client -starttls smtp -connect ‹mx host›:25 -servername ‹mx host› — expect a completed handshake.

  • Re-run this check and confirm STARTTLS is now offered.

The configuration to publish
# Postfix (main.cf)
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/{{mxHost}}/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/{{mxHost}}/privkey.pem
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_protocols = >=TLSv1.2

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

Postfix
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/‹mx host›/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/‹mx host›/privkey.pem
smtpd_tls_mandatory_protocols = >=TLSv1.2
Exim
tls_advertise_hosts = *
tls_certificate = /etc/letsencrypt/live/‹mx host›/fullchain.pem
tls_privatekey = /etc/letsencrypt/live/‹mx host›/privkey.pem
tls_require_ciphers = NORMAL:-VERS-ALL:+VERS-TLS1.2:+VERS-TLS1.3
Technical detail

‹mx host› answered EHLO with ‹ehlo keywords› and did not advertise the STARTTLS keyword defined by RFC 3207 §2. Opportunistic TLS is therefore impossible, and a sender enforcing an MTA-STS policy (RFC 8461 §4.1) will treat delivery to this host as failed rather than fall back to plaintext.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the email smtp tls checker

Other email smtp tls checks