SMTP TLS Handshake / Mail Domain Delivery Readiness
Combines MX, bounded STARTTLS and certificate probes with optional policy and FCrDNS evidence.
Email SecurityAuditing Mail Delivery Readiness End to End
A receiving domain is ready only when every route a strict sender may choose survives the full chain from DNS to authenticated TLS. Green checks in isolation are cheap; agreement between MX, certificates, policy, and host identity is the actual control.
Adopt the sender's point of view
Start with a domain and no internal assumptions. A remote MTA resolves MX, orders the results by preference, resolves exchanger addresses, connects to port 25, reads the SMTP capabilities, and may negotiate STARTTLS. A strict sender then asks whether the certificate and any published transport policy authorize the route it selected. It does not know that mx-old is “almost retired” or that a missing certificate will be fixed next week. Published state is the contract.
Record evidence per exchanger, not as one domain-wide verdict: preference, addresses, connection result, banner, STARTTLS advertisement, negotiated protocol, certificate names and validity, MTA-STS coverage, TLSA result, and PTR/forward confirmation. Run the SMTP TLS Handshake / Mail Domain Delivery Readiness as a bounded outside-in snapshot, but keep its limit in view: it probes the first few exchangers from one network path at one moment. A production audit adds repeated observations and real sender evidence.
First gate: can DNS lead to a receiver?
Resolve the authoritative MX RRset and sort it correctly: lower preference first, equal values as alternative normal routes. Each target must be a hostname, not a CNAME, and must resolve to addresses on which you intentionally serve SMTP. Check both address families you publish. A broken AAAA is not harmless decoration; senders that try IPv6 first can experience delays or failure while IPv4-only tests stay green. Include every backup, because senders reach backups precisely during stress.
Treat DNS defects as foundational. Null MX means the domain declares that it accepts no mail; a mixed Null MX and ordinary set is incoherent. An NXDOMAIN target, stale provider hostname, or unreachable high-preference backup invalidates a route before TLS enters the picture. Capture TTLs and authoritative answers, then compare them with the intended inventory. Recursive-cache output alone can hide a partial rollout, while a single authoritative query can miss what senders still have cached.
Second gate: STARTTLS and certificate identity
Connect to every address and issue EHLO. STARTTLS must be advertised consistently and the handshake must complete with a supported protocol and cipher. More important, validate the certificate against the MX hostname selected through DNS, not merely the recipient domain. A certificate for mail.example.com does not authenticate mx.provider.net unless that provider name is also covered. Check the validity window, chain, trust anchor, and intermediates from a clean external client.
Prioritize hard connection failures, missing STARTTLS where policy requires it, and certificate name or chain failures on preferred MX hosts. These block every sender that insists on verifiable TLS for that route. Protocol cosmetics come later. Also distinguish a temporary probe failure from reproducible evidence: retest from a second path and inspect server logs before naming a cause. The goal is not a screenshot of one successful handshake, but proof that all advertised paths present the identity the next layer expects.
Third gate: policies must describe the live routes
MTA-STS adds an HTTPS-fetched policy announced by _mta-sts. In enforce mode, its mx: patterns must cover every legitimate exchanger, and those hosts must offer publicly valid TLS. Check the TXT id, the fixed policy URL, syntax, mode, max_age, and coverage together. The MTA-STS Checker/Generator compares these surfaces, but no parser can compensate for a new MX host omitted from change control.
DANE is a different trust path and a harder dependency. For SMTP, TLSA records live at names such as _25._tcp.mx1.example.net, under the exchanger hostname, and matter only with validated DNSSEC. The DANE Validator evaluates owner name, TLSA parameters, DNSSEC context, and optional certificate evidence as one binding. A stale digest after key rotation is not a warning to a validating sender; it is a reason to refuse delivery. Audit every MX host separately.
FCrDNS is a reputation check, not TLS
For each exchanger address, resolve PTR, then resolve the resulting hostname forward and confirm that it contains the original address. That is forward-confirmed reverse DNS. Keep banners and HELO names aligned with a sensible operational identity where possible. FCrDNS does not authenticate the STARTTLS certificate, and SMTP transport security does not depend on it. Mixing these conclusions produces bad remediation priorities.
It still matters. Large operators use coherent reverse identity as a reputation signal, and mismatches are common signs of rushed IP changes or generic cloud address pools. Fix missing and contradictory PTR data after route-blocking transport defects, unless a known peer is already rejecting on reputation grounds. Remember ownership: the address provider usually controls the reverse zone, while your DNS team controls forward records. A ticket closed on only one side is not a repair.
Rank findings by delivery impact and drift
Use an operational order. First: no viable MX route, connection refusal, or DNS that points nowhere. Second: STARTTLS or certificate failure on a preferred route when strict transport is expected. Third: enforced MTA-STS or authenticated DANE contradicting the live server. Fourth: defects confined to a backup or one address family. Fifth: FCrDNS and hygiene findings. Scope matters alongside severity: one broken equal-preference host can affect a large fraction of traffic even if another host is perfect.
The default failure mode is drift between layers. A migration changes MX but not MTA-STS; a renewal rotates the DANE-bound key; an IPv6 address reaches an older TLS terminator; a provider changes hostnames while PTR and monitoring keep the previous ones. Build the audit around cross-layer joins, not independent checklists. Re-run it after DNS, certificate, policy, network, or provider changes, and retain the previous matrix for comparison. A readiness verdict without a timestamp and tested host set expires quickly.