What Is SMTP Testing? Everything You Need to Know

You configured your mail server. The credentials look right. The DNS records are in place. But emails aren't arriving — and you have no idea which layer is failing.

SMTP testing answers that question. Instead of guessing, you test each layer of the sending path directly and watch exactly where things break.

This guide covers the four essential SMTP tests — connection, authentication, port, and TLS — what each one tells you, how to run it, and what the results actually mean.

In this guide:

• What Is SMTP Testing?
• SMTP Connection Testing
• SMTP Authentication Testing
• SMTP Port Testing
• SMTP TLS Testing
• How to Run a Complete SMTP Test
• Common SMTP Response Codes
• When SMTP Testing Isn't Enough

What Is SMTP Testing?

SMTP (Simple Mail Transfer Protocol) is the protocol that moves email from your application to a mail server, and between mail servers across the internet. Every email you've ever sent rode SMTP at some point in its journey.

SMTP testing is the practice of sending diagnostic commands to a mail server to verify that each stage of the sending process works — before you depend on it in production.

Think of it like checking the plumbing in a new house. You don't assume the whole system works because water comes out of one tap. You turn every valve separately, find the leak, then fix it. SMTP testing does the same for your email pipeline, one layer at a time:

• Connection testing — can you reach the server at all?
• Authentication testing — do your credentials actually work?
• Port testing — are you talking on the right channel?
• TLS testing — is the conversation encrypted?

What SMTP testing does not tell you is where your email lands after the server accepts it. That's a different discipline — deliverability testing — and we'll cover the distinction at the end of this guide.

SMTP Connection Testing

The most fundamental test: can you reach the mail server, and does it actually speak SMTP?

When a client connects to an SMTP server, the server responds with a 220 banner announcing itself. The client then introduces itself with EHLO, and the server replies with its capabilities. A healthy connection test looks like this:

$ telnet smtp.yourprovider.com 587
Trying 203.0.113.10...
Connected to smtp.yourprovider.com.
220 smtp.yourprovider.com ESMTP ready
EHLO yourdomain.com
250-smtp.yourprovider.com
250-AUTH LOGIN PLAIN
250-STARTTLS
250-SIZE 52428800
250 OK

Three things to verify in that exchange:

• The 220 banner appears. No banner means you're connected to something that isn't an SMTP server — or a firewall is intercepting the connection.
• The server accepts EHLO. A 250 response confirms the server is willing to talk to you.
• The capability list makes sense. AUTH and STARTTLS should both be present on a modern submission server.

Common connection failures and what they mean:

• Connection timed out — a firewall (yours or theirs) is dropping the traffic, or the hostname is wrong. Check DNS first: dig MX yourdomain.com tells you which servers should accept mail for a domain.
• Connection refused — the host is reachable, but nothing is listening on that port. Either the service is down or you have the wrong port (see port testing below).
• Connection closed immediately — the server doesn't like your IP. Some providers drop connections from IPs with poor reputation before the banner.

Connection testing confirms a server exists and responds. It says nothing yet about whether you can actually send through it.

SMTP Authentication Testing

Authentication testing verifies that your username and password actually work — before your application fails at 2 AM with a queue full of undelivered mail.

SMTP authentication happens through the AUTH command, most commonly with the LOGIN or PLAIN mechanisms. Credentials are base64-encoded (note: encoded, not encrypted — more on that in the TLS section). A successful exchange looks like:

AUTH LOGIN
334 VXNlcm5hbWU6
bXl1c2VyQGV4YW1wbGUuY29t
334 UGFzc3dvcmQ6
bXlwYXNzd29yZA==
235 2.7.0 Authentication successful

Those cryptic 334 lines are simply base64 for Username: and Password:. The server is prompting you, one field at a time. The response you care about is the last one:

• 235 — authentication succeeded. Credentials are valid.
• 535 — authentication failed. Credentials were rejected.

A 535 doesn't always mean a wrong password. The usual suspects:

• App passwords required. Gmail rejects your account password outright if 2FA is enabled — you need a generated app password instead.
• Basic auth disabled. Microsoft 365 has been retiring basic authentication in favor of OAuth2. A perfectly valid password fails with basic auth if the tenant requires modern auth.
• IP restrictions. Some providers only accept authentication from allow-listed IP ranges.
• Wrong username format. Some servers want the full email address, others just the local part, others a separate login entirely.

Testing authentication manually is fiddly (you'll be base64-encoding credentials by hand). This is where a purpose-built tool earns its keep — more on that in the workflow section.

SMTP Port Testing

SMTP runs on several ports, and they are not interchangeable. Talking to the wrong port is one of the most common reasons email fails silently in new environments.

The rule of thumb: applications submit on 587 (or 465); servers relay on 25.

Port testing answers two questions: is the port open, and does the expected service answer on it? A port can be "open" at the firewall level while a completely different service listens behind it — which is why a real SMTP greeting (from connection testing) matters more than a bare TCP handshake.

The classic trap: an application configured to send on port 25 from a cloud VPS. AWS, Google Cloud, and Azure all restrict or block outbound port 25 by default to combat spam. Your code doesn't error — the packets just vanish. Five minutes of port testing before deployment beats a day of debugging after.

SMTP TLS Testing

TLS testing verifies that your SMTP conversation is actually encrypted — and this matters more than most teams realize, because base64-encoded credentials are not encrypted credentials. Without TLS, anyone on the network path can read your username, password, and message content in transit.

SMTP supports two encryption models:

• STARTTLS (ports 25, 587) — the connection starts in plaintext, then the client issues STARTTLS to upgrade it to TLS before authenticating.
• Implicit TLS (port 465) — the connection is encrypted from the very first byte. No plaintext phase at all.

You can test the TLS handshake directly with OpenSSL:

$ openssl s_client -starttls smtp -connect smtp.yourprovider.com:587 -servername smtp.yourprovider.com

What to verify in the output:

• Verify return code: 0 (ok) — the certificate chain is trusted. Anything else means a certificate problem: expired, self-signed, wrong hostname, or an incomplete chain.
• Protocol version — TLS 1.2 is the practical minimum in 2026. TLS 1.0 and 1.1 are deprecated and increasingly refused.
• Certificate hostname — the CN/SAN must match the hostname you're connecting to (that's what the -servername flag tests).

One subtle failure mode deserves attention: opportunistic TLS. If a server offers STARTTLS but the upgrade fails (broken certificate, unsupported cipher), many clients silently fall back to plaintext and send anyway. Your connection test passes. Your auth test passes. And your credentials just crossed the network unencrypted. TLS testing is the only way to catch this — which is also why MTA-STS exists for enforcing TLS on inbound mail to your own domain.

How to Run a Complete SMTP Test

A full SMTP test runs the four layers in sequence, because each one depends on the last:

1. DNS lookup. Find the right server: dig MX yourdomain.com for inbound, or confirm your provider's submission hostname for outbound.
2. Port test. Verify your candidate ports (587, 465, 25) are open and reachable from the environment that will actually send — not just from your laptop.
3. Connection test. Confirm the 220 banner and a successful EHLO.
4. TLS test. Verify the certificate, protocol version, and that the STARTTLS upgrade succeeds before any credentials are sent.
5. Authentication test. Log in with the real credentials and look for 235.
6. End-to-end send. Relay an actual message and confirm it arrives — and where it lands.

For manual testing, swaks (Swiss Army Knife for SMTP) is the standard tool — it handles TLS negotiation and auth encoding for you in one command:

$ swaks --to test@example.com --server smtp.yourprovider.com:587 --tls --auth-user you@yourdomain.com

Manual tools work, but they test from wherever you run them. If your production app sends from a different network (a cloud VPC, a Kubernetes cluster, a serverless function), a passing test from your laptop proves nothing about production. Test from the environment that actually sends — or use a tool that tests from outside your network entirely.

Common SMTP Response Codes

SMTP servers communicate almost entirely through three-digit codes. These are the ones you'll see most while testing:

The pattern worth remembering: 2xx means continue, 4xx means retry later, 5xx means stop and fix something.

When SMTP Testing Isn't Enough

Here's the uncomfortable truth: a perfect SMTP test only proves your server can send. It says nothing about where your messages land after the receiving server accepts them.

That 250 OK from Gmail's servers means they took the message. It does not mean the message reached the inbox. Between acceptance and inbox sits an entire filtration pipeline — reputation scoring, SPF/DKIM/DMARC alignment, engagement history, content analysis — that SMTP testing never touches. We break down exactly how that pipeline works in How Email Servers Decide Whether Your Message Reaches the Inbox.

The confusion between "delivered" and "in the inbox" is the most expensive misunderstanding in email. A message can be accepted with a 250 and still land in spam — or be silently discarded. That's the difference between delivery and deliverability, covered in depth in What Is Email Deliverability?. And if your tests pass but mail still lands in spam, work through the 15 most common reasons emails go to spam.

Use SMTP testing to prove your infrastructure works. Use deliverability testing to prove your emails arrive where humans will see them. You need both.

Want the full picture, not just the first hop? mailtest.ai tests your entire sending path — SMTP connectivity, authentication, and real inbox placement across Gmail, Microsoft, and Yahoo — so you know not just that you sent it, but that it was seen.