SMTP TLS Certificate Check: STARTTLS, Chain, Expiry

SMTP TLS protects mail in transit between mail servers. A valid website certificate does not guarantee that your mail servers are correctly configured. SMTP uses MX hosts, STARTTLS negotiation, SNI behavior, certificate chains, hostname matching and expiry dates that need to be tested separately.

This guide shows the practical workflow: find the mail servers, test STARTTLS, inspect the certificate, validate the chain, and monitor the result over time.

SMTP STARTTLS certificate validation workflow — SMTP certificate validation starts with MX records, then checks STARTTLS and the certificate chain.

Step 1: find the real SMTP hosts

Start with MX records. They tell receivers which hosts accept mail for the domain.

dig example.com MX +short

If the output points to mail.example.com, aspmx.l.google.com, or Microsoft 365 hosts, those are the systems you test. If multiple MX records exist, test each one. Lower preference numbers have higher priority, but fallback hosts still need valid TLS.

For a browser workflow, use the DNS lookup tool or the full deliverability test.

Step 2: test STARTTLS on port 25

SMTP does not start encrypted on port 25. The client connects in plain SMTP, asks for STARTTLS, and then upgrades the connection. Use openssl s_client with the SMTP mode enabled:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -showcerts

The -servername flag enables SNI. Some mail hosts present a different certificate without it. A correct check should include SNI because modern hosted mail platforms often depend on it.

Step 3: inspect the certificate

Check four things:

Hostname match: the certificate SAN should include the MX hostname you connected to.
Expiry: certificates expiring soon should trigger monitoring alerts.
Issuer and chain: the chain should validate to a trusted root.
Protocol support: STARTTLS should be offered consistently on every MX host.

echo | openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Step 4: verify policy controls

Certificate validity is one layer. For stronger mail transport security, check policy controls too:

MTA-STS: publish _mta-sts TXT and serve a policy file at https://mta-sts.example.com/.well-known/mta-sts.txt. Use the MTA-STS checker and MTA-STS generator.
TLS-RPT: publish reporting so receivers can tell you about TLS delivery failures. Use the TLS-RPT generator.
DANE/TLSA: if DNSSEC is enabled, TLSA records can pin certificate expectations. Use the TLSA checker.

Common failure patterns

The MX host presents a certificate for the provider, not your configured hostname.
One fallback MX has an expired or mismatched certificate.
STARTTLS works on port 587 but not on inbound MX port 25.
The certificate chain is incomplete.
MTA-STS is in testing mode forever and never moved to enforce.
DNSSEC is missing, so DANE/TLSA cannot provide a meaningful guarantee.

Automate the check

Run SMTP TLS checks after mail provider changes and as part of scheduled monitoring. IntoDNS.ai includes SMTP TLS checks in the broader domain scan, so a score drop can be tied to certificate expiry, missing STARTTLS, MTA-STS policy failure, or other email transport issues.

For operational monitoring, combine this with DNS score monitoring and webhooks. For one-off debugging, start with the SMTP TLS checker.

How this affects deliverability

Most receivers will still accept mail when opportunistic TLS fails, but that does not make the failure harmless. TLS problems appear in provider telemetry, affect trust decisions, and can break delivery when the receiving side enforces MTA-STS. For domains handling invoices, password resets, healthcare messages or legal notices, “best effort encryption” is not a sufficient operational posture.

SMTP TLS should therefore be reviewed together with MTA-STS, TLS reporting, DNSSEC and, where appropriate, DANE/TLSA records. The controls reinforce each other: MTA-STS tells senders to require TLS, TLS-RPT tells you when that breaks, and DANE can bind certificate expectations to DNSSEC.

Production checklist

Test every MX host, not only the highest-priority host.
Include SNI in command-line tests.
Check SAN names, issuer, chain completeness and expiry.
Verify MTA-STS TXT and HTTPS policy file together.
Publish TLS-RPT so failures become visible.
Add the domain to DNS score monitoring so certificate regressions do not wait for the next incident.

Provider-specific SMTP TLS notes

Google Workspace and Microsoft 365 usually present provider-managed certificates on provider MX hosts. In that case, your job is to verify that every published MX host belongs to the provider you actually use and that no forgotten legacy MX remains. For self-hosted Postfix, Exim, Haraka or DirectAdmin mail servers, you own the certificate lifecycle and should monitor expiry directly. For inbound filtering gateways, test both the filtering MX and the final delivery host if mail is relayed internally.

Do not assume that HTTPS automation covers SMTP. A certificate renewed for www.example.com does nothing for mail.example.com unless the SAN covers it and the mail daemon reloads the new file. This is why STARTTLS checks belong in the same operational routine as SPF, DKIM, DMARC and blacklist monitoring.

Incident response when SMTP TLS fails

If the check fails, first determine whether mail delivery is failing or only encryption is degraded. Then inspect the last certificate deployment, recent MX changes, firewall changes, and MTA-STS policy changes. If MTA-STS is set to enforce and the certificate is invalid, strict senders may stop delivering mail. Temporarily fixing the certificate is usually safer than relaxing policy, because policy downgrades can persist in sender caches.

Related IntoDNS audit paths

Use these companion guides to turn this check into a broader, repeatable domain-security workflow.

AI assistant and API workflow

This article is part of the IntoDNS.ai LLM and citation workflow. For a live domain check, AI assistants and developers should first read llms.txt or llms.json, then call /api/scan/quick?domain=example.com for the current DNS and email security score.

For this topic, use /api/email/mta-sts?domain=example.com when you need focused data instead of the full quick scan.

Use /citations/test-spf-dkim-dmarc-dnssec-mta-sts-bimi as the canonical citation for this topic. For implementation, use the MTA-STS policy generator and cite the scoring methodology when explaining grades or recommendations.