SPF, DKIM and DMARC say who may send. They say nothing about whether the mail travels encrypted. Between two mail servers, TLS is opportunistic by default: if STARTTLS fails or a certificate is wrong, the mail goes in plain text, and nobody notices. MTA-STS and DANE turn that into a requirement. This check reads the MX records, opens an SMTP connection to up to three of them from this server, negotiates STARTTLS and reads the certificate, fetches the MTA-STS policy and the TLS-RPT record, and looks up TLSA records for DANE. No mail is sent; after the handshake the connection is closed with QUIT.
From this server: DNS queries, one request for the MTA-STS policy, and one or two SMTP connections on port 25 to each of up to three MX hosts, ending with QUIT before any envelope. MX hosts in private, loopback and link-local networks are never contacted. The query is protected by reCAPTCHA v3; the calling IP address and the domain are stored for one hour to limit the rate.
Limits worth knowing: only the first three MX hosts and one address each are tested; some hosting providers greylist or refuse unknown senders before EHLO, which shows here as unreachable while real mail still flows; whether TLS 1.0 or 1.1 would be accepted is not probed; the DNSSEC signal is the AD flag of a public resolver, not a validation done here; and MTA-STS is judged from this server's view of DNS and the policy, while a sending server may have an older policy cached.