SMTP Test Tool
Test any SMTP server's connection, authentication, TLS/SSL configuration, and delivery. Diagnose connection refused, authentication failures, certificate problems, and relay errors before they reach production — without firing up Telnet or a test mail client.
SMTP Configuration
Privacy Note: Your credentials are not stored and are used only for this test session. Always use secure connections (TLS/STARTTLS) when testing with production credentials.
Test Results
Test results will appear here
Configure your SMTP settings and click a test button to start
About SMTP Testing
Port 587 (STARTTLS): Recommended for most modern SMTP servers. Starts unencrypted and upgrades to TLS.
Port 465 (SSL/TLS): Direct encrypted connection from the start. Used by some providers.
Port 25: Traditional SMTP port, typically unencrypted. Often blocked by ISPs for security.
Test Connection: Verifies server connectivity and authentication without sending email.
Send Test Email: Performs full test including actual email delivery.
Security: Always use TLS/STARTTLS for production servers to protect credentials.
About SMTP Test Tool
The SMTP Test Tool exercises an SMTP server through a real connection: TCP handshake, optional STARTTLS upgrade or implicit TLS, EHLO, AUTH, and (optionally) full message delivery. It surfaces the server greeting, advertised capabilities, certificate chain summary, authentication result, and the final 250 OK / NDR — exactly the diagnostic output you'd get from telnet/openssl s_client but presented as a clean form. Pairs with SPF Checker, MX Lookup, and Trace Email for end-to-end deliverability debugging.
Why use a SMTP Test Tool?
When transactional mail starts bouncing, the 'why' is almost always one of four things: TCP connection refused, TLS negotiation failure, AUTH rejected, or RCPT TO refused. Telnet can show you each of those but only if you remember the SMTP protocol commands and TLS handshake sequence. This tool runs the same diagnostic via a UI — type credentials, click test, see exactly which step fails and the server's actual response code/message. No need to install Postfix or write a one-off Node script.
Who is it for?
DevOps engineers configuring transactional email for a new app, developers integrating SendGrid/Mailgun/Postmark/SES SMTP relays, IT admins testing an on-prem mail server before cutover, support teams diagnosing 'our outbound mail stopped working' tickets, and security folks validating that a vendor's SMTP credentials work without bouncing the test mail through their own production app.
How to use the tool
Enter the SMTP host (smtp.gmail.com, smtp.sendgrid.net, your own server, etc.)
Pick the port — 587 for STARTTLS (most common), 465 for implicit TLS, 25 for unencrypted (testing only)
Choose the security mode — auto-defaults match the port choice
Enter the username and password (or app password). Credentials never leave the browser session
Set the From and To addresses for the test message
Click 'Test Connection' for a non-sending diagnostic OR 'Send Test Email' for full delivery
Read the result panel: each step (connect, TLS, AUTH, MAIL FROM, RCPT TO, DATA) shows pass/fail with the server's actual response
If it fails, the response code (e.g. 535 for auth failure, 550 for relay denied, 4xx for transient) tells you exactly what to fix
Key Features
Step-by-step SMTP transaction trace
See every SMTP command and response (220 greeting, EHLO capabilities, STARTTLS, AUTH, MAIL FROM, RCPT TO, DATA, 250 OK). Failures point at the exact step that broke.
TLS / STARTTLS validation
Reports negotiated TLS version, cipher, certificate issuer, and expiry. Catches expired certs, wrong-hostname certs, and servers that don't actually support STARTTLS despite advertising it.
Auto-port → security mapping
Pick port 587 → STARTTLS. Pick 465 → implicit TLS. Pick 25 → unencrypted. The form pre-selects the right mode so you don't fight protocol mismatches.
Credential-free test mode
'Test Connection' verifies the server reaches AUTH without sending any data — useful for confirming a setup before you have credentials, or testing that an IP is allowlisted.
Full-delivery test with actual sent message
'Send Test Email' runs the entire transaction and delivers a real message. Returns the server's message ID so you can confirm delivery on the other side.
Detailed error reporting
Server response codes (5xx vs 4xx) are categorized. 535 = auth, 550 = relay, 421 = service not available, 452 = mailbox full, etc. — each with the actual message and a plain-English fix suggestion.
No credential storage
Username/password live only in the request payload to the worker, never persisted, never logged. Use app-specific passwords (Gmail, Microsoft) for extra safety.
Common Use Cases
Verifying SendGrid / Mailgun / Postmark API SMTP credentials
Scenario: You provisioned an ESP API key and want to make sure the SMTP relay credentials work before wiring them into production.
✓ 30-second test confirms the relay accepts your credentials and delivers mail. Skip the round-trip of deploying a code change just to test.
Debugging 'our app stopped sending email overnight'
Scenario: App deploys haven't changed but transactional mail is failing. Suspect the SMTP relay credentials expired or the provider rotated something.
✓ Run the test with the production credentials. If AUTH fails, you know it's a credential / API-key issue. If TLS fails, the provider may have raised minimum TLS version. If 5xx on RCPT, the recipient is on a suppression list.
Pre-launch validation of an in-house Postfix / Exim setup
Scenario: You set up your own mail server and want to confirm everything works (TLS, AUTH, relay) before pointing the app at it.
✓ Test against your own server. Catches the misconfigured TLS cert, wrong relay rules, or AUTH backend issues before users hit them.
Migrating from one ESP to another
Scenario: Switching from one SMTP provider to another and want to verify the new relay before cutover.
✓ Test new credentials. If they work, point the app at the new relay. If they don't, you have actionable diagnostics from the new ESP's response.
Diagnosing TLS-version-mismatch errors
Scenario: Provider tightened their minimum TLS version (e.g. now requires 1.2+). Your app uses an older library that defaults to TLS 1.0/1.1.
✓ TLS section of the test result shows the negotiated version and any failure reason. Confirms the issue is on the client side and tells you what minimum to require.
Real SMTP transaction with real TLS handshake. The result is exactly what your application would see when connecting from the worker's network.
Credentials and message content live only in the request to our edge proxy — never persisted, never logged. Use app-specific passwords for extra safety.
Globally distributed edge infrastructure for low-latency queries.
Frequently Asked Questions
What's the difference between STARTTLS, TLS, and unencrypted?
STARTTLS (port 587) starts as plain TCP, then upgrades to encrypted via the STARTTLS command. Implicit TLS (port 465) is encrypted from the first byte. Unencrypted (port 25) doesn't use encryption — only appropriate for server-to-server relay between trusted internal hosts. Use STARTTLS or TLS for any SMTP server you authenticate against.
Why does Gmail reject my password?
Since 2022, Gmail / Google Workspace require an 'App Password' for SMTP authentication — your regular Google account password doesn't work. Generate an app password in Google Account → Security → 2-Step Verification → App passwords, and use that 16-character string. Same applies to Microsoft 365 (use app password if MFA is enabled).
What does 535 5.7.8 mean?
5xx codes are permanent failures. 535 specifically means authentication credentials rejected. The 5.7.8 enhanced status code narrows it: 'Authentication credentials invalid'. Translation: your username or password is wrong (or, in Gmail's case, you used your real password instead of an app password).
What does 421 mean?
4xx codes are transient — try again later. 421 specifically means 'service not available'. Often the server is overloaded, rate-limiting, or temporarily blocking your IP. Wait a few minutes and retry; if it persists, contact the provider.
What does 550 mean for RCPT TO?
5xx on RCPT TO is the recipient being refused. 550 is most common — could be 'recipient doesn't exist', 'recipient blocked', 'sender domain rejected as spam', 'relay denied' (if your auth wasn't accepted), or 'recipient on suppression list'. Read the full response text — providers usually explain.
Are my credentials stored?
No. Credentials are sent in the request to the worker, used only to perform the SMTP transaction, and never persisted, never logged, never used for anything else. Use app-specific passwords (Gmail, Microsoft) where possible — even if a credential is exposed, it's scoped and revocable.
How does this differ from telnet smtp.example.com 25?
Telnet does the same SMTP commands but only over plain TCP — it can't easily test STARTTLS or implicit TLS, and you have to type the protocol commands yourself. This tool exercises the full modern SMTP stack with TLS, with a friendly UI and structured diagnostic output.
Why does the server greet me with the wrong hostname?
The server's banner (220 line) might show its internal hostname instead of the public DNS name you connected to. Usually fine, but if you're testing reverse-DNS for deliverability you want them to match — many anti-spam policies penalize mismatched banner / PTR. Worth checking with your hosting provider.
Technical Specifications
Supported Formats
- ✓SMTP / ESMTP over TCP
- ✓STARTTLS (port 587), implicit TLS (port 465), unencrypted (port 25)
- ✓AUTH PLAIN, AUTH LOGIN, AUTH CRAM-MD5
- ✓Test Connection (no delivery) or full Send Test (delivery + message ID)
- ✓TLS version detection (1.0 through 1.3)
- ✓Certificate chain summary (issuer, expiry, hostname match)
- ✓All standard SMTP response codes (2xx, 3xx, 4xx, 5xx) with parsing
Limits & Performance
- •File Size: Single SMTP server test per request
- •Validations: Live SMTP transaction
- •Response Time: 1-15 seconds depending on server response time and TLS negotiation
- •Browsers: All modern browsers
Pro Tips
- Always use STARTTLS (port 587) or TLS (port 465) — never unencrypted SMTP for any production sending.
- Use app-specific passwords for Gmail / Microsoft / Yahoo. Your account password won't work and using it weakens security if leaked.
- Test with both 'Test Connection' (no actual delivery) and 'Send Test Email' — sometimes connect+auth pass but the message gets rejected at RCPT TO.
- If 5xx on AUTH, double-check whether the provider requires the username to be the full email address or just the local part. Different providers differ.
- Test from the same network as your production app. NAT issues, ISP-level port 25 blocks, or firewall rules can cause failures from a dev environment that won't repro in prod (or vice versa).
- When testing a provider's SMTP relay, send the test email to a Gmail address. Then check the Gmail spam folder + view-original to see how Gmail rated your message — useful early signal on deliverability.
- Keep the From and To addresses on different domains for any meaningful test. Same-domain mail often takes a different code path inside ESP infrastructure.
Share This Tool
Found this tool helpful? Share it with others who might benefit from it!
💡 Help others discover useful tools! Sharing helps us keep these tools free and accessible to everyone.