SMTP Monitoring: Mail Server Reachability, Banners, and Delivery Checks
SMTP monitoring helps you verify that a mail server is reachable and actually speaks the protocol clients and peer servers expect. If email matters to your product, it is not enough that TCP port 25 or 587 is open. You also want to know whether the mail service is responding correctly and ready to continue the SMTP conversation.
What SMTP monitoring actually validates
SMTP monitoring checks whether a mail server accepts a connection and responds like a real SMTP service. That often includes confirming the initial 220 banner and that the server can continue the handshake sequence when a client sends commands such as EHLO.
This is important because an open TCP port alone does not prove the mail system is healthy. A service may still be misconfigured, overloaded, filtering unexpectedly, or failing at the protocol layer even when the port accepts connections.
When teams monitor SMTP
Email delivery is business-critical
Password resets, alerts, invoices, onboarding emails, and transactional messages all depend on working SMTP infrastructure somewhere in the chain.
A mail server must do more than just listen
You want confidence that the SMTP process answers correctly, not just that the port is technically reachable.
You need early warning for silent mail issues
Mail failures can be easy to miss until support tickets arrive, especially if queues back up or only some servers fail.
You run self-hosted or hybrid mail infrastructure
Custom SMTP setups, relays, and mixed cloud/on-prem mail paths benefit from active checks that confirm the service is speaking SMTP where it should.
How a basic SMTP handshake works
The client connects to the SMTP port
That usually means TCP 25 for server-to-server transfer or TCP 587 for authenticated client submission.
The server sends a 220 banner
A healthy SMTP server typically begins by identifying itself with a 220 response that shows it is ready to continue.
The client sends EHLO or HELO
This starts the SMTP session and allows the server to advertise capabilities and proceed with the conversation.
Protocol-aware checks prove more than port reachability
If the server never returns the expected banner or does not continue correctly, the service may be unhealthy even though the TCP port itself is open.
How to read common SMTP signals
SMTP troubleshooting often revolves around protocol replies such as these:
220 mail.example.com ESMTP ready 250 OK 250-STARTTLS 421 Service not available 450 Requested action not taken 550 Requested action not taken: mailbox unavailable
220 banner
This is the classic sign that the SMTP server is ready to begin a session after the TCP connection opens.
250 responses
These usually indicate that the previous command was accepted and the conversation can continue.
4xx temporary failures
These often signal temporary problems such as overload, throttling, or unavailable dependencies.
5xx permanent failures
These usually indicate a harder failure or policy rejection rather than a temporary retry situation.
Why SMTP needs more than a port check
A mail server can expose TCP 25 and still fail to return the right SMTP banner or continue the protocol correctly. That creates real delivery risk even though a simple port check might look healthy.
Protocol-aware SMTP monitoring gives you a better signal because it confirms that the service is acting like an SMTP server, not just that something is listening on the port.
SMTP monitoring vs TCP port monitoring
| Topic | SMTP check | TCP port check |
|---|---|---|
| Primary question | Does the mail service respond like SMTP and continue the handshake? | Is the port reachable and accepting a TCP connection? |
| Best for | Mail server behavior, banner validation, and application-level email service health. | Basic listener availability on port 25, 465, or 587. |
| What it can miss | It may still not prove full end-to-end inbox delivery behavior on its own. | It cannot prove that the service actually speaks SMTP correctly after connect. |
Need the transport-layer basics behind SMTP too?
SMTP depends on TCP port connectivity before the protocol conversation can begin, so TCP port monitoring is still a useful foundation underneath mail checks.
Read the TCP and UDP guide βHow to interpret common scenarios
TCP 25 is open, but no 220 banner appears
Something is listening, but the SMTP service may be hung, misconfigured, filtered, or not actually behaving like a healthy mail server.
The banner appears, but later commands fail
The listener is alive, but the application may still have protocol, auth, policy, or backend problems deeper in the session.
Mail delays appear intermittently
Temporary 4xx-style behavior can point to throttling, queue pressure, dependency issues, or overloaded infrastructure.
A submission port works, but incoming relay does not
TCP 587 and TCP 25 serve different roles, so checking the correct SMTP endpoint matters when diagnosing delivery paths.
Important limitations
- β SMTP monitoring does not automatically prove end-to-end inbox delivery or spam acceptance by every remote provider.
- β A healthy SMTP handshake does not guarantee that downstream mail queues, relays, or recipient policies are healthy.
- β Different ports such as 25, 465, and 587 serve different purposes and may need separate checks.
- β Mail systems often involve multiple layers, so one passing endpoint does not prove the whole mail flow is healthy.
How people test SMTP manually
telnet mail.example.com 25 Useful for seeing whether the server answers with the expected 220 SMTP banner after connect.
nc -vz mail.example.com 25 A quick way to test basic TCP reachability before deeper SMTP protocol checks.
openssl s_client -starttls smtp -connect mail.example.com:587 Helpful when you need to inspect SMTP over TLS behavior on submission endpoints.
Frequently asked questions
An open mail port is not the same as a healthy mail service.
nsmon helps you monitor SMTP endpoints so you can see when a mail server stops responding correctly before password resets, alerts, or transactional email start failing in production. Create a free account to monitor the SMTP services your business depends on.