SMTP Test Tool Guide: How to Test Any SMTP Server

What does an SMTP test actually check?

An SMTP test typically checks 4 things, and they fail in different ways. Knowing which layer broke saves you hours of guessing.

Every test walks the same path: reach the server, secure the connection, prove who you are, then hand over the message.

Here’s the part most tools skip. A passing test means the server accepted your message. It doesn’t mean anyone will see it.

Acceptance and delivery are different claims. We’ll come back to that gap at the end.

How to test SMTP from the command line

To test an SMTP server from the command line, connect with openssl, say hello with EHLO, log in with AUTH, then send a short message. Each step gets a numbered reply from the server. A 5xx reply tells you exactly which step failed.

Use openssl for ports 587 and 465, and telnet only for plain port 25. Picking the wrong one is why most manual tests fail.

The rule is simple:

• Port 587 (submission, STARTTLS): use openssl s_client -starttls smtp
• Port 465 (implicit TLS): use openssl s_client with no STARTTLS flag
• Port 25 (server to server, unencrypted): telnet works here

I’ll use SendLayer SMTP for these examples. SendLayer accepts connections on port 587 only, so its examples all use 587. Swap in your own host, port, and credentials.

Before you start: install the tools

You need a terminal and openssl. Here’s how to get it on each system:

• macOS: openssl is already installed. Open the Terminal app.
• Linux: it’s installed on most distributions. If it isn’t, run sudo apt install openssl on Debian or Ubuntu.
• Windows: Windows doesn’t include openssl. Install Git for Windows, then open Git Bash, which comes with it.

You’ll also need your SMTP username and password.

To retrieve your SMTP credentials in SendLayer, log in to your account dashboard and select the Settings sidebar menu. Then select the SMTP Credentials tab. Click Show Password to see the password, or use the copy icon next to it.

How to test SMTP with OpenSSL on port 587

Run openssl s_client with the -starttls smtp flag. It connects in plaintext, then upgrades to TLS the way a real mail client does.

openssl s_client -starttls smtp -connect smtp.sendlayer.net:587 -crlf -quiet

Here’s what each part does:

• -starttls smtp tells OpenSSL to send STARTTLS and set up the encryption for you.
• -crlf ends each line the way SMTP servers expect.
• -quiet stops OpenSSL from treating some of your lines as its own commands. Without it, OpenSSL grabs any line starting with R (like RCPT TO) or Q. Those lines never reach the server.

You’ll see a few depth= and verify return:1 lines while OpenSSL checks the certificate. You may also see one stray 250 ENHANCEDSTATUSCODES line. That’s the tail end of OpenSSL’s own hello, so you can ignore it.

Now type EHLO test.example.com and press Enter. Here’s what SendLayer’s server sent back when I tested it:

250-smtp.sendlayer.net greets test.example.com
250-SIZE 102400000
250-AUTH LOGIN PLAIN
250 ENHANCEDSTATUSCODES

That output tells you 2 useful things. TLS worked, and the server accepts AUTH LOGIN and AUTH PLAIN.

Next, log in. The server won’t take a message until you do.

How to test an SMTP server on port 465

Drop the -starttls flag. Port 465 is encrypted from the first byte, so there’s nothing to upgrade.

SendLayer doesn’t accept connections on port 465, so this example uses a placeholder host. Replace it with your provider’s server:

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

Everything after the handshake is identical to the 587 walkthrough above: EHLO, log in, then send.

How to test SMTP with telnet on port 25

Open a raw connection, then type the SMTP commands yourself. Port 25 carries no encryption, so telnet is enough.

First, make sure telnet is installed:

• macOS: Apple removed telnet, so install it with brew install telnet.
• Linux: run sudo apt install telnet on Debian or Ubuntu.
• Windows: open Command Prompt as an administrator and run dism /online /Enable-Feature /FeatureName:TelnetClient.

telnet mail.example.com 25

Then run the same EHLO through QUIT sequence from the openssl section. If telnet stops responding, press Ctrl+], then type quit and press Enter.

Port 25 is mostly for server-to-server mail now. Most ISPs and cloud hosts block outbound 25, so a failure here often isn’t your mail server’s fault.

You can do all of that manually, but there’s a faster option if you’re troubleshooting regularly.

How to test SMTP faster with swaks

Use swaks, a single command that runs the whole session for you. It handles TLS, authentication, and the message body in one line.

Install it first:

# macOS (Homebrew)
brew install swaks

# Debian or Ubuntu
sudo apt install swaks

# Fedora
sudo dnf install swaks

On Windows, install WSL with Ubuntu, then run the Debian or Ubuntu command inside it.

Next, save your credentials as variables in the same terminal window. Set the username normally. For the password, use read -s, which waits for you to paste it and doesn’t save it to your shell history:

export SENDLAYER_USER="your-smtp-username"
read -s SENDLAYER_PASS
export SENDLAYER_PASS

After the read -s line, paste your password and press Enter. Nothing shows on screen while you paste, and that’s normal.

Then test port 587 with STARTTLS and authentication. This sends a real test email, so use your own inbox for --to:

swaks --server smtp.sendlayer.net:587 \
  --tls \
  --auth-user "$SENDLAYER_USER" \
  --auth-password "$SENDLAYER_PASS" \
  --from [email protected] \
  --to [email protected]

Lines starting with ~> are what swaks sent, and lines starting with <~ are the server’s replies. A 235 after the login and a 250 after the message mean the test passed.

Want to check the login without sending anything? Add --quit-after AUTH. Swaks logs in, then disconnects before MAIL FROM.

For a server that uses port 465, swap --tls for --tls-on-connect. Set SMTP_USER and SMTP_PASS the same way first:

swaks --server smtp.example.com:465 \
  --tls-on-connect \
  --auth-user "$SMTP_USER" \
  --auth-password "$SMTP_PASS" \
  --from [email protected] \
  --to [email protected]

Swaks prints the full SMTP conversation, so you still see exactly where things break. Because read -s set the password, it never appears in the command or your shell history.

How to check if an SMTP port is open

Test the port on its own before you blame your credentials. A blocked port looks exactly like a broken mail server from inside your app.

On macOS or Linux:

nc -zv smtp.sendlayer.net 587

If the port is open, you’ll see a line like Connection to smtp.sendlayer.net port 587 [tcp/submission] succeeded!. On Linux, install nc with sudo apt install netcat-openbsd if it’s missing.

On Windows, in PowerShell:

Test-NetConnection -ComputerName smtp.sendlayer.net -Port 587

Look for TcpTestSucceeded : True at the bottom of the output.

A success means the path is clear and the problem lies further up. A timeout usually points at one of these:

• Your ISP blocks outbound port 25 on residential connections
• Your cloud provider may restrict outbound port 25. AWS, Google Cloud, and Azure all apply port 25 restrictions in at least some environments.
• A local firewall or container network rule is dropping the traffic
• The host name or port is simply wrong

If 587 times out, your network is probably filtering the submission port. Ask your host to open it.

With SendLayer, you can also send through the email API instead, which runs over port 443.

Our guide on SMTP ports covers which port to use where.

Which SMTP test tool should I use?

Pick based on where you’re testing from and whether you’re willing to hand over credentials. I checked each of these on 3 things: whether it shows the raw SMTP conversation, whether it needs your live credentials, and what it costs. I’ve grouped them by that trade-off rather than ranking them.

Short on time? Use swaks if you have terminal access and MXToolbox if you don’t.

Here’s an MXToolbox run against smtp.gmail.com. It grades every check separately, so you can see which layer failed.

Scroll past that summary and you get the full SMTP conversation. That’s where the real error text lives.

In this run, Gmail answered 530 Must issue a STARTTLS command first. It’s the same failure telnet hits on port 587.

Here’s what each one is actually good at:

• swaks. The closest thing to a complete test in one command. Runs a full authenticated send, prints the whole conversation, and never leaks credentials off your machine. Needs Perl, which most systems already have.
• openssl s_client. Already installed almost everywhere. Best for answering “does TLS work and what auth does this server support?” before you touch credentials.
• MXToolbox Diagnostics. Reach for this when you’re diagnosing a server you don’t control. It needs no credentials at all, and it checks DNS and blacklists in the same pass.
• GMass SMTP Test. Shows the exact handshake in a browser, which is genuinely useful when you have no terminal. It needs your username and password to do it.
• smtper.net. A quick one-off check. Minimal interface, no account, and it reports the raw server responses.
• Zoho ZeptoMail test. Handy presets for common providers, so you’re less likely to mistype a host or port.
• SocketLabs diagnostics. Bundles connection testing with DNS and reverse-DNS checks, which helps when the problem might be your records rather than your server.
• Mailpit. Not a diagnostic tool at all. It’s where you point your app so tests never reach a real inbox.

Three of those need live credentials. If that’s a problem, stay with the first two.

For campaign-level testing (rendering across clients, spam scoring, link checks), that’s a different job. WP Mail SMTP’s roundup of email testing tools covers that side.

Is it safe to enter my SMTP password into an online tool?

Treat it as a real risk. You’re handing working credentials to a third party, and those credentials can send mail as you.

Reduce the exposure:

• Use swaks or openssl locally when you can. That way, you send credentials directly to your SMTP provider instead of passing them through a third-party testing service.
• If you must use a web tool, rotate the password straight after the test.
• Never paste production credentials into a tool you can’t identify.
• Check whether your provider issues scoped SMTP credentials you can revoke on their own.

How to test emails without sending them to real people

To send a test email without using an actual recipient’s inbox, point your app at a local SMTP catcher. It accepts every message, sends none, and shows you the results in a web inbox.

Mailpit is the one I’d install today. If you have Docker installed, start it with one command:

docker run -d --name mailpit -p 8025:8025 -p 1025:1025 axllent/mailpit

No Docker? On macOS, run brew install mailpit, then start it with mailpit. On Linux and Windows, download the file for your system from Mailpit’s releases page and run it.

Then set your app’s mail config to localhost on port 1025, with no credentials. Open http://localhost:8025 to read what it caught.

Most roundups still recommend MailHog here, and it’s worth knowing why I don’t. MailHog’s last release was v1.0.1 in August 2020, and the last commit on its main branch landed in August 2022. Mailpit’s release history shows v1.32.0 shipped on October 22, 2026.

Both do the same job. Only one is still maintained.

Mailtrap covers the same need as a hosted service. That helps when a whole team shares one test inbox.

What do the SMTP response codes in my test mean?

Read the first digit first. It tells you whether to retry or to fix something before you read a word of the message. RFC 5321, section 4.2.1 defines the classes.

• 2xx succeeded, keep going
• 3xx the server wants more input from you
• 4xx temporary failure, retry later
• 5xx permanent failure, fix it or stop

Here are the codes you’ll actually hit while testing:

A 535 after a clean TLS handshake is almost always a credential problem, not a server problem. A 550 on a valid address usually means you don’t have permission to relay through that server.

Our guide on SMTP error codes goes deeper on each response.

My SMTP test passed, so why do emails still go to spam?

Because your test proved the server accepted the message, and nothing more. Acceptance happens in milliseconds. Filtering happens after.

A 250 response answers one question: did the server take it? Whether Gmail shows it to a human depends on things your test never touched.

Those things are:

• Authentication records. SPF, DKIM, and DMARC on your sending domain
• Domain reputation. Your history of complaints, bounces, and spam-trap hits
• Content signals. Subject lines, link quality, image-to-text balance
• List hygiene. How often you hit dead addresses

None of these show up in a command-line test. That’s not a flaw in the test; they’re simply outside what an SMTP connection can tell you.

Is mail accepted but still landing in spam? Our guide on why emails go to spam is the next stop. To confirm what happened after acceptance, see delivered vs accepted.

That’s also where a sending provider earns its keep. SendLayer sets up DNS-based authentication for you and monitors your sending reputation. That closes much of the gap between a passing test and a delivered email.

Frequently Asked Questions

These are answers to some of the most common questions we receive about SMTP testing tools.

David Ozokoye

David is a technical writer at SendLayer. He tests and documents new features and updates to SendLayer's email services. Away from the computer, he enjoys playing video games and roller skating.

See Full Bio