TLS / STARTTLS checkSTARTTLS (RFC 3207) upgrades a plaintext SMTP session to encrypted transport when both sides support it. Learn more →
Inspect both your domain's outbound submission server TLS and the inbound TLS posture announced via DNS (MTA-STS + TLS-RPT). Instant, no signup, plain English.
This tool inspects two distinct TLS-related concerns. (1) **Outbound submission TLS posture** — your `smtp.<domain>` server (or whatever this domain announces via SRV) on ports 465 (SMTPS) and 587 (Submission/STARTTLS). MUA clients connect to these; we verify your cert + TLS version + cipher. (2) **Inbound MX TLS posture (announced)** — what your domain tells receiving MTAs about TLS expectations via MTA-STS (RFC 8461) policy and TLS-RPT (RFC 8460) reporting endpoint. Direct probing of receiver-MX TLS via TCP :25 / :587 / :465 is intentionally not attempted — major receiver-MX hosts firewall cloud-IP ranges across all ports as anti-spam practice; DNS-based posture inspection is the empirically-validated alternative.
Quick answer: SMTP TLS encrypts mail in transit between mail servers. This tool checks two things: (1) your outbound submission server's TLS posture on ports 465 and 587 — what your customers' mail clients negotiate when they send mail; (2) your inbound MTA-STS and TLS-RPT DNS records — what you tell other mail servers about TLS expectations when they deliver mail to you. Both matter for end-to-end transport security.
What this checksMTA-STS (RFC 8461) lets domain owners require TLS for inbound SMTP from compliant senders. Learn more →
STARTTLS is an SMTP extension defined in RFC 3207 that upgrades a plaintext SMTP session to encrypted transport when both sides support it. MTA-STS is a DNS- and HTTPS-published policy defined in RFC 8461 that lets domain owners require TLS encryption for inbound SMTP connections from compliant senders. TLS-RPT is a DNS-published reporting endpoint defined in RFC 8460 that lets receivers send daily TLS-failure reports back to the domain owner. Relaymetry first attempts to discover your submission server via SRV record (_submission._tcp.<domain> per RFC 6186) with heuristic smtp.<domain> fallback, then probes ports 465 (implicit TLS) and 587 (STARTTLS) to verify your certificate chain, TLS version, cipher, and SAN coverage. Separately, we query the apex TXT for the MTA-STS policy DNS hint, fetch the policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt, parse mode + max_age + mx patterns, and verify mx-pattern coverage of your actual MX records. We then query _smtp._tls.<domain> for the TLS-RPT TXT record.
How to read the resultTLS 1.0 and 1.1 are deprecated. TLS 1.2 is the minimum; TLS 1.3 is preferred for new deployments. Learn more →
The submission section shows the discovered submission target (from SRV or fallback), each port's negotiated TLS version (1.3 preferred, 1.2 acceptable, 1.0 / 1.1 deprecated), the certificate's subject + SAN list + expiry, and any cipher / chain warnings. A self-signed cert, an expired cert, or a SAN that does not cover the submission target are all warnings worth fixing. The MTA-STS section shows the published policy mode (enforce, testing, none, not-published), the max_age (how long compliant senders cache your policy), and the mx patterns. mode: enforce is the strongest posture — compliant senders MUST use TLS to deliver to you. mode: testing is a phased rollout — senders try TLS but fall back on failure. mode: none explicitly opts out. The TLS-RPT section shows your reporting rua endpoint (typically a mailto: or https: URL); receivers send daily JSON reports of TLS-delivery failures to that endpoint.
Common failures
No submission server discovered: neither SRV record nor smtp.<domain> resolves. If this domain does not host outbound mail (only inbound), this is fine. Otherwise add an SRV record per RFC 6186 or publish an smtp A/AAAA record. Cert SAN does not match submission target: the certificate's Subject Alternative Names list does not include the discovered submission hostname. MUA clients will refuse the connection. Re-issue the cert with the correct SAN. Cert expired: the certificate is past its notAfter date. Renew immediately. TLS version too old: TLS 1.0 and 1.1 are deprecated; modern MUAs may refuse to connect. Configure the server for TLS 1.2 minimum. MTA-STS policy mode none: the domain explicitly opts out of TLS enforcement. Switch to testing to gather data, then enforce once stable. MTA-STS published in DNS but .well-known/mta-sts.txt returns 404: the HTTPS endpoint must be reachable for compliant senders to fetch the policy. Check the web server config. MTA-STS mx pattern misses your MX: if the policy lists mx: mail.example.com but your MX is aspmx.l.google.com, compliant senders will refuse delivery. Match the patterns to your actual MX records. TLS-RPT not published: receivers cannot send you TLS-failure reports. Add a TXT record at _smtp._tls.<domain> with v=TLSRPTv1; rua=mailto:tlsrpt@<your-domain>;.
What this does not prove
We do not directly probe your inbound MX hosts on TCP 25 / 587 / 465 — major receiver-MX cloud IPs (Gmail, Outlook, etc.) firewall those ports against arbitrary scanners as anti-spam practice. The MTA-STS + TLS-RPT DNS-based check is the empirically-validated alternative. We do not test whether your submission server actually accepts authenticated SMTP submission (that requires real credentials) and do not validate that real outbound mail is being sent encrypted end-to-end. We also do not check inbound TLS-Reporting aggregate data — that requires running a TLS-RPT collector against the rua endpoint we report.
Common questions
What is the difference between TLS-RPT and MTA-STS?TLS-RPT (RFC 8460) is a DNS endpoint where receivers send daily JSON reports of TLS-delivery failures. Learn more →
MTA-STS (RFC 8461) is a policy — it tells compliant senders 'use TLS or refuse to deliver to me.' TLS-RPT (RFC 8460) is a reporting endpoint — receivers send you daily JSON reports of TLS-delivery successes and failures. They complement each other: MTA-STS prevents fallback to plaintext; TLS-RPT tells you whether anyone is hitting that fallback path.
Is MTA-STS worth it?
Yes, for any domain with significant inbound mail. MTA-STS in enforce mode prevents downgrade attacks (a man-in-the-middle stripping the STARTTLS upgrade). The cost is small — a DNS TXT record, a tiny HTTPS endpoint at mta-sts.<domain>, and the discipline to keep certificate + MX records in sync with the policy.
How do I know if my MTA-STS is enabled?
Check the result of this tool — the MTA-STS section shows the published mode (enforce / testing / none / not-published) and any policy parsing errors. If the section says not-published, no MTA-STS DNS hint exists at the apex. If it says none, you have explicitly opted out. Only enforce provides actual TLS enforcement; testing is observation-only.
What is STARTTLS for email?STARTTLS (RFC 3207) upgrades a plaintext SMTP session to encrypted transport when both sides support it. Learn more →
STARTTLS is an SMTP command that upgrades a plaintext SMTP session to encrypted transport. Per RFC 3207, the receiving server advertises STARTTLS in its EHLO response; the sending server issues STARTTLS, both sides negotiate TLS, then continue the SMTP session encrypted. Modern best practice is TLS 1.2 minimum, ideally TLS 1.3.