SMTP Test
SMTP Test helps you test smtp server connectivity and capabilities, for email authentication analysis, policy checks, and delivery troubleshooting.
Advertisement · Anuncio
Advertisement · Anuncio
Technical Analysis & Guide
What It Does
The SMTP test opens a raw TCP connection from our scanner to the host and port you specify (25, 465, 587 or 2525; any other value falls back to 25), waits for the first data the server sends and reports it. A reply starting with 220 is the RFC 5321 greeting and counts as a pass; anything else is flagged as unexpected. The tool reads only that opening banner: it does not send EHLO, negotiate STARTTLS, authenticate or attempt to relay mail.
Why It Matters
- →Bounce investigations: When senders report 'connection timed out' to your MX, a banner test from an outside network shows whether port 25 is listening at all.
- →Firewall and cloud changes: A new security group, NAT rule or provider migration can silently close port 25 inbound while web traffic keeps working.
- →Banner hygiene: The 220 line often names the hostname and MTA software; a hostname that does not match the PTR record is a classic spam-filter penalty.
- →Client configuration: Confirming that 587 or 465 answers on your submission host settles whether mail apps should be configured for STARTTLS or implicit TLS.
- →Load balancer health: A greeting that arrives with a 421 or 554 code instead of 220 reveals a server that is up but refusing service, often because of overload or blocklisting.
How to Read Results
- PASS with 'SMTP server reachable': The server sent a 220 greeting. The banner field holds the raw text (first 200 characters) and serverInfo the part after the code.
- smtpCode: The three-digit reply code from the greeting; 220 means ready, 421 means service temporarily unavailable, 554 means the server refuses to talk to this client.
- portType: STARTTLS for ports 25 and 587, SMTPS for 465. This label is derived from the port number; the tool does not issue the STARTTLS command, so it does not prove TLS is actually offered.
- WARN 'Our scanner network cannot reach...': Our hosting provider restricts outbound SMTP, and the packet never left our side. This is not evidence that your server is down; verify from another network.
- FAIL 'Connection refused': A host answered with a TCP reset, meaning nothing listens on that port or a firewall actively rejects it.
- FAIL 'timed out': No greeting within 10 seconds. Common causes are a silent firewall drop, a filtered path, or testing port 465, where the server waits for a TLS handshake before speaking.
Technical Background
RFC 5321 defines an SMTP session as a strict call-and-response dialogue. The server speaks first with a 220 greeting that should include its fully qualified hostname, for example 220 mx1.example.com ESMTP Postfix. The client then sends EHLO with its own name, and the server answers with a multiline 250 reply advertising extensions such as SIZE, PIPELINING, 8BITMIME, AUTH and STARTTLS. Only after that come MAIL FROM, RCPT TO and DATA. A server that is overloaded or deliberately rejecting a client can greet with 421 or 554 instead, and well-configured receivers delay or drop clients that talk before the greeting (pregreet detection).
Encryption between servers was bolted on later. RFC 3207 added the STARTTLS command: the client sends STARTTLS, the server replies 220 Ready to start TLS, both sides perform a TLS handshake on the same connection, and the client must issue EHLO again because everything learned before the upgrade is discarded. On port 25 this upgrade is opportunistic, so an attacker who strips the STARTTLS line can force plaintext. MTA-STS (RFC 8461) and DANE (RFC 7672) exist to close that gap.
The three ports have distinct jobs. Port 25 carries server-to-server relay and is where your MX must listen. Port 587 is message submission (RFC 6409), used by mail clients and applications that authenticate with AUTH after STARTTLS. Port 465 was reassigned by RFC 8314 for submission over implicit TLS, where the TLS handshake starts immediately and the SMTP greeting is sent only inside the encrypted channel; RFC 8314 now recommends implicit TLS over STARTTLS for submission. Port 2525 is an unofficial alternative some relay services offer when 587 is blocked.
Our scanner reads the greeting and stops. That design avoids sending any mail, but it has two consequences you should know. First, on port 465 the server waits for the client to start TLS, so a plain banner read usually times out even when the service is healthy; use openssl s_client to test 465. Second, the platform hosting this site restricts outbound SMTP, as many cloud providers and residential ISPs do to fight spam. When that egress block applies, the tool returns a warning saying our network cannot reach the target, which is a statement about our path, not about your server.
An open relay is an SMTP server that accepts RCPT TO for external domains from unauthenticated clients. Spammers find them within hours, and the result is blocklisting of the server's IP. Test relaying only on systems you administer, with a tool such as swaks, and expect a 554 or 550 relay-denied reply for any outside recipient when you are not authenticated.
Common Errors and How to Fix Them
- ProblemThe test times out on port 25 from a cloud VM or home connection and the admin assumes the mail server is down.
- FixMany networks block outbound 25. Repeat the test from a different network or from another mail server, and check inbound logs on the MX to see whether the connection ever arrived.
- ProblemThe banner announces localhost.localdomain or an internal name instead of the public MX hostname.
- FixSet the public FQDN in the MTA (myhostname in Postfix, smtp_banner or primary_hostname in Exim) and ensure the same name has matching A and PTR records.
- ProblemMail clients fail on port 465 because they are set to STARTTLS, or fail on 587 because they are set to SSL/TLS.
- FixUse implicit TLS (often labeled SSL/TLS) with port 465 and STARTTLS with port 587. Mixing them produces handshake errors or a client that hangs waiting for a greeting.
- ProblemSTARTTLS is advertised but the certificate is self-signed or for the wrong name, so MTA-STS enforcing senders defer mail.
- FixInstall a publicly trusted certificate whose SAN covers the MX hostname, include the full intermediate chain, and verify with openssl s_client -starttls smtp.
- ProblemThe server relays mail for any recipient because the trusted networks setting includes 0.0.0.0/0 or a NAT address.
- FixRestrict relaying to authenticated users and localhost (for Postfix, smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination) and keep mynetworks minimal.
Frequently Asked Questions
Why does the tool say your scanner cannot reach my SMTP server?
The servers that run this site sit on a hosting network that restricts outbound SMTP connections, a common anti-spam measure. When the operating system reports the network or host as unreachable, we return a warning instead of a failure because the problem is on our side. Verify your server from another network, and use the MX, SPF, DMARC and MTA-STS tools, which rely on DNS and HTTPS.
Which port should I use: 25, 587 or 465?
Port 25 is for server-to-server delivery and is where your MX hosts must listen. For mail clients and applications sending through your server, use 465 with implicit TLS, which RFC 8314 now prefers, or 587 with STARTTLS. Both require authentication. Avoid sending authenticated user mail over port 25, which many ISPs block outbound.
Does a PASS mean my server supports STARTTLS?
Not necessarily. The tool reads the 220 greeting and labels ports 25 and 587 as STARTTLS based on convention, but it never sends EHLO or STARTTLS. To confirm encryption, run openssl s_client -connect host:25 -starttls smtp and check that a certificate chain is returned, or use a mail service's message headers to see the negotiated TLS version.
How can I check whether my mail server is an open relay?
From an outside network, connect to your server without authenticating, give a sender address and then a recipient at a domain you do not host. A correctly configured server answers RCPT TO with 554 or 550 relay access denied. Tools like swaks automate this with --quit-after RCPT so no message is actually sent. Only test servers you are authorized to administer.
Why does my port 465 test time out when email clients work fine?
Port 465 uses implicit TLS: the client must start the TLS handshake before the server sends anything. Our banner test waits silently for a greeting that is only sent after encryption is established, so it times out. Test 465 with openssl s_client -connect host:465, which performs the handshake and then shows the 220 greeting inside the tunnel.
Academic Documentation
Protocol context and primary references
DMARC.org
Domain-based Message Authentication standard
Open source →
SPF Project
Sender Policy Framework documentation
Open source →
IETF
Internet Engineering Task Force
Open source →
RFC Editor
Official RFC documentation
Open source →
IANA
Internet Assigned Numbers Authority
Open source →
M3AAWG
Operational guidance for email authentication and abuse handling.
Open source →
REST API Documentation
v1.0GET /api/tools/smtp
curl -X POST https://epcybertools.com/api/tools/smtp \
-H "Content-Type: application/json" \
-d '{"host":"smtp.gmail.com","port":587}'
{
"success": true,
"results": [
{ "test": "Sample Check", "status": "pass", "message": "All clear" }
]
}
Usage Examples
# Read the greeting and see STARTTLS in the EHLO reply (type EHLO test after 220)
nc -v mx1.example.com 25
# Full STARTTLS handshake with certificate details
openssl s_client -connect mx1.example.com:25 -starttls smtp -crlf -brief
# Implicit TLS on submission port 465
openssl s_client -connect smtp.example.com:465 -crlf -brief