What is an SMTP test? How online SMTP testing works

An SMTP test opens a TCP connection to a mail server and walks through the Simple Mail Transfer Protocol conversation the same way a real mail client would. It reads the server greeting, sends EHLO to discover capabilities, optionally secures the session with STARTTLS or implicit TLS, authenticates if credentials are supplied, and can submit a real message with MAIL FROM, RCPT TO, and DATA.

Each step proves something specific, and the test isolates exactly where a problem occurs, rather than showing a generic "could not send" error that tells you nothing.

A realistic SMTP conversation, annotated

Here is a complete submission session against a typical submission server, with commentary on every exchange. When you run a test, the transcript you see follows this exact shape.

S: 220 mail.example.com ESMTP Postfix
C: EHLO tester.smtptester.org
S: 250-mail.example.com
S: 250-PIPELINING
S: 250-SIZE 35882577
S: 250-STARTTLS
S: 250-AUTH PLAIN LOGIN
S: 250 SMTPUTF8

The 220 greeting confirms DNS resolves, the port is open, and an SMTP service is alive. EHLO is where the server advertises its extensions. Read this list carefully: SIZE 35882577 says the server accepts messages up to roughly 34 MB, so a 50 MB attachment will be rejected later with 552. AUTH PLAIN LOGIN lists exactly which mechanisms you may use; if CRAM-MD5 is absent, requesting it will fail.

C: STARTTLS
S: 220 2.0.0 Ready to start TLS
... TLS handshake ...

The client sends STARTTLS and the server agrees with 220. Both sides then perform a TLS handshake. If it succeeds, everything after this point (including credentials) travels encrypted. If the server's certificate is expired, self-signed, or does not match the hostname, the handshake fails here, before any authentication is attempted.

C: AUTH PLAIN [redacted base64]
S: 235 2.7.0 Authentication successful

AUTH PLAIN sends the username and password together in one base64-encoded string; AUTH LOGIN exchanges them line by line. A 235 response proves the credentials are valid on this server. A 535 means they are not, and the transcript makes it clear the failure was authentication, not connection or TLS.

C: MAIL FROM:<sender@example.com>
S: 250 2.1.0 Ok
C: RCPT TO:<recipient@example.com>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>

MAIL FROM and RCPT TO each get their own reply. A 250 here means the server accepts the sender and will relay to that recipient. If it refuses to relay to an outside domain, RCPT TO returns 554 Relay access denied right at this step, a policy problem rather than a credentials problem. The 354 response to DATA is easy to misread: it is not an error. It is the server saying "go ahead, send the message, end with a dot on its own line."

C: From: Sender <sender@example.com>
C: To: Recipient <recipient@example.com>
C: Subject: SMTP test
C: Date: Thu, 30 Aug 2026 12:00:00 +0000
C: Message-ID: <20260830120000@test>
C:
C: This is a test message.
C: .
S: 250 2.0.0 Ok: queued as 4B2F1A9C3D
C: QUIT
S: 221 2.0.0 Bye

The message headers and body are sent as raw text, terminated by a lone dot. The final 250 ... queued as <ID> is the acceptance receipt: the server has taken the message into its queue. 221 closes the session cleanly.

What each step proves

1. Connect and greeting

The client opens a TCP socket to the server's host and port. A 220 greeting (for example 220 smtp.gmail.com ESMTP) tells you the hostname resolves in DNS, the port is reachable and not blocked by a firewall, and the SMTP service is running. If this step fails (timeout or connection refused), the issue is network-level: wrong host, wrong port, blocked port, or the server is down.

2. EHLO (capabilities)

The client sends EHLO client-hostname and the server responds with a list of extensions it supports:

• 250-STARTTLS: the server offers encryption upgrade.
• 250-AUTH PLAIN LOGIN: the server accepts these authentication methods.
• 250-SIZE 35882577: maximum message size in bytes.
• 250-PIPELINING: the server supports command pipelining.

This tells you what the server can do before you attempt anything further. If a specific AUTH mechanism is missing, you know not to try it.

3. STARTTLS or implicit TLS

With STARTTLS (port 587), the client sends STARTTLS, the server answers 220 Ready to start TLS, and both sides negotiate a TLS handshake before any credentials are sent. With implicit TLS (port 465), the handshake happens immediately on connect, before any SMTP commands. A successful negotiation proves encryption works, and SMTP Tester reports the protocol version (TLS 1.2/1.3), cipher suite, certificate subject, issuer, and expiry (or the exact validation error if the certificate is bad).

4. Authentication (AUTH)

The client sends credentials using the negotiated method (PLAIN, LOGIN, or CRAM-MD5). A 235 response means the server accepted the credentials.

This proves your username, password, and auth method are correct for this server. If you get 535 instead, the credentials are wrong, and the transcript shows you that it is specifically auth that failed, not connection or TLS.

5. Message submission (optional)

If handshake-only mode is off, the client sends MAIL FROM, RCPT TO, and DATA with headers and body. A 250 Ok (often with a queue ID) after the final . means the server accepted the message for delivery processing.

Where each stage breaks

Most "SMTP not working" tickets collapse into one of these rows:

Reading the transcript against this table turns an opaque failure into a specific fix. For the most common row, see fixing SMTP authentication error 535.

Four different things called "SMTP testing"

People use "SMTP test" to mean several distinct checks. Knowing which one you need prevents wasted debugging:

1. Connectivity testing. Can a TCP connection reach the host and port, and does a 220 greeting come back? This validates DNS, firewalls, and service health. It proves nothing about credentials.
2. Authentication testing. Do the username, password, and AUTH mechanism work? A 235 answers this. Credential rotation failures show up here, and nowhere else.
3. Relay permission testing. Will the server actually accept mail from you for an external recipient? This only surfaces when RCPT TO names a domain the server does not host. Servers commonly accept your login but restrict relaying, so a handshake alone cannot answer it.
4. Deliverability testing. Does the message land in the inbox, the spam folder, or a rejection? No SMTP response can tell you this.

The ordering matters because each level depends on the ones before it. There is no point debugging spam placement while authentication still returns 535, or tuning credentials while the port is firewalled.

Submission success is not inbox delivery

This is the most important distinction in SMTP testing:

Submission success (250 after DATA) means the server accepted the message into its queue. It agreed to process it.

Inbox delivery is what happens next. The server attempts to deliver the message to the recipient's mailbox, and that attempt can still fail or land in spam because of:

• DNS/MX resolution problems at the recipient domain.
• Greylisting by the recipient server (temporary rejection, retry later).
• Missing or misaligned SPF, DKIM, or DMARC records.
• Content-based spam filtering.
• Recipient mailbox full or non-existent.
• IP reputation issues (your sending IP is blocklisted).

To verify end-to-end delivery, send a test to a mailbox you control and check whether it arrives, and where (inbox, spam, or rejected). SMTP Tester confirms submission works; deliverability testing is a separate concern that depends on your DNS records, sending IP reputation, and message content.

Who needs to run these tests, and when

• Setting up a new mail server or provider: confirm host, port, TLS, and credentials work before wiring them into your application. A broken configuration in WordPress or a cron script can silently drop mail for hours before anyone notices. Per-provider specifics live in the dedicated guides, for example testing Gmail SMTP and testing SendGrid SMTP.
• Debugging send failures: isolate whether the problem is connection, TLS, authentication, or relay policy before touching application code.
• After credential rotation: verify new passwords or API keys work without deploying code. Testing the new credential from a browser catches typos and expired accounts before the nightly cron job fails at 2 AM.
• New MTA deployments: after installing Postfix, Haraka, or similar, test from an outside network to confirm the server answers on the public interface with the extensions you configured, not just from localhost.
• Verifying TLS configuration: confirm the correct protocol, cipher, and certificate are in use after a certificate renewal.

Handshake-only mode

Handshake-only runs connect, EHLO, STARTTLS, AUTH, and then closes the session without sending MAIL FROM, RCPT TO, or DATA. This is useful for:

• Verifying credentials on a production server without triggering a real send, so you never pollute a customer-facing queue or an inbox with test messages.
• Testing that TLS works after a certificate change.
• Confirming connectivity without triggering rate limits.

A successful handshake-only test proves the session path works up through authentication. It does not prove the server will relay to external recipients, that requires a full send with a real RCPT TO.

Manual tools vs a browser-based tester

Traditionally, admins debug SMTP with telnet host 25, openssl s_client -starttls smtp, or swaks. Each has a place, and each has gaps:

• telnet shows you the raw conversation but cannot negotiate TLS at all. Type AUTH PLAIN and you must base64-encode the username and password yourself. Typing credentials into a plaintext session is exactly how passwords end up in shell history.
• openssl s_client handles STARTTLS and shows full certificate detail, but once TLS starts you are back to typing SMTP by hand, and the output mixes protocol text with certificate noise.
• swaks automates the whole session (TLS, AUTH, message) and is excellent for scripted checks, but you need Perl installed, there is no credential redaction, and you may not be able to install anything on the machine where the problem occurs.
• A browser-based tester streams the same transcript live but adds parsed TLS diagnostics (protocol, cipher, certificate subject and expiry), automatic credential redaction in the output, and zero installation.

The last row matters more than it looks: many corporate and cloud networks block outbound port 25 by default, so telnet tests fail for network reasons that have nothing to do with your server. A browser tester reaches submission ports (587, 465) from the same machine.

A practical habit: use the browser tester for interactive debugging and credential checks, and swaks or openssl when you need to repeat the same session from a script or from the server itself.

Where to go next

• SMTP port 587 vs 465: choosing the right port before you test
• Fixing SMTP authentication error 535: the most common failure and how to read it
• SMTP Tester vs smtper.net: how this tool compares to the browser classic
• Testing Gmail SMTP: app passwords, port rules, and quirks
• Testing SendGrid SMTP: API-key credentials and relay policies

Frequently asked questions

Does an SMTP test send an actual email?

Only if handshake-only mode is off. With handshake-only on, the test stops after authentication and closes the session, so no message is queued or delivered.

What does a 220 response mean?

It is the server's greeting after a successful TCP connection. It confirms DNS, firewall, and service availability, but says nothing about authentication or delivery.

What is the difference between 250 and 235?

235 means the server accepted your credentials. 250 is a general success used for EHLO, MAIL FROM, RCPT TO, and message acceptance. If you see 235 but no final 250 after DATA, your login works but the message submission failed.

Why did my test pass but the email went to spam?

The 250 queued response only proves the sending server accepted the message. Spam placement depends on SPF, DKIM, DMARC, IP reputation, and content, all evaluated downstream. Send a test to a mailbox you control to see actual placement.

Can I test SMTP without installing anything?

Yes. A browser-based tester performs the full session (connect, EHLO, TLS, AUTH, optional message) and streams the transcript back with credentials redacted.

Is it safe to enter real credentials in an SMTP test?

With SMTP Tester, credentials exist only in memory for the duration of the request, are never logged, and are redacted from the transcript before it reaches your browser. Over the wire they are protected by the TLS session you see in the transcript.