The deployment looked clean. Code reviewed, tests passing, staging environment verified. They pushed to production and watched the monitoring dashboards. Everything green.
Except emails weren't sending. The SMTP credentials that worked in staging didn't work in production—different environment, different secrets, different configuration. Customers weren't receiving order confirmations. Password resets were failing silently. It took two hours to notice and another hour to fix.
SMTP testing tools prevent this. They let you verify your email configuration works before it matters, catch credentials issues before deployment, and debug sending problems without flooding real inboxes.
Local SMTP servers
Mailhog is the go-to local SMTP server for development. Run it locally, point your application's SMTP settings at it, and every email gets captured in a web interface instead of being delivered. You can inspect the full message—headers, HTML, plain text, attachments—without any email actually leaving your machine.
Installation is trivial: download a single binary, run it, done. No dependencies, no configuration. The web interface shows all captured emails with search and filtering. For development environments, it's essentially mandatory.
MailCatcher does the same thing with a Ruby implementation. The web interface is clean, the functionality is equivalent to Mailhog. Some developers prefer it; others prefer Mailhog's Go-based simplicity. Both work well.
Papercut is the Windows-native option. It runs as a desktop application, capturing SMTP traffic and displaying emails in a local interface. If your development environment is Windows-based, it integrates more naturally than the cross-platform alternatives.
smtp4dev is another Windows-focused option that's been around for years. It's simple and reliable, though the interface feels dated compared to newer tools. For basic SMTP capture on Windows, it works.
Cloud-based testing
Mailtrap provides a cloud SMTP server specifically for testing. Instead of running a local server, you point your application at Mailtrap's SMTP endpoint. Emails are captured in their web interface, where you can inspect content, check HTML rendering, and share results with teammates.
The cloud approach has advantages: no local setup, accessible from any environment, team collaboration built in. The free tier handles reasonable testing volumes; paid tiers add features like API access and more inboxes.
Mailtrap has expanded beyond SMTP capture to include email preview across clients and deliverability testing. If you need more than basic capture, the integrated platform is convenient.
Ethereal Email from Nodemailer provides free disposable SMTP accounts for testing. Generate credentials, use them in your application, and view captured emails in their web interface. It's simpler than Mailtrap—no account required, just generate and go.
The disposable nature is both feature and limitation. Great for quick tests; less suitable for ongoing development where you want persistent history.
SMTP diagnostics
MXToolbox SMTP Diagnostics tests your mail server's configuration from the outside. Enter your domain or server address, and it attempts connections on standard ports, checks TLS configuration, and verifies your server responds correctly to SMTP commands.
This catches configuration issues that internal testing misses. Your server might accept connections from localhost but reject external connections due to firewall rules or binding configuration. External testing reveals these problems.
SMTPer is a simple tool for sending test emails through any SMTP server. Enter credentials and server details, compose a test message, and send. It's useful for verifying that credentials work and the server accepts connections, without involving your application code.
When debugging "SMTP isn't working" issues, isolating whether the problem is your application or the SMTP server is the first step. SMTPer tests the server directly.
CheckTLS tests your server's TLS configuration specifically. It attempts connections with various TLS versions and cipher suites, reporting what works and what doesn't. If you're having TLS-related connection issues, this pinpoints the problem.
Command-line tools
For developers comfortable with the terminal, command-line tools offer flexibility that GUIs can't match.
swaks (Swiss Army Knife for SMTP) is the definitive command-line SMTP testing tool. It can send test emails, test authentication, verify TLS, and exercise virtually any SMTP feature. The learning curve is steeper than GUI tools, but the power is unmatched.
A simple test: swaks --to [email protected] --from [email protected] --server smtp.example.com --auth --auth-user username --auth-password password. This tests authentication and sending in one command.
openssl s_client lets you test TLS connections directly. openssl s_client -connect smtp.example.com:465 establishes a connection and shows certificate details. For debugging TLS issues, seeing the raw handshake is invaluable.
telnet, while ancient, still works for basic SMTP testing. telnet smtp.example.com 25 connects to the server, and you can manually type SMTP commands to see how the server responds. It's tedious but educational—you learn exactly how SMTP works.
Integration testing
For automated testing, you need SMTP testing that integrates with your test suite.
GreenMail is a Java-based mail server designed for testing. It runs embedded in your tests, capturing emails that your application sends. Your test code can then verify that emails were sent with correct content, recipients, and headers.
For Java/JVM applications, GreenMail integrates naturally with JUnit and other test frameworks. The embedded approach means no external dependencies—tests are self-contained and reproducible.
MailSlurper is a lightweight SMTP server with a REST API for retrieving captured emails. Run it alongside your tests, send emails to it, then query the API to verify what was captured. The API-first design makes it easy to integrate with any test framework.
For Node.js applications, nodemailer includes a test account feature that creates Ethereal Email accounts programmatically. Your tests can send emails and then verify delivery through Ethereal's API.
Debugging workflow
When SMTP isn't working, a systematic approach saves time.
First, verify the server is reachable. Can you connect to the SMTP port? Telnet or openssl s_client answers this quickly. If not, it's a network or firewall issue, not an SMTP configuration problem.
Second, verify authentication. Use a tool like SMTPer or swaks to test credentials directly, outside your application. If authentication fails here, the credentials are wrong—check for typos, expired passwords, or app-specific password requirements.
Third, verify TLS. Many SMTP issues stem from TLS misconfigurations. CheckTLS or openssl s_client shows what's happening at the TLS layer. Certificate problems, protocol mismatches, and cipher issues all appear here.
Fourth, test from your application. If direct testing works but your application fails, the problem is in your application's SMTP configuration or library usage. Check connection settings, timeouts, and error handling.
Finally, check the receiving side. If sending succeeds but emails don't arrive, the problem is downstream—spam filtering, recipient server issues, or deliverability problems. Header analysis and deliverability tools help here.
Frequently asked questions
Should I use a local SMTP server or cloud service for testing?
Local servers (Mailhog, MailCatcher) are simpler for individual development—no account needed, works offline, fast. Cloud services (Mailtrap) are better for team environments where multiple developers need to see test emails or when testing from environments that can't run local servers.
How do I test SMTP in CI/CD pipelines?
Run a containerized SMTP server (Mailhog has an official Docker image) as part of your CI environment. Point your application at it during tests. After tests run, query the captured emails via API to verify correct sending behavior.
Why do my SMTP credentials work in one environment but not another?
Common causes: different secrets/environment variables, IP-based restrictions on the SMTP server, different TLS requirements, or rate limiting. Test credentials directly with a tool like swaks to isolate whether it's a credentials issue or application configuration.
What ports should I test SMTP on?
Port 587 (submission with STARTTLS) is the modern standard for sending. Port 465 (implicit TLS) is making a comeback. Port 25 is for server-to-server communication and often blocked for end users. Test whichever port your ESP specifies, and have a fallback plan if it's blocked.