From a domain to a connection
For a domain the tool fetches the MX records, sorts them by priority and takes the lowest number as the host. The MX list is shown in the result with the tested host marked. If there are no MX records the domain name itself is used, which mirrors the implicit-MX rule receivers apply. The host is then resolved to IPv4 and the socket is opened to that address rather than to the name, so DNS cannot change between the check and the connection.
Hosts without an IPv4 address, or that resolve to private or reserved space, are rejected with an explanation. Each step waits up to ten seconds by default for a reply. A step that times out ends the session and appears in the findings as the session ended early, with whatever was captured before it.
What the banner and EHLO reply tell you
The greeting must start with 220; anything else stops the test. The banner text usually contains the server's hostname and sometimes its software, and it should agree with the reverse DNS of the address, which the Server details card shows next to it. The EHLO reply lists extensions, shown as pills: STARTTLS, SIZE, AUTH, PIPELINING, 8BITMIME, SMTPUTF8, CHUNKING and others.
AUTH mechanisms are extracted from the AUTH line and SIZE becomes the Max message size row in megabytes. On port 25 an AUTH offer on a connection that never gets STARTTLS is a warning, because clients would be sending credentials in clear text. After STARTTLS the extensions are re-read, since servers often advertise AUTH only inside TLS.
Encryption and the certificate
STARTTLS support on port 25 is the difference between encrypted and plain-text delivery from other servers, so its absence is a fail there and a warning on the other ports. The Encryption tile shows the negotiated protocol and cipher. TLS 1.0 and 1.1 are flagged as deprecated. On port 465 the finding reports implicit TLS.
The certificate rows show the subject common name, issuer and expiry date. Validity is judged like a strict sender would: trusted chain plus a hostname match against the MX name. Self-signed or mismatched certificates are common on MX hosts and most senders still deliver, but senders that enforce MTA-STS or DANE will not. To read every field of the certificate, paste it into the certificate decoder.
Response time, PTR and the transcript
The Response time tile is the TCP connect time. The sub-line is the whole session. The transcript prints every command (C:) and reply (S:) with the milliseconds each step took, which is the quickest way to see a slow banner (often a reverse DNS lookup on the server's side) or a slow STARTTLS handshake.
- No PTR record on the IP: many receivers reject or defer such connections; the finding warns
- Banner hostname differs from the PTR name: align them, receivers compare the two
- 450 or 421 in the transcript: the server is deferring, often greylisting or load
- STARTTLS answered with 454: TLS is advertised but not currently available
What the test cannot tell you
A successful session shows the server accepts connections and negotiates TLS. It does not show that a given mailbox exists, that the server will accept mail from you, or that your own sending IP is welcome there. Relay testing is deliberately not implemented. Outbound port 25 may be filtered on the network running the test, so a failure to connect on 25 alone is not proof the server is down.
For the sending-side picture, check the server's address with the blacklist checker and the IP reputation checker, and confirm the domain's MX and SPF records with the DNS lookup.