About SMTP Tester

SMTP Tester is a free, open-source tool that helps developers, system administrators, WordPress admins, MTA operators, and IT support teams test and verify any SMTP server. Instead of guessing why mail will not send, you can watch the entire SMTP conversation happen live and see exactly where it succeeds or fails.

The tool runs a real connection against the server you specify, streams the full protocol transcript back to your browser, and shows plain-language hints when something fails. There is no signup, no tracking wall, and no server-side storage of your credentials. You can use it hosted at smtptester.org or run it yourself from the source code.

What SMTP Tester does

When you run a test, SMTP Tester opens a live connection to the mail server and walks through the Simple Mail Transfer Protocol step by step: it reads the server greeting, sends EHLO to discover what the server supports, upgrades the session with STARTTLS or implicit TLS, authenticates with your credentials, and optionally submits a test message. Every client and server line is streamed back to your browser in real time as the conversation unfolds, so you are never staring at a spinner wondering what stage the test has reached.

The transcript is the core of the tool. You see the actual SMTP dialogue: greeting, EHLO response, TLS negotiation, AUTH exchange, MAIL FROM, RCPT TO, DATA, and the final response codes. Passwords and authentication payloads are redacted automatically before anything reaches your screen. If a test fails, the error response is shown alongside a short explanation and, where one exists, a link to a guide that covers that specific failure.

Beyond the transcript, each test produces:

• A stage timeline showing each phase of the handshake and whether it succeeded, failed, or was skipped.
• A TLS certificate panel from a separate short-lived probe: negotiated protocol and cipher, certificate issuer, subject, and expiry.
• Error hints that map common server responses to matching guides in our library.
• A copyable transcript you can paste into a ticket, a pull request, or a conversation with a provider's support team.

Why we built it

Anyone who has debugged email delivery knows the usual routine: open a terminal, type telnet mail.example.com 25, squint at the greeting, and try to type base64-encoded AUTH strings by hand from memory. Or run openssl s_client to check whether the certificate expired, then re-do everything with different credentials and no record of what was actually said. That workflow is slow, error-prone, and inaccessible to anyone who is not comfortable on the command line. It also gives you no clean artifact to share with a colleague or a support engineer.

Most web-based SMTP testers hide that conversation behind a single pass/fail result. When the test fails with "authentication failed" or "connection timed out", you learn almost nothing about why.

SMTP Tester exists to close that gap: the full dialogue, visible live, redacted, and copyable. If you want a deeper explanation of what a test involves, our guide on what an SMTP test is covers the mechanics of each stage.

How a test works

A test runs in four broad phases, and you control each one:

1. Connect. The tool opens a TCP connection to your host and port. Port defaults map to security modes: 465 uses implicit TLS, 587 and 2525 use STARTTLS, and 25 uses no encryption unless you choose otherwise. If your port and security choice look mismatched (for example, TLS selected on port 587), the form flags it before you run the test.
2. Secure. The session upgrades via STARTTLS or implicit TLS as configured. The separate TLS probe reports the negotiated protocol, cipher, and certificate details that telnet cannot show you.
3. Authenticate. You pick PLAIN, LOGIN, or CRAM-MD5, or leave the method on Auto and let the tool negotiate based on what the server advertises in its EHLO response.
4. Deliver (optional). In full mode, the tool sends a short test message drawn from a rotating set of professional templates to the address you enter. In handshake-only mode, the message phase is skipped entirely: the tool verifies the connection, TLS, and your credentials without delivering any mail, which is what you want when testing production relays or shared credentials you would rather not use to send a real message.

Because the whole conversation streams back as it happens, a failure is usually obvious within seconds: an unexpected greeting, a 530 response on AUTH, a certificate error, or a relay rejection. Our guide on SMTP authentication failures covers the most common errors in that stage and how to fix them.

Privacy and security by default

SMTP Tester has no database and no user accounts. What happens to the credentials you enter:

• They are used for exactly one purpose: to connect to your server for the test you initiated.
• They are never written to disk or to a log on our side. The server holds them in memory for the duration of the test and discards them when it ends.
• They are redacted from the transcript before it is streamed to your browser, so AUTH exchanges appear with credentials masked.
• They are never sent to any third party.

The only data that persists anywhere is in your own browser. If you save a connection profile, it is stored in your browser's localStorage, never on our servers. Passwords are only kept in a profile if you explicitly check "remember password"; the last-run fields the tool restores between visits contain no secrets. Closing the tab or running a new test discards whatever the server was holding.

If you disconnect mid-test, the run is aborted and the connection closed rather than left running. For the full data-handling picture, see our Privacy Policy.

Who it is for

• Developers integrating email into an application who need to confirm credentials, ports, and TLS settings work before wiring them into code.
• WordPress and CMS administrators debugging transactional email plugins, where a wrong port or auth method shows up only as silent mail failure.
• MTA operators running Postfix, Exim, KumoMTA, PowerMTA, or similar, who want to verify relay authentication and TLS on a submission endpoint without sending real traffic.
• IT support teams who need a shareable, redacted transcript to attach to a ticket or forward to a provider's support desk.

The guides library

A test tells you that something failed; a guide tells you why. The guides library covers SMTP setup and verification for major providers, including Gmail, Outlook 365, Zoho, SendGrid, Mailgun, Amazon SES, Brevo, Resend, SparkPost, Mailjet, and SMTP2GO, plus self-hosted MTAs such as KumoMTA and PowerMTA. Concept guides explain the decisions behind the settings, like whether to use port 587 with STARTTLS or port 465 with implicit TLS, and how to read the response codes you will see in a transcript.

Every guide is written against real server behavior, and the tool's error hints link directly to the guide that matches the failure you hit.

Open source and self-hosting

SMTP Tester is open source and self-hostable. You can clone the repository, run the server yourself on your own network, and test mail servers that are only reachable internally, such as a relay inside a VPC or a container on your workstation. Self-hosting also means credentials for internal systems never leave your network at all, even to a browser session on a hosted copy.

Contact and feedback

The tool and the guides are actively maintained. If you found a bug, want a feature, or need a guide for a provider we have not covered yet, tell us through the Contact page. Reports that include the redacted transcript and the stage timeline are the easiest to act on.