How do you test an SMTP server with Telnet or OpenSSL?

When mail won't send, the fastest way to find out why is to talk to the server yourself. A manual SMTP session shows exactly which step fails and what the server says, without an email client hiding the error behind "something went wrong". This guide shows the commands for every common port, what a healthy session looks like, and how to read the replies.

Which tool should you use for each SMTP port?

Use Telnet or nc (netcat) only on port 25 without encryption, and use openssl s_client for ports 587 and 465. The reason is encryption. Telnet sends and receives plain text, so it can't take part in a TLS handshake. Port 587 upgrades to TLS with the STARTTLS command, and port 465 starts TLS before any SMTP is spoken, so you need a TLS-capable client for both.

If you're not sure which port your provider expects, our guide to SMTP ports 25, 587, 465 and 2525 explains each one. If the SMTP conversation itself is new to you, what is SMTP walks through it command by command.

How do I check that an SMTP port is open?

Check reachability first, because a blocked port looks like a broken server. On Windows, run this in PowerShell:

Test-NetConnection smtp.example.com -Port 587

Microsoft Learn documents -Port as "the TCP port number on the remote computer". Look at the TcpTestSucceeded line in the output. True means a TCP connection opened. False means something between you and the server stopped it.

On macOS or Linux, use netcat:

nc -vz -w 5 smtp.example.com 587

-z scans without sending data, -v prints the result, and -w 5 gives up after 5 seconds. A message such as "succeeded" or "open" means the port is reachable.

How to read a failure:

• A timeout usually means a firewall, your ISP or your cloud host is silently dropping the traffic. Port 25 is the usual victim; see why port 25 is blocked for what to do.
• "Connection refused" means a host answered but nothing is listening on that port, or a device actively rejected it.
• A name resolution error means the host name is wrong or DNS isn't working.

To find the right host for inbound tests, look up the domain's MX records with the MX Lookup tool or nslookup -type=mx example.com. Submission hosts such as smtp.office365.com or smtp.gmail.com are not MX hosts, and MX hosts don't accept authenticated submission.

How do I test port 25 with Telnet?

Open a session to the receiving server's MX host on port 25 and type the SMTP commands one at a time. On Windows, the Telnet Client is an optional feature; Microsoft notes that "on most versions of Windows, you'll need to install the Telnet client before you can use it". On Linux, nc -C host 25 works the same way with the netcat packaged by most distributions or with Ncat, where -C sends the CRLF line endings SMTP requires; netcat versions differ (on current OpenBSD, -C means something else), so check man nc first.

Here is an example session. Lines from the server start with a three-digit code. The host names and addresses are examples.

$ telnet mx1.example.net 25
220 mx1.example.net ESMTP ready
EHLO mail.example.com
250-mx1.example.net Hello [203.0.113.10]
250-SIZE 52428800
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 SMTPUTF8
MAIL FROM:<test@example.com>
250 2.1.0 Sender OK
RCPT TO:<someone@example.net>
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
From: Test <test@example.com>
To: someone@example.net
Subject: SMTP test

This is a test message.
.
250 2.0.0 Queued as 4ABC123
QUIT
221 2.0.0 Bye

Five rules make this work:

1. Send EHLO first. RFC 5321 says "a client MUST issue HELO or EHLO before starting a mail transaction." Use a real, resolvable host name for your machine, not localhost; our guide to the HELO/EHLO hostname explains why.
2. Put angle brackets around addresses in MAIL FROM:<...> and RCPT TO:<...>.
3. Leave a blank line between the headers and the body.
4. End the message with a line containing only a period.
5. Don't use backspace. Microsoft's Telnet guide warns that "you can't use the backspace key in the Telnet session after you connect". If you mistype, press Enter and type the command again.

Read the EHLO reply carefully. It lists what the server supports. SIZE 52428800 is its maximum message size in bytes (here 50 MB), and STARTTLS means it can encrypt the session. If an MX host doesn't list STARTTLS, mail to it travels in plain text; STARTTLS and email encryption in transit covers why that matters.

Most receivers check the connecting IP against blocklists and reverse DNS before they accept anything. A test from a home connection or a new cloud server may be refused at the greeting or at RCPT TO even when the server is healthy. Microsoft's guide makes the same point: if you're testing a remote server, run the test from your mail server, because remote servers are "often set up to make sure the IP address where the SMTP connection is coming from matches the domain in the sender's email address".

How do I test port 587 with OpenSSL and STARTTLS?

Run openssl s_client with -starttls smtp, which connects in plain text, sends EHLO and STARTTLS for you, then completes the TLS handshake:

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

What each option does, from the OpenSSL documentation:

• -starttls smtp sends "the protocol-specific message(s) to switch to TLS".
• -crlf translates "a line feed from the terminal into CR+LF as required by some servers".
• -name sets the name OpenSSL uses in its own EHLO. Without it, OpenSSL uses mail.example.com.
• -connect host:port picks the server.

OpenSSL prints the certificate chain and session details. Check three things: the certificate's subject matches the host you connected to, Verify return code: 0 (ok) appears, and the protocol line shows TLS 1.2 or 1.3.

Now send EHLO again yourself. RFC 3207 says that after the handshake the client "MUST discard any knowledge obtained from the server" and "SHOULD send an EHLO command as the first command after a successful TLS negotiation". The second EHLO reply is the one that matters, because many servers only advertise AUTH once TLS is running. Here is an illustrative example; the host name, SIZE value and AUTH methods vary by provider and change over time:

EHLO mail.example.com
250-smtp.example.com at your service
250-SIZE 35882577
250-8BITMIME
250-AUTH LOGIN PLAIN XOAUTH2
250-ENHANCEDSTATUSCODES
250 SMTPUTF8

The R and Q trap in openssl s_client

In interactive mode, s_client reads a line that starts with certain letters as a command for itself, and ignores the rest of that line. The documentation lists Q to "End the current SSL connection and exit", R to "Renegotiate the SSL session (TLSv1.2 and below only)", C to reconnect, and lowercase k and uppercase K for TLS 1.3 key updates. Typing RCPT TO: is therefore taken as the R command instead of being sent to the server, and QUIT closes the connection before the server sees it.

Two fixes work:

• Type SMTP commands in lowercase: rcpt to:<someone@example.net>. RFC 5321 says verbs "are not case sensitive", so the server accepts them.
• Or add -quiet (or -ign_eof). Those shortcuts only apply "when used interactively (which means neither -quiet nor -ign_eof have been given)".

How do I test port 465 with implicit TLS?

Drop -starttls and connect straight to the TLS port:

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

The TLS handshake happens immediately, then the server sends its 220 greeting inside the encrypted session. From there, send EHLO, authenticate and continue as on 587.

If the handshake hangs or prints a protocol error, you've probably used the wrong mode for the port: -starttls smtp on 465, or no -starttls on 587. Not every provider offers 465. Microsoft Learn says Microsoft 365 client submission uses smtp.office365.com on "587 (recommended) or 25", and that a device that "recommends or defaults to TCP port 465" doesn't support the TLS versions it requires.

How do I test SMTP authentication by hand?

Use AUTH PLAIN inside a TLS session. RFC 4616 defines the PLAIN message as an optional authorization identity, a NUL byte, the username, another NUL byte and the password. Encode it with Base64 on your own machine:

printf '\0test@example.com\0YourTestPassword' | base64

Then, in the OpenSSL session, after the second EHLO:

AUTH PLAIN AHRlc3RAZXhhbXBsZS5jb20AWW91clRlc3RQYXNzd29yZA==
235 2.7.0 Accepted

That Base64 string is the encoding of the example credentials above, not a real login. A 235 reply means you're authenticated. A 535 5.7.8 means the server rejected the username, password or method. A 530 5.7.0 means you need to authenticate or start TLS first.

Treat this as a password exposure:

• Base64 is encoding, not encryption. Anyone who sees the string can decode it.
• RFC 4954 says servers should not permit plaintext password mechanisms unless STARTTLS "has been negotiated or some other mechanism that protects the session from password snooping has been provided". Never authenticate over plain Telnet.
• The printf command lands in your shell history. Use a test mailbox, and clear the history line afterwards.

Some providers no longer accept passwords at all. Gmail needs an app password for this, and Microsoft 365 is retiring Basic auth for SMTP AUTH, so a manual password test there tells you about Basic auth, not about OAuth-based apps.

What do the replies mean at each step?

Read the first digit of every reply. RFC 5321's reply codes follow the same pattern on every server: 2 means success, 3 means "go on", 4 means a temporary failure worth retrying, and 5 means a permanent failure.

A 250 after the final period matters. RFC 5321 says that by sending it, "the receiver takes full responsibility for the message". It does not mean the message reached an inbox. Filtering, quarantine and junk folders all come after that point. For any code you don't recognize, paste it into the SMTP error code lookup.

How do you run a complete SMTP test checklist?

Work from the outside in, and stop at the first step that fails:

1. Resolve the host. Confirm the MX or submission host name resolves.
2. Check the port with Test-NetConnection or nc -vz.
3. Read the greeting. A 220 means the service is up. Note the server's name.
4. Send EHLO with your server's real host name and read the extension list.
5. Start TLS with openssl s_client and check the certificate and protocol version.
6. Send EHLO again and confirm AUTH is offered (submission ports only).
7. Authenticate with a test mailbox.
8. Send a short test message to an outside mailbox you control.
9. Check the result. Open the message's headers, or send to the deliverability test, which reports SPF, DKIM, DMARC, reverse DNS and TLS for the message it receives.

If you're testing your own inbound side, run step 2 to step 4 from outside your network, for example from a cloud server, because tests from inside often take a different path. Microsoft also points to its Remote Connectivity Analyzer, whose Inbound SMTP Email test runs the same checks from the internet.

Next steps

• Save the commands that worked for your provider in your runbook, with the host, port and mode.
• If a port test times out, check whether your network or cloud host blocks it before you change any mail settings.
• If the session succeeds but mail lands in spam, the problem is authentication or reputation. Check your sending IP with the Reverse DNS (PTR) Lookup and send one message to the deliverability test.
• If you're testing because a filtering service sits in front of your mail server, iBlockSpam's setup guide for each platform explains which host should accept mail on port 25 and how to confirm it.