Skip to main content
Free checker - no signup required

Free SMTP TLS Checker

Test live MX server STARTTLS support, certificate validity, hostname matching, expiry, and FCrDNS so inbound mail transport does not silently downgrade.

Run the check

Enter a domain to check it live against the IntoDNS.ai engine. No signup, no trial gating.

What this SMTP TLS checker verifies

This tool resolves your MX records, connects to each mail host on port 25, and performs a live SMTP conversation. It checks whether the server advertises STARTTLS, completes the TLS handshake, and then inspects the presented certificate: whether it is publicly trusted, whether its name matches the MX hostname, how many days remain before expiry, and the negotiated TLS protocol. It also performs forward-confirmed reverse DNS (FCrDNS) on each server IP. The summary shows how many of your MX hosts pass each stage.

Why SMTP TLS matters

Opportunistic SMTP can deliver in plaintext when STARTTLS is unavailable, and can use unauthenticated TLS with an untrusted certificate. MTA-STS enforcement requires PKIX validation, including certificate name and validity checks. DANE-EE (usage 3) instead authenticates through a DNSSEC-authenticated TLSA match: it does not require a public CA, and certificate name and expiry are not checked. Test the requirements of the transport policy you actually deploy.

How to read the result

Ideally every MX host is reachable, supports STARTTLS, presents a publicly trusted certificate whose name matches the hostname, and passes FCrDNS. A host that is reachable but lacks STARTTLS is the highest-priority fix — it accepts mail in the clear. A valid-but-mismatched certificate (the name does not cover the MX hostname) will break MTA-STS in enforce mode even though plain delivery still works today. Low days-remaining on any certificate is an early warning to renew. FCrDNS failures here mirror what the FCrDNS checker reports and affect how much receivers trust your servers.

Common failure causes and fixes

Enable STARTTLS on every inbound MX host — no modern mail server should accept mail in plaintext. Install a publicly trusted certificate (Let's Encrypt is sufficient) whose subject or SAN covers the exact MX hostname, not just the web domain; a SAN/CN mismatch is the single most common reason MTA-STS enforcement breaks. Automate renewal so certificates never lapse. Ensure each mail-server IP has a PTR record that forward-confirms back to the MX hostname. Re-run this checker after any certificate or DNS change, and only switch MTA-STS to enforce once every host passes here.

The prerequisite for MTA-STS and DANE

Both MTA-STS enforcement and usable SMTP DANE policies require authenticated TLS from supporting senders, but their certificate checks differ. Use these PKIX checks before MTA-STS testing, review TLS-RPT reports, then enforce. For DANE-EE (usage 3), verify DNSSEC and the TLSA certificate or public-key match instead; a PKIX warning alone does not establish DANE failure. Authentication failures can defer delivery and eventually cause a bounce, rather than an immediate hard bounce.

What This Checks

  • MX host connection on SMTP port 25
  • STARTTLS support and handshake result
  • TLS certificate trust and expiry
  • MX hostname and certificate name match
  • PTR and forward-confirmed reverse DNS context

Common Fix Path

  • Enable STARTTLS on every inbound MX host
  • Install a publicly trusted certificate for the MX hostname
  • Fix certificate SAN/CN mismatch with the mail hostname
  • Correct PTR and forward DNS for mail-server IPs

Frequently Asked Questions

What is STARTTLS and why does it matter for SMTP?
STARTTLS is the command that upgrades a plaintext SMTP connection on port 25 to an encrypted TLS session. Because it is opportunistic, a sending server that does not see STARTTLS advertised simply delivers in the clear. If any of your MX hosts lack STARTTLS, inbound mail to that host can be intercepted or modified in transit, so enabling it on every host is essential.
Why does my certificate need to match the MX hostname?
MTA-STS requires a trusted, valid certificate covering the MX hostname. DANE-EE (usage 3) instead uses a DNSSEC-authenticated TLSA match: it does not require a public CA, and certificate name and expiry are not checked. DANE-TA (usage 2) has different validation rules, including certificate name checks.
What does FCrDNS have to do with SMTP TLS?
Forward-confirmed reverse DNS checks that each mail-server IP has a PTR record whose hostname resolves back to the same IP. Many receivers downgrade trust or reject mail from servers without it. This checker reports FCrDNS alongside TLS because both are transport-layer trust signals that affect inbound and outbound mail handling, and both are prerequisites for a clean mail setup.
Is a Let's Encrypt certificate good enough for mail servers?
Yes. Any publicly trusted certificate authority works, including Let's Encrypt, as long as the certificate covers the MX hostname and is renewed before it expires. The key requirements are public trust (so senders' default trust stores accept it) and a name that matches the MX host. Automating renewal is strongly recommended.
My mail still delivers — why fix TLS warnings?
Delivery alone does not prove authenticated encryption: opportunistic SMTP can use plaintext or unauthenticated TLS. Fix PKIX warnings before MTA-STS enforcement. For DANE, assess DNSSEC and the TLSA usage-specific checks; DANE-EE does not fail merely because a certificate name, expiry, or public CA check fails.

Machine-Readable Evidence

AI assistants and automation can cite the stable explanation page, then fetch the live check result for a specific domain.

GET https://intodns.ai/api/email/smtp-tls?domain=example.com

Related Tools and Citations

MTA-STS CheckerFCrDNS CheckerSMTP TLS report citationRun the full domain scan