How to Test an SMTP Server: Tools, Commands and a Full Diagnostic Workflow

Why testing the server directly matters

When email stops working, the temptation is to debug from your application's logs. Resist it. Frameworks wrap, translate, and truncate SMTP replies, so the message you read is a paraphrase of a paraphrase. The single fastest way to diagnose an email problem is to talk to the server directly and read exactly what it says.

A proper SMTP test answers five questions in order, and each one depends on the last:

1. Reachability — can you open a TCP connection to the host and port?
2. Protocol — does the server return a valid ESMTP greeting?
3. Capabilities — what does it advertise in the EHLO response?
4. Encryption — does TLS negotiate, and is the certificate valid?
5. Authentication — are your credentials accepted?

If step 1 fails, nothing about steps 2–5 matters. Working in order saves hours.

The fastest option: an online SMTP tester

For most situations a browser-based test is the quickest path. Enter the hostname, port, encryption mode and credentials, and get back the full server transcript in a few seconds — no local tooling, no firewall on your laptop confusing the result, and a readable breakdown of each stage.

This is the right tool when you want to:

• Verify a new provider's settings before writing any code.
• Confirm a credential still works after a rotation.
• Check whether a specific port is reachable from the public internet.
• Show a colleague or a support agent exactly what the server replied.

Use a dedicated test mailbox rather than production credentials whenever you can, and rotate anything you paste into a tool you do not control.

Testing with telnet

Telnet is the classic manual approach. It works only for plaintext connections, which in practice means port 25 or the pre-STARTTLS phase of 587.

telnet smtp.example.com 587

A healthy session looks like this:

220 smtp.example.com ESMTP ready
EHLO test.example.org
250-smtp.example.com
250-STARTTLS
250-AUTH LOGIN PLAIN
250-SIZE 35882577
250 8BITMIME
QUIT
221 Bye

What to look for:

• No 220 greeting — the port is blocked or nothing is listening.
• STARTTLS missing from the EHLO response — the server does not offer encryption on this port.
• AUTH missing — normal before STARTTLS on a correctly configured server; it should appear after the upgrade.

Telnet cannot complete the STARTTLS handshake, so its usefulness ends there. Note also that many systems no longer ship a telnet client; nc (netcat) works identically for this purpose.

Testing with openssl

For anything involving TLS, openssl s_client is the right tool.

Implicit TLS on port 465:

openssl s_client -connect smtp.example.com:465 -crlf

STARTTLS on port 587:

openssl s_client -starttls smtp -connect smtp.example.com:587 -crlf

Both print the certificate chain, the negotiated protocol version and cipher, then hand you an interactive SMTP session.

Read these lines carefully in the output:

Verify return code: 0 (ok)
Protocol  : TLSv1.3
Cipher    : TLS_AES_256_GCM_SHA384

A verify return code other than 0 means a certificate problem: expired, hostname mismatch, or a missing intermediate. Fix it properly — never disable verification in your application to work around it.

Testing authentication by hand

Once encrypted, you can authenticate manually. AUTH LOGIN expects Base64-encoded values:

printf 'you@example.com' | base64
printf 'your-app-password' | base64

Then in the session:

EHLO test.example.org
AUTH LOGIN
334 VXNlcm5hbWU6
<base64 username>
334 UGFzc3dvcmQ6
<base64 password>
235 2.7.0 Accepted

235 is the only success code. Anything else is a failure — see our SMTP error code reference for what each one means.

Be careful: commands typed into a terminal land in your shell history. Clear it afterwards, or use a throwaway credential.

Sending a complete test message

To verify the whole path end to end:

MAIL FROM:<you@example.com>
250 2.1.0 OK
RCPT TO:<recipient@example.org>
250 2.1.5 OK
DATA
354 Go ahead
From: You <you@example.com>
To: Recipient <recipient@example.org>
Subject: SMTP test
Date: Thu, 15 Jan 2026 10:00:00 +0000

This is a test message.
.
250 2.0.0 OK: queued as 4A2B3C

The lone dot on its own line terminates the message. The queue ID in the final 250 is worth logging — it is the only handle for tracing the message later.

Three details commonly break manual tests: SMTP requires CRLF line endings (hence -crlf in the openssl commands), a blank line must separate headers from the body, and any line in the body that begins with a dot must be escaped by doubling it.

Verifying DNS alongside the connection

A working connection is only half of a working email setup. Check the DNS side too:

dig +short MX example.com
dig +short TXT example.com                    # SPF
dig +short TXT s1._domainkey.example.com      # DKIM
dig +short TXT _dmarc.example.com             # DMARC
dig +short -x 203.0.113.20                    # reverse DNS

Reverse DNS deserves special attention for self-hosted senders. Your sending IP needs a PTR record that resolves to the hostname you present in EHLO, and that hostname must resolve forward to the same IP. Without matching forward and reverse DNS, several major providers reject your mail regardless of SPF and DKIM.

Testing from the right place

This is the mistake that wastes the most time. Your laptop and your production container have completely different network policies. A test that passes on your machine proves nothing about whether your application can send.

Always test from the environment that will actually send: the container, the VM, the CI runner, the serverless function. Cloud providers block outbound port 25 by default and corporate networks frequently filter 587 and 465 as well.

If a browser-based tester succeeds but your application fails, that discrepancy is itself the diagnosis — the server and credentials are fine, and the problem is egress filtering.

A repeatable diagnostic workflow

When email breaks, work this list in order and stop at the first failure:

1. Resolve the hostname. dig +short smtp.example.com. No answer means DNS, not SMTP.
2. Open the port. nc -vz smtp.example.com 587. A timeout means a firewall; a refusal means nothing is listening.
3. Read the greeting. No 220 within a few seconds means a middlebox is interfering.
4. Check EHLO capabilities. Confirm STARTTLS is offered.
5. Negotiate TLS with openssl and confirm verify return code 0.
6. Re-issue EHLO after the upgrade and confirm AUTH appears.
7. Authenticate and confirm a 235.
8. Send a test message and capture the queue ID.
9. Inspect the received headers in the destination mailbox for spf=pass, dkim=pass, dmarc=pass.

Change exactly one variable between attempts. Changing the port and the credentials at the same time tells you nothing about which one mattered.

Make testing continuous

One-off testing catches configuration errors. Continuous testing catches the failures that appear later without warning: a credential that expired, a certificate that lapsed, a firewall rule added during a migration, a provider that changed a hostname.

Add a synthetic check that runs hourly, authenticates against your relay, and alerts on failure. It takes an afternoon to build and it will tell you about broken email before your customers do — which is the entire difference between a minor fix and an incident.

For everything else, keep a browser tab open on SMTPTester. Paste the host, port and credentials, read the full transcript, and you will know in seconds which of the five layers actually failed.