STARTTLS Checker
Enter a domain and choose port 25, 587 or 465. The tool opens a TLS session to the mail hosts and reports STARTTLS support, the negotiated protocol and certificate validity.
Run STARTTLS and certificate check
No sign-up required. Public hosts and addresses only; results show what was observed, nothing is simulated.
What this check tests
STARTTLS is a command that upgrades an existing plaintext SMTP connection to TLS (RFC 3207). Port 25 and the submission port 587 use it; port 465 uses implicit TLS, where the handshake happens immediately. This tool connects to up to three MX hosts on the selected port, requests the upgrade where applicable, completes the handshake and examines what the server presented.
It reports whether STARTTLS was offered, the negotiated TLS version, whether the certificate validates for the MX host name from your MX record against this server's trusted root store, how many days remain before expiry, and the RSA key size.
STARTTLS, MTA-STS and DANE are different things
Encryption support is only one layer. On port 25, mail servers normally use opportunistic TLS: they encrypt if the other side offers it, and most do not insist on a trusted certificate. An attacker who can modify traffic can remove the STARTTLS offer, and the sender will often carry on in plaintext.
MTA-STS (RFC 8461) lets a domain publish a policy that tells compatible senders to require TLS with a certificate valid for the MX name. DANE (RFC 7672) achieves a similar goal by publishing certificate data in DNSSEC-signed TLSA records. This tool tests the servers themselves. It does not evaluate DANE, and MTA-STS enforcement is checked by the MTA-STS tool. A pass here does not mean that senders are required to use TLS.
How to read the result
When STARTTLS is not offered on port 25 the finding is a risk: the connection is unencrypted. On 587 it is an improvement item. A certificate result of 'validates' means the chain reaches a trusted root and the name matches the MX host name; it says nothing about how a sender with a different trust store would judge it. Certificates expiring within 14 days are flagged, as are RSA keys under 2048 bits.
The protocol finding passes when TLS 1.2 or 1.3 is negotiated. The scanner requires TLS 1.2 or newer, so a server that supports only older versions appears as a handshake error, and older-version support is not probed otherwise.
Common problems
- Certificate name mismatch. The certificate covers the web name but not the MX host name. This matters most for MTA-STS enforcement.
- Expired certificate. Opportunistic senders may still deliver, but enforcing senders refuse.
- Incomplete chain. The server sends only the leaf certificate; some validators then fail.
- Self-signed certificate. Acceptable to many opportunistic senders, rejected by enforcing ones.
- Port closed on 587 or 465. Normal for an inbound mail host that does not offer submission.
- Several MX hosts with different certificates. One neglected host can fail validation while the others pass.
How to fix safely
Prerequisites: control of the mail server or provider portal, a certificate that lists each MX host name, and automated renewal. Operational risk: a bad TLS configuration can make servers refuse connections from some senders; changing certificates on a live mail server briefly restarts services. Rollback: keep the old certificate and configuration, and reload one host at a time.
- Obtain a certificate whose subject alternative names include every MX host name.
- Install it on one MX host and run this test against the domain to see that host's result.
- Enable TLS 1.2 and 1.3 and make sure the full chain is sent.
- Repeat on the remaining hosts.
- Only after all hosts validate, consider publishing MTA-STS in testing mode.
Limits
The test is a single probe from one network position. It judges trust with this server's CA store, so a private CA that your partners trust would still fail here. Only three hosts are tested. The tool cannot see whether senders actually use TLS to you, which is what TLS-RPT reports are for. Where outbound port 25 is blocked from the scanner, the result is unknown and says nothing about your servers.
Frequently asked questions
Is STARTTLS the same as MTA-STS?
No. STARTTLS lets a connection be encrypted. MTA-STS is a published policy that tells senders to require validated TLS.
Does the tool test DANE?
No. DANE uses DNSSEC-signed TLSA records and is not evaluated here.
Why does a self-signed certificate show as an issue?
The scanner validates against trusted roots. Many senders accept it opportunistically, but enforcing policies do not.
Which port should I test?
Port 25 for receiving mail from other servers. Use 587 or 465 for submission by your own users, if you run those services.
Can I tell if a message was encrypted in transit?
Not from this tool. Look at the Received headers of the message or TLS-RPT reports.
Why was nothing tested?
Either the domain has no mail hosts (or publishes null MX), or outbound connections from the scanner were blocked.
Written by DNS Tools editorial · Last updated 2026-10-09