SMTP Test – Complete Guide to Testing Mail Server Banner, EHLO and STARTTLS

"Our mail server is up, but nobody can deliver to it" is a classic ticket. DNS looks fine, yet senders time out, fall back to plaintext or reject the server because its certificate does not match. To see what a sending server sees, you have to open an SMTP connection and look at the conversation: the greeting banner, the EHLO capabilities and whether STARTTLS actually works.

The SMTP Test does exactly that from the NetTools.tech server: one connection to port 25, 465 or 587, banner, EHLO, STARTTLS with certificate details, a second EHLO and QUIT. It never sends a message and never asks for credentials. Use it after configuring a new MX, when TLS errors appear in sender logs, or when you suspect a firewall in front of the mail server.

What is an SMTP test?

In simple terms

SMTP is the protocol mail servers use to hand messages to each other. Before any mail moves, the two servers exchange a short greeting: the receiver says who it is, the sender introduces itself, and the receiver lists what it supports, such as encryption. An SMTP test performs only this greeting and then politely hangs up, so you can see whether the server is reachable, how fast it responds and whether it can encrypt the connection.

Technical background

The relevant standards are:

• RFC 5321 (SMTP): the server sends a 220 greeting after the TCP connection; the client sends EHLO <name>; the server answers with a multi-line 250 reply listing ESMTP extensions such as SIZE, PIPELINING, 8BITMIME, STARTTLS and AUTH. QUIT ends the session with 221.
• RFC 3207 (STARTTLS): the client sends STARTTLS, the server answers 220, and a TLS handshake starts on the same connection. After that the client must send EHLO again, because the server's capabilities may change once the channel is encrypted (AUTH is often only offered after TLS).
• RFC 6409 (Message Submission): port 587, intended for mail clients submitting mail with authentication.
• RFC 8314: recommends implicit TLS on port 465 for submission, where TLS starts immediately without STARTTLS.

On the command line the same exchange looks like this:

openssl s_client -connect mail.example.com:25 -starttls smtp -crlf
openssl s_client -connect mail.example.com:465 -crlf

Why use an SMTP test?

• Inbound mail times out. See whether port 25 is reachable from the internet at all.
• TLS is missing or broken. Confirm that STARTTLS is advertised and that the handshake succeeds, and check the negotiated protocol and cipher.
• Certificate problems. See the certificate subject, issuer and expiry date and whether it matches the host name, which matters for MTA-STS.
• Slow greeting. Some servers deliberately delay the banner (greet-pause) or do slow reverse DNS lookups; the session table shows the time of every step.
• Verify a submission port. Check that 587 offers STARTTLS or that 465 speaks TLS immediately.
• Inspect advertised extensions. For example whether SIZE reports a sensible limit or whether AUTH is advertised on port 25 before TLS.

Who should use it?

• Mail administrators running Postfix, Exim, Exchange or similar servers.
• Network and firewall engineers verifying NAT and port forwarding for mail.
• MSP and help-desk staff checking a customer's mail server from outside their network.
• Security reviewers checking that mail transport is encrypted and certificates are valid.

How the SMTP test works

The NetTools.tech SMTP Test runs on the server, with strict guards around every step:

1. Validation. The input must be a public host name or a public IP address. Private, loopback and documentation addresses, and internal names such as .local, are rejected. Only ports 25, 465 and 587 are accepted.
2. MX resolution. If you entered a name (not an IP), the server looks up its MX records through the public resolvers 1.1.1.1 and 8.8.8.8. If any exist, the test switches to the MX host with the lowest priority number and marks the result as "MX of" your input. If there is no MX record, the name itself is tested.
3. Destination guard. The target host is resolved again; if any of its addresses is private or reserved, the test is refused. An IPv4 address is preferred when the host has both.
4. Per-target limit. Each mail server address may be tested at most three times in ten minutes across all users.
5. Connection. One TCP connection with a 10-second connect timeout. On port 465 a TLS handshake starts immediately (implicit TLS). Each reply must arrive within 10 seconds.
6. Conversation. Read the banner, send EHLO nettools.tech, and if STARTTLS is advertised (ports 25 and 587), send STARTTLS, perform the handshake with SNI for the host name, then send EHLO nettools.tech again. Finally send QUIT and close.
7. Certificate evaluation. The handshake does not abort on an untrusted certificate. Instead the test records the protocol, cipher, subject CN, issuer, expiry date, whether the chain is trusted and whether the certificate matches the host name.

The test never sends AUTH, MAIL FROM, RCPT TO or DATA. No relaying is attempted and no message is transmitted. The whole operation is limited to 40 seconds, and normal per-client rate and concurrency limits apply.

How to use the NetTools.tech SMTP Test

1. Open SMTP Test.
2. In Host, enter a mail server name such as mail.example.com, a public IP address, or a domain to test through its primary MX.
3. Choose the Port: 25 (default, server-to-server delivery), 587 (submission with STARTTLS) or 465 (submission with implicit TLS).
4. Press Run SMTP Test. The example chips fill in a port-25 and a port-587 test.
5. Read the server line, TLS and certificate rows, findings and the session table. Use Copy to paste the output into a ticket, or Open in terminal to run /smtp mail.example.com --port 587 in the web terminal.

Understanding the results

Every result ends with the note that no email was sent.

Example: testing an MX host on port 25

Illustrative output for a hypothetical domain example.com whose primary MX is mx1.example.com (documentation address; the real tool rejects documentation ranges, so you will see your server's public address):

Findings: "Connected to mx1.example.com (192.0.2.25) port 25; greeting after 84 ms." and "TLS TLSv1.3 with a valid certificate for mx1.example.com."

The expandable extension list would show entries such as PIPELINING, SIZE 52428800, 8BITMIME and CHUNKING. Note that STARTTLS usually disappears from the second EHLO, because TLS is already active.

Common use cases

• Verifying a new MX host before switching DNS to it.
• Checking certificate renewal on a mail server (Let's Encrypt renewals often forget to reload the MTA).
• Confirming that a submission service on 587 or 465 is reachable from the internet.
• Collecting evidence for an MTA-STS rollout: every MX must present a trusted certificate matching its name.
• Part of a domain-wide check with the Email Health Check, which runs this test against the primary MX.

Troubleshooting

"Could not connect … Connection timed out (port may be blocked or filtered)"

Nothing answered on that port. Check the firewall and NAT rules in front of the server, whether the MTA listens on the public interface, and whether your hosting provider blocks the port. Use Port Check to test reachability separately.

"Could not connect … ECONNREFUSED"

The host answered but nothing listens on the port. MX servers usually listen only on 25; submission on 587/465 is often a different host.

The test went to a different host than I typed

You entered a name that has its own MX records, so the test followed the MX with the lowest priority number. To test a specific host, enter its IP address or a host name that has no MX record.

"resolves to a private or reserved address"

At least one of the host's addresses is private (for example 10.x or 192.168.x). NetTools.tech never connects to internal networks. Check for split-horizon DNS or a wrong A record.

Certificate "does not match"

The certificate's names do not include the host name that was tested. For MX hosts, the certificate must cover the MX target name (not just the domain). Add the name to the certificate or point the MX at a name the certificate covers.

"This mail server was tested several times recently"

The per-server limit (three tests per ten minutes, across all users) was reached. Wait a few minutes.

Common mistakes

• Testing port 587 or 465 on an MX host and concluding mail is broken when the MX only listens on 25.
• Expecting the domain test to cover every MX. Only the primary MX is tested.
• Ignoring certificate warnings because mail still flows. Opportunistic TLS hides the problem until you enable MTA-STS.
• Looking for AUTH on port 25. Authentication belongs on submission ports; advertising it on 25 without TLS is a risk, not a feature.
• Typing credentials anywhere. The test needs none and never asks for them.

Limitations

• The test runs from one location, the NetTools.tech server. A firewall that allows the NetTools network but blocks others (or vice versa) gives different results for real senders.
• Only one host is tested per run: the lowest-priority MX for domains, IPv4 preferred.
• It does not test authentication, message acceptance, relaying policy, recipient validation, spam filtering or DANE/TLSA records.
• The certificate summary shows the subject CN and issuer; it does not list all SAN names or the full chain. Use the SSL Certificate Checker on port 465 for chain details.
• Servers that greet the NetTools address with a rejection may treat real senders differently.

Security & privacy

The host name or IP you enter is sent to the NetTools.tech server, which connects to the mail server; the mail server sees the NetTools.tech address and the EHLO name nettools.tech, never your IP address. The test only exchanges banner, EHLO, STARTTLS and QUIT. Results are not stored; the tool log keeps the tool name, the target and your shortened IP address for 30 days (see the privacy policy). Never enter mailbox passwords, SMTP user names or API keys: the tool does not need them and has no field for them.

Related tools

• MX Lookup – find the mail servers to test (guide).
• SSL Certificate Checker – full certificate chain on port 465 (guide).
• MTA-STS Lookup – check the policy that requires valid TLS on your MX hosts (guide).
• Port Check – test whether a TCP port is reachable (guide).
• Email Health Check – runs this test together with the DNS checks (guide).
• Email Tools overview – all email tools and workflows.

Summary

An SMTP test shows what a sending server experiences when it connects: reachability, banner, capabilities and whether TLS works with a valid certificate. The NetTools.tech SMTP Test performs exactly that conversation on port 25, 465 or 587, follows a domain to its primary MX, and stops with QUIT without sending mail or using credentials. Results reflect a single vantage point, so combine them with port and certificate checks when something looks inconsistent.