Email

SMTP Test

Connection & login

Test an SMTP server

Check that a mail server accepts your connection, encryption, credentials and recipient — with or without actually sending a message.

Fills in the host, port and encryption. Pick Custom for your own server.

What happens to your credentials

Your username and password are used for this single connection and nothing else. They are held in memory for the few seconds the test runs, are never written to disk, never saved to a database, never logged, and never included in the result or the JSON export. Nothing about this test is stored or shareable — there is no result link to leak. We do not use your credentials for any other purpose.

Be aware of what this cannot protect: the credentials travel over HTTPS to our server and then on to the mail server you named, so they do pass through infrastructure we operate and networks we do not control. If you choose no encryption, they reach the mail server in clear text. Prefer an app password or a throwaway test credential over your primary account password, and rotate anything you are unsure about.

This tool is provided as-is, with no warranty of any kind. Only test servers you own or are authorised to test. To the fullest extent permitted by law, ShowDNS accepts no liability for interception, unauthorised access, credential compromise or misuse by any third party, or for any loss or damage arising from your use of this tool. See our Terms of Service and Privacy Policy.

Both addresses are needed even for a connection test — the envelope is what proves the server will accept mail from this sender to this recipient.

What should this test do?

Runs the full session up to RCPT TO, then resets. Nothing is delivered.

Auto picks the strongest method the server advertises in its EHLO response.

Fill in your server details above and choose Run connection test to see the full SMTP conversation, step by step.

Tool features

A complete SMTP session, recorded step by step
8 checks

Full connection trace

Every step from DNS lookup to RCPT TO, with the server’s own reply and how long it took.

Test without sending

Verify the whole route up to recipient acceptance without delivering anything.

Real test email

Optionally finish the session with a short plain-text message so you can confirm it arrives.

STARTTLS and implicit TLS

Reports the negotiated protocol, cipher and certificate for either encryption mode.

Authentication check

LOGIN, PLAIN and CRAM-MD5, picked automatically from what the server advertises.

Capability listing

The complete EHLO response, including maximum message size and offered AUTH mechanisms.

Reverse DNS

Shows the PTR record for the server’s address — a signal receiving systems check.

Provider presets

Correct host, port and encryption for Gmail, SES, SendGrid, Microsoft 365 and more.

How an SMTP session works

What each step in the trace means

Sending mail is a conversation. Your client resolves the server’s hostname, opens a TCP connection, and waits for a greeting. It introduces itself with EHLO, and the server replies with a list of everything it supports.

If encryption is in play, the connection is upgraded next — either with STARTTLS on an already-open connection, or by starting encrypted from the first byte on port 465. After a STARTTLS upgrade the client must say EHLO again, because the session resets; this is where the AUTH options usually appear for the first time.

The client then authenticates, names the sender with MAIL FROM and the recipient with RCPT TO. At that point the server has agreed to accept a message, but nothing has been sent. Only DATA transfers the message itself.

Each of those steps can fail on its own, and the reply code tells you which. That is why a trace is more useful than a pass or fail: "it does not work" and "the server rejected the password at AUTH with 535" are very different problems.

EHLO
STARTTLS
AUTH
MAIL FROM
RCPT TO
DATA

How to use this tool

Test an SMTP server in four steps
1
Enter your server details
Pick a provider preset or type your own host. The preset sets the port and encryption for you.
2
Add credentials and addresses
Supply the username and password the server expects, plus the sender and recipient addresses to test.
3
Choose what the test should do
Run a connection test to check everything short of delivery, or send a real test email to confirm it arrives.
4
Read the trace
Each step shows the server’s reply and its timing. The first failing step is where the problem is.

Learn more

Guides & explainers related to this tool

Error

550 5.7.1 Relaying Denied

Why a server accepts your login but refuses the recipient — the usual cause of a failed RCPT TO.

Error

550 5.1.1 User Unknown

What it means when the mailbox itself does not exist on the receiving server.

Article

TLS vs SSL Explained

What the protocol and cipher in your trace actually mean, and which versions still count as safe.

Guide

Why Emails Go to Spam

The connection can succeed and the message still be filtered — what decides that.

Related tools

Keep debugging with tools from the same suite
4 tools
Email Health Checker
Comprehensive email deliverability check including SPF, DKIM, DMARC, and MX records
MX Lookup
Find mail exchange (MX) records for email server configuration and priority
MTA-STS & TLS-RPT Checker
Check a domain MTA-STS policy and TLS-RPT record, validating DNS records and the live HTTPS policy file
IP Blacklist Checker
Check if IP address is blacklisted across multiple DNSBL and spam databases

Frequently asked questions

Common questions about SMTP testing
7 Q&A

No. The password is used to build the AUTH command for this one connection and is never written to disk, saved to a database, logged, or returned in the result or the JSON export. Nothing about the test is persisted, and there is no shareable result link. It does pass through our server in order to reach yours, so we still recommend using an app password or a dedicated test credential rather than your primary account password.

Both run exactly the same SMTP session. The connection test stops after RCPT TO and issues a reset, so the server has agreed to accept a message but none is delivered. Send mode continues into DATA and hands over a short plain-text message. If you only need to know whether the settings work, the connection test tells you that without putting anything in an inbox.

RCPT TO acceptance is a promise to take the message, not a promise to deliver it. Plenty of servers accept a recipient and then bounce or quarantine the message afterwards based on content, SPF, DKIM or DMARC. Run the test in send mode to confirm end-to-end delivery, and check your SPF, DKIM and DMARC records if the message arrives in spam.

A 535 reply nearly always means the credential is not the one the server expects rather than that you typed it wrong. Gmail and Zoho require an app-specific password when 2FA is enabled, SendGrid expects the literal username "apikey", Amazon SES uses SMTP credentials rather than AWS access keys, and Microsoft 365 disables SMTP AUTH on most tenants by default.

Most hosting providers and consumer ISPs block outbound port 25 to limit spam. A timeout on 25 with a working 587 is that block, not a problem with the server. Port 587 is the submission port and is what client software should use anyway.

No. The tool refuses hostnames that resolve to private, loopback or link-local addresses, and only connects to ports 25, 465, 587 and 2525. For an internal server, run the same checks from a machine on that network with swaks or openssl s_client.

Connection tests are limited to 10 per hour per IP address and test emails to 3 per hour. The tighter limit on sending is what stops the tool being used as an anonymous mailer — the message body is a fixed template for the same reason.