Inputs
Example
example.com -> MX hosts, STARTTLS banner and certificate match, MTA-STS policy alignment, TLS-RPT, optional DANE hints, and FCrDNS confirmation.
SMTP TLS Handshake / Mail Domain Delivery Readiness
Review MX, STARTTLS, certificate match, MTA-STS, TLS-RPT, and optional DANE and FCrDNS readiness evidence.
Use it to check whether a mail domain has enough SMTP transport-security evidence for delivery readiness.
One probe, the whole receiving story
When another operator asks whether your domain is ready to receive mail securely, the honest answer spans half a dozen mechanisms: MX routing, STARTTLS on the exchangers, certificates that match the right names, and — where deployed — MTA-STS, TLS-RPT, DANE, and forward-confirmed reverse DNS. Each has its own tool; delivery problems, however, arise from their combination. A valid MTA-STS policy pointing at an exchanger whose certificate does not match is two green checks and one broken deployment.
This checker runs the combination as one readiness report: it resolves effective MX targets, including RFC 5321 implicit MX when no MX RRset exists, and attempts a separate STARTTLS session to every resolved public A and AAAA address for each selected exchanger. It preserves per-address certificate evidence and — when enabled — layers strict MTA-STS WebPKI/SAN validation, TLS-RPT record validity, DANE/TLSA comparison from each address session, and canonical-IP FCrDNS round trips on top. The trust modes remain separate: a green layer never erases another layer's failure.
Layering the checks in the order senders do
Run the base check first: MX plus STARTTLS gives bounded diagnostic transport evidence. Enable MTA-STS when the question requires WebPKI chain and SAN identity proof, and enable only the other layers that are actually in scope. An absent unselected policy is not a failure: a domain without DANE is not broken, it merely has not deployed DANE, and the report keeps that distinction visible.
Read findings as a sender would experience them. A certificate mismatch on the first MX host blocks MTA-STS and other WebPKI identity checks, while DANE treatment depends on certificate usage; a missing TLSA record affects only DANE-validating senders, and a reverse-DNS mismatch mostly costs reputation points at large providers. That ordering is your priority list. After any change — new certificates, new MX hosts, a policy edit — re-run the full set, because these layers reference each other by name and drift between them is the standard failure mode.
Probe boundaries and honest scope
Live checks run only on request through guarded helpers: DNS lookups, the fixed no-redirect MTA-STS policy URL, and SMTP probes to public MX hosts on port 25 with short timeouts, limited to the first three exchangers to keep the check bounded. Within those selected exchangers, every resolved public IPv4 and IPv6 address is attempted. An unattempted address keeps coverage incomplete without inventing a STARTTLS, certificate, MTA-STS, DANE, or FCrDNS failure; an attempted address with a real protocol failure is reported as that failure. TLS-RPT validates one usable record and its destination syntax but cannot prove report delivery. The probe observes one network path at one moment and never proves end-to-end mail delivery.
Frequently asked questions
Why are the policy checks optional?
Because not every domain publishes MTA-STS, TLS-RPT, DANE, or clean FCrDNS, and their absence is a deployment status, not a defect. Making them explicit keeps a pure STARTTLS check from looking broken when a domain simply has not adopted a layer.
Does a passing STARTTLS probe prove my mail delivers securely?
No. It proves the probed host advertised and negotiated TLS on this path at this moment. Real senders may take different routes, retry differently, or enforce policies this probe did not exercise — the result is strong evidence, not a delivery guarantee.
Why must the certificate match the MX host?
MTA-STS requires a trusted WebPKI chain and a matching SAN DNS identity for the selected MX host. DANE identity requirements depend on certificate usage; a valid DANE-EE usage 3 association does not require PKIX or certificate-name validation.
What does FCrDNS add to mail readiness?
It confirms that the PTR names of your MX addresses resolve forward to the same addresses. Nothing in TLS depends on it, but large receivers use it as a reputation signal, and a mismatch is a cheap thing to fix before it costs deliverability.
How many MX hosts does the probe test?
The live helper deliberately limits probing to the first few exchangers by preference, with short timeouts. That keeps the check bounded and polite while still covering the hosts real senders would try first.
The report is green but mail still fails — where next?
Then transport is probably not your problem. Move to the authentication layer — SPF, DKIM, DMARC and their alignment — and to real evidence: message headers from a failed delivery and your TLS-RPT reports, which name failure classes this snapshot cannot see.