SMTP Banner Probe — What Your Mail Server Announces
This connects to a mail server the way a sending server would, captures the greeting banner, asks what capabilities it advertises, and tests whether encryption can be negotiated. It is the difference between knowing a mail host is reachable and knowing it will actually accept a message.
Why run it
A mail server can be listening and still be unable to receive mail: TLS misconfigured so encrypted delivery fails, authentication mechanisms advertised that do not work, a banner identifying the wrong hostname in a way that trips reverse-lookup checks on the receiving side. The capability list is also a small security review — an open relay or an unexpected authentication mechanism shows up here and nowhere else you routinely look.
Why automate it
Mail servers are patched and restarted like anything else, and TLS configuration is the part most likely to change underneath you as packages update defaults. A server that has been quietly failing to negotiate encryption since a patch three weeks ago is still accepting mail, so nothing alerts — you have simply been delivering in the clear, or having encrypted delivery attempts fall back. Probing on a schedule catches configuration regressions that leave the service technically up and functionally degraded.
What it gives you
Confirmation that a mail server will actually complete a delivery conversation, not merely answer the phone. It covers the gap between a port being open and mail being accepted, where a surprising number of delivery problems live.