Why port 25 so often just times out

Outbound connections on TCP port 25 are blocked by default on most major cloud providers — AWS, GCP, Azure, and the Oracle Cloud instance this site runs on among them — specifically to stop compromised instances from being used as spam relays. That policy applies to this site's own outbound connections the same way it applies to anyone else's cloud instance, which means a perfectly healthy, reachable mail server can still time out here on port 25 for a reason that has nothing to do with that server's health. Testing port 587 (the standard mail submission port, which isn't subject to the same blanket blocking) is the way to distinguish "the target is actually down" from "port 25 egress is blocked from wherever this request originates" — and that distinction matters whether you're troubleshooting from this tool or from any other cloud-hosted vantage point.

What "reads the banner" means, and what it deliberately doesn't do

This tool opens a plain TCP connection, reads the server's initial greeting banner, sends EHLO, and reports whatever capabilities the server advertises back — including whether STARTTLS is offered. It stops there: it never actually performs the STARTTLS upgrade or exchanges any mail. That's a deliberate scope boundary, not a missing feature — the banner and capability list alone already answer the most common troubleshooting questions (is the server up, does it identify itself correctly, does it support the extensions a mail client would need), without needing to actually negotiate TLS or attempt a real delivery.