SMTP Test Tool Guide: How to Test Any SMTP Server

What does an SMTP test actually check?

An SMTP test typically checks four 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

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. Swap in your own host and credentials.

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.

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

You should see a certificate chain, then a 250 capability list:

250-smtp.sendlayer.net
250-PIPELINING
250-SIZE 26214400
250-AUTH LOGIN PLAIN
250 8BITMIME

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

Now walk through a full send. Type each line and press Enter:

EHLO test.example.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: SMTP test

Testing from the command line.
.
QUIT

The single period on its own line ends the message body. Skip it and the session just sits there.

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.

openssl s_client -connect smtp.sendlayer.net:465 -crlf

Everything after the handshake is identical to the 587 walkthrough above.

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.

telnet mail.example.com 25

Then run the same EHLO through QUIT sequence from the openssl section.

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.

How do I authenticate during a manual SMTP test?

Base64-encode your credentials first. SMTP won’t accept plaintext usernames and passwords, which is where most manual tests die.

For AUTH PLAIN, encode both values in one string:

printf '\0%s\0%s' 'your-smtp-username' 'your-smtp-password' | base64

Paste the result after the command:

AUTH PLAIN AGpvaG5AZXhhbXBsZS5jb20AczNjcmV0
235 2.7.0 Authentication successful

For AUTH LOGIN, encode each value separately:

printf '%s' 'your-smtp-username' | base64
printf '%s' 'your-smtp-password' | base64

The server prompts twice with 334. Send the encoded username, then the encoded password.

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:

# using Homebrew
brew install swaks   

# using sudo
sudo apt install swaks  

Then test port 587 with STARTTLS and authentication:

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

For port 465, swap -tls for --tls-on-connect:

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

Swaks prints the full SMTP conversation, so you still see exactly where things break. Reading credentials from environment variables keeps them out of 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

On Windows, in PowerShell:

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

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 fails but 465 works, your network is filtering the submission port. 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 three 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. The fastest 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:

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

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. Its last commit landed in February 2024. Mailpit’s release history shows v1.30.7 shipped on August 8, 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. The classes are defined in RFC 5321, section 4.2.1.

• 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. A passing test and a delivered email then line up far more often.

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