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.

What each step proves

1. Connect and greeting

The client opens a TCP socket to the server's host and port. If the server responds with a 220 greeting (for example 220 smtp.gmail.com ESMTP), you know:

• The hostname resolves in DNS.
• The port is reachable and not blocked by a firewall.
• The SMTP service is running and accepting connections.

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

If you chose STARTTLS (port 587), the client sends STARTTLS and the server responds 220 Ready to start TLS. Both sides then negotiate a TLS handshake. After that, all further commands (including credentials) are encrypted.

If you chose implicit TLS (port 465), the TLS handshake happens immediately on connect — before any SMTP commands.

A successful TLS negotiation proves:

• Encryption works between client and server.
• The server's certificate is valid (or you see which validation errors occur).
• SMTP Tester reports the protocol version (TLS 1.2/1.3), cipher suite, certificate subject, issuer, and expiry.

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:<[email protected]> — declares the sender.
• RCPT TO:<[email protected]> — declares the recipient.
• DATA followed by headers and body, ending with a lone . on a line.

A 250 Ok (often with a queue ID) after the final . means the server accepted the message for delivery processing.

Submission success vs 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. Delivery can still fail after successful submission 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.

When to use an SMTP test

• Setting up a new mail server or provider: confirm host, port, TLS, and credentials work before wiring them into your application.
• Debugging send failures: isolate whether the problem is connection, TLS, authentication, or relay policy.
• After credential rotation: verify new passwords or API keys work without deploying code.
• Verifying TLS configuration: confirm the correct protocol, cipher, and certificate are in use.
• Production health checks: use handshake-only mode to test connectivity and auth without delivering a message.

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.
• Testing that TLS works after a certificate change.
• Confirming connectivity without generating mail in the server's queue.

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.

SMTP Tester vs command-line tools

Traditionally, admins debug SMTP with telnet host 25, openssl s_client -starttls smtp, or swaks. SMTP Tester provides the same diagnostic information from a browser:

SMTP Tester streams the transcript live (the same lines you would see in a terminal session) but adds TLS diagnostics, automatic credential redaction, and works from any device with a browser — including machines where you cannot install software or where outbound port 25 is blocked.