How to test relays using telnet or openssl s_client?

Something seems off with your relay, and you want to know exactly what the server is doing before you send another email. Running a raw SMTP test from the command line cuts out every abstraction layer and shows you the actual conversation between your machine and the mail server.

There are two tools for this: telnet for plain connections, and openssl s_client for encrypted ones. Which one you reach for depends on whether the port uses TLS.

Plain connection with telnet (port 25)

Use this when you want to test a basic SMTP handshake with no encryption involved.

telnet mail.example.com 25

If the server is reachable, you'll get a greeting that looks like this:

220 mail.example.com ESMTP ready

That 220 means the server is alive and talking. From there, introduce yourself and walk through a delivery attempt:

EHLO yourdomain.com
MAIL FROM:<test@yourdomain.com>
RCPT TO:<recipient@example.com>
DATA
Subject: Test

Hello.
.
QUIT

Now each command gets a response code. 250 at every step means the server accepted it. A 550 on RCPT TO means the recipient was rejected (often because relaying isn't permitted for that address). A 421 anywhere means the server temporarily gave up, which is often a rate-limit or overload signal.

Encrypted connection with openssl (ports 465 and 587)

Port 465 uses implicit TLS, meaning encryption starts the moment you connect. Port 587 uses STARTTLS, meaning you connect in plain text and then upgrade. The commands are slightly different for each.

For port 465 (implicit TLS):

openssl s_client -connect mail.example.com:465

For port 587 (STARTTLS upgrade):

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

After the TLS handshake completes, you'll see the same SMTP greeting and run the same EHLO, MAIL FROM, RCPT TO sequence as above. If TLS fails to establish, openssl will tell you why (expired certificate, mismatched hostname, unsupported protocol version). That's already useful information.

What to watch for at each step

• No connection at all: the port is blocked, the server is down, or DNS isn't resolving correctly.
• 220 greeting but EHLO fails: unusual, but can indicate a misconfigured banner or a strict hostname policy.
• 550 on RCPT TO: the relay is rejecting that recipient. This is normal if the server doesn't allow open relaying, but if you're seeing it for your own domain it may point to an SPF or authentication problem.
• 530 or 535: authentication required or failed. The server wants credentials before it'll accept mail.
• 421: temporary problem, try again later. Worth noting when it appears and whether it's consistent.

Still the goal of this test is to find exactly where in the conversation the server says no. Once you know the step and the code, you know what to fix.

If you're reading SMTP response codes for the first time, our almanac has a walkthrough of full SMTP transcripts that puts all of this in context. And if something is broken right now, our SOS hotline is free.