SMTP Connectivity Test

Verify if your mail server is accepting connections on standard ports and check the speed of the initial SMTP handshake.

Evidence ASSESSED

Checked against: TCP connect and SMTP banner on port 25/587

RED TEAM 0 findings BLUE TEAM control did not hold

Importance of SMTP Health

A healthy SMTP connection is the backbone of reliable email delivery:

Latency: Slow SMTP response times can lead to "Deferred" status in remote mail queues.
Port Accessibility: Ensure ports 25, 465, or 587 are not blocked by external firewalls.
Banner Configuration: Your server should identify itself correctly in the initial connection banner to avoid being flagged as a suspicious sender.

Our SMTP Connectivity Check connects to your mail server, reads its greeting, enumerates the extensions it advertises, and confirms whether STARTTLS encryption is available — establishing whether the server is reachable and correctly configured.

What is SMTP Connectivity?

SMTP connectivity means a sending server can open a connection to your mail server and begin a conversation. It is the first requirement for receiving mail, and it fails in ways that are entirely invisible from inside your network.

A connection begins with the server sending a greeting — a 220 response naming itself. The client then issues EHLO, and the server replies with a list of supported extensions: STARTTLS for encryption, SIZE for message limits, AUTH for authentication, and others.

That exchange reveals a great deal. Whether the server answers at all, how quickly, what hostname it claims, and whether it offers encryption are all visible before any message is sent, and each is something receiving and sending servers evaluate.

The first requirement for receiving mail at all
Begins with a 220 greeting naming the server
EHLO elicits the list of supported extensions
STARTTLS availability determines whether mail can be encrypted
Failures are invisible from inside the network

Why SMTP Connectivity Matters

If sending servers cannot connect, mail is not delivered. Senders retry for several days before giving up, so the failure is silent for a long period — during which the sender believes the mail is in transit and you have no indication anything is wrong.

The greeting also matters beyond mere reachability. The hostname a server announces is compared against its reverse DNS by receiving systems, and an inconsistency is treated as a spam signal. Whether STARTTLS is offered determines whether mail arrives encrypted or in plaintext, and MTA-STS policies depend on it working correctly.

No connection means no mail delivery at all
Sending servers retry for days before generating a bounce
The announced hostname is compared against reverse DNS
STARTTLS availability determines whether mail is encrypted in transit
Connection failures give no indication from inside the network

How This SMTP Connectivity Check Works

The tool opens an SMTP connection and records the server responses.

Validates the host input against format and SSRF safety checks
Opens a TCP connection to the mail server port
Reads the greeting banner and its response code
Issues EHLO and records the advertised extensions
Confirms whether STARTTLS is offered and reports the response times

How to Use the SMTP Connectivity Check

Enter your mail server hostname, usually from your MX record
Run the check to open a connection
Confirm a 220 greeting is received
Review the advertised extensions, particularly STARTTLS
Compare the announced hostname against the reverse DNS of the address

Understanding Your SMTP Connectivity Results

Each element of the exchange carries information:

Field / Value	Meaning
`220 greeting`	The server accepted the connection and is ready. The response text normally names the server and its software, which is useful but also discloses version information.
`Announced hostname`	The name in the greeting. It should match the reverse DNS of the connecting address and have a valid forward record, since receivers check this.
`STARTTLS`	The server supports upgrading the connection to TLS. Essential — without it, mail is transmitted in plaintext and MTA-STS enforcement will fail.
`SIZE`	The maximum message size the server accepts, in bytes. Senders use this to avoid transmitting messages that will be rejected.
`AUTH`	Authentication mechanisms offered. Expected on submission ports 587 and 465. On port 25 for inbound mail it is usually unnecessary.
`Response time`	How long the greeting took. Slow greetings cause sending servers to time out and retry, delaying delivery. Under a few seconds is normal.
`421 or 554`	The server is refusing the connection — temporarily in the case of 421, permanently for 554. Often the result of rate limiting or a reputation-based block.

Common Problems & How to Fix Them

Either the mail service is not running or a firewall is blocking the port.

Check the service is listening on the host, then work outward through the host firewall and any cloud security group. Many cloud providers block outbound port 25 by default, and some block inbound until requested. Verify from outside your network, since an internal test sees a different path.

Mail to and from your server is transmitted in plaintext and can be read by anyone on the network path.

Enable STARTTLS in your mail server configuration and install a valid certificate for the hostname. Without it, any MTA-STS policy you publish will fail, and an increasing number of senders will refuse to deliver unencrypted.

Receiving servers compare the EHLO hostname against the reverse DNS of the connecting address, and treat a mismatch as a spam signal.

Make all three agree: the hostname announced in the greeting, the PTR record for the address, and the forward A record for that hostname. This trio is what receivers check.

Slow greetings cause sending servers to time out and retry, which delays delivery and can eventually cause messages to bounce.

Common causes are a reverse DNS lookup timing out during connection handling, an overloaded server, or an anti-spam mechanism deliberately delaying responses. Greylisting does this intentionally; unintentional delays are worth investigating.

The server is rejecting the connection outright, usually on reputation grounds or an explicit block.

Check whether the connecting address is blacklisted, and read the response text which frequently names the reason or links to a policy page. If your own server is issuing this, verify the blocking rules are not broader than intended.

Best Practices

Test connectivity from outside your network, since internal tests see a different path
Enable STARTTLS with a valid certificate for the announced hostname
Match the EHLO hostname to reverse DNS and to a valid forward record
Keep greeting response times under a few seconds
Monitor connectivity continuously rather than discovering failures from complaints
Verify after every firewall, certificate or infrastructure change
Use submission ports 587 or 465 for authenticated sending, not port 25

Security Recommendations

Require STARTTLS so mail is not transmitted in plaintext across the internet
Consider reducing version detail in the greeting banner, which currently advertises your software version to anyone who connects
Never offer AUTH on port 25 for inbound mail, as it invites credential attacks
Verify the server is not an open relay, which would get the address blacklisted rapidly
Deploy MTA-STS and TLS-RPT so encryption is enforced and failures are visible
Rate limit connections to resist enumeration and denial of service attempts

Frequently Asked Questions

The server accepted the connection and is ready to receive commands. It is the expected first response, and the accompanying text normally names the server and its software.

Without it, mail crosses the internet in plaintext and can be read by anyone on the network path. It is also a prerequisite for MTA-STS, and an increasing number of senders will refuse to deliver unencrypted.

Receiving servers compare the two as a basic consistency check. A mismatch suggests a misconfigured or spoofed sender and is treated as a spam signal. The hostname, its PTR record and its forward A record should all agree.

Port 25 for server-to-server mail transfer. Port 587 for authenticated submission from clients, and 465 for implicit TLS submission. Many providers block outbound port 25 from consumer and cloud networks by default.

Either the service is not running or a firewall is blocking the port. Check the service, the host firewall and any cloud security group in turn. Test from outside your network, since an internal test takes a different path.

The service is temporarily unavailable. It is commonly rate limiting, greylisting, or a temporary reputation block. Sending servers will retry, so it is not necessarily a problem — but persistent 421 responses delay delivery significantly.

Most servers do by default, and it tells anyone who connects exactly what you are running and which vulnerabilities to check. Reducing the detail is minor hardening rather than a real control, but it costs nothing.