← All articles
September 14, 2025·7 min read

SMTP Testing: Test Outbound Emails Without Sending to Real Inboxes

developerSMTPtestingemail testing

Every application that sends email needs a way to test that email without sending it to real users. A misconfigured staging environment that sends 10,000 test notifications to actual customers isn't a hypothetical — it's a rite of passage for enough teams that the industry has built multiple categories of tools to prevent it.

The question isn't whether you need SMTP testing. It's which approach matches your situation.

Why SMTP Testing Matters

Outbound email goes wrong in predictable ways:

  • Staging sends to production addresses. A developer forgets to update the recipient list, and test data hits real inboxes.
  • Templates render incorrectly. HTML email is its own discipline. What looks right in a browser can break in Outlook, Gmail, or Apple Mail.
  • Transactional emails contain wrong data. Password reset links point to localhost. Invoice amounts show test values. Verification codes are hardcoded strings.
  • Email doesn't send at all. SMTP configuration errors fail silently in many frameworks.

Testing catches all of this before it reaches users. The three main approaches each address different parts of the problem.

Approach 1: Fake SMTP Servers

A fake SMTP server accepts email over SMTP but doesn't deliver it anywhere. It stores messages locally and provides a UI to inspect them.

Mailhog

Mailhog is the most widely used open-source fake SMTP server. You run it locally (usually via Docker), point your application's SMTP config at it, and all outbound email gets captured in Mailhog's web UI.

# docker-compose.yml
services:
  mailhog:
    image: mailhog/mailhog
    ports:
      - "1025:1025"   # SMTP
      - "8025:8025"   # Web UI

Configure your app to send to localhost:1025, and every email appears at http://localhost:8025.

Pros: Free, open source, zero external dependencies, great for local development.

Cons: Self-hosted (requires Docker), no real delivery, not easily available in CI environments, no IMAP access, maintenance has stalled. See our Mailhog alternatives guide for more options.

smtp4dev

Similar to Mailhog but built on .NET. Offers a slightly more polished UI and is actively maintained. Same concept — fake SMTP, local capture, no delivery.

Best for: .NET-heavy teams who want a local SMTP capture tool that integrates with their existing stack.

When Fake SMTP Is the Right Tool

Use a fake SMTP server when:

  • You're developing locally and want to see what emails your app sends
  • You need to inspect HTML templates visually
  • You don't need to test actual delivery or IMAP retrieval
  • Your team is comfortable with Docker and self-hosting

Approach 2: Email Sandboxes

An email sandbox is a hosted service that captures outbound email, similar to a fake SMTP server but without the self-hosting overhead. Mailtrap is the most well-known.

How Sandboxes Work

You configure your application to send email through the sandbox's SMTP server. The sandbox captures every message, displays it in a web dashboard, and provides tools for inspecting headers, HTML rendering, spam scores, and more.

No email actually gets delivered. The sandbox is a dead end by design — it's there to prevent exactly the kind of accidental sends that SMTP testing exists to stop.

Mailtrap

Mailtrap provides project-based inboxes, team collaboration features, HTML rendering previews, and an API for automated checks. Free tier has limits; paid plans run $15-35/month.

Pros: Hosted (no Docker), good UI, team features, HTML preview, spam analysis.

Cons: Subscription pricing, no real delivery in sandbox mode, no IMAP access, overkill for simple "does this email arrive?" testing. See Mailtrap alternatives for a full comparison.

Ethereal Email

Built by the Nodemailer team, Ethereal provides free fake SMTP accounts. You create disposable credentials, send email to them, and view messages in the Ethereal web UI.

Pros: Free, no signup needed, perfect for quick tests.

Cons: No persistence (messages expire), no team features, no API.

When Sandboxes Are the Right Tool

Use an email sandbox when:

  • Your team needs a shared view of test emails
  • You want HTML rendering previews and spam score checking
  • You don't want to self-host anything
  • You don't need to test real email delivery or IMAP retrieval

Approach 3: Real On-Demand Inboxes

The third approach is using real email inboxes with real SMTP and IMAP credentials. You send email through real SMTP, it gets delivered to a real inbox, and you read it back via real IMAP. End-to-end.

Reusable.Email Managed Inboxes

A managed inbox on Reusable.Email is a full email account. It has SMTP credentials for sending (smtp.reusable.email:587, STARTTLS) and IMAP credentials for reading (imap.reusable.email:993, SSL/TLS).

The key difference from sandboxes: email is actually delivered. Your tests verify the entire email pipeline, not just the sending half.

Cost: $3 per inbox, one-time. No subscription.

Quick Setup Example

Configure your application to send through a managed inbox's SMTP credentials:

# Django settings.py
EMAIL_HOST = "smtp.reusable.email"
EMAIL_PORT = 587
EMAIL_USE_TLS = True
EMAIL_HOST_USER = "staging@reusable.email"
EMAIL_HOST_PASSWORD = "your-inbox-password"

// Node.js with nodemailer
const transporter = nodemailer.createTransport({
  host: "smtp.reusable.email",
  port: 587,
  secure: false, // STARTTLS
  auth: {
    user: "staging@reusable.email",
    pass: "your-inbox-password",
  },
});

Now your staging or test environment sends real email through Reusable.Email's SMTP server. You can read those emails via IMAP in your test assertions, or just check them in any email client.

When Real Inboxes Are the Right Tool

Use real on-demand inboxes when:

  • You need to test end-to-end email delivery, not just sending
  • Your tests need to read emails via IMAP (parse verification codes, check links)
  • You want staging email that's isolated but real
  • You need SMTP credentials for integration with external services
  • You want a one-time cost instead of a monthly subscription

Choosing the Right Approach

Need Fake SMTP Sandbox Real Inbox
Local dev email preview Yes Yes Overkill
HTML template inspection Basic Best Via client
CI/CD email assertions Difficult Via API Via IMAP
End-to-end delivery test No No Yes
IMAP/POP3 retrieval test No No Yes
Team collaboration No Yes Shared creds
Zero ops No (Docker) Yes Yes
Cost Free $15-35/mo $3 once

Many teams use more than one approach. Mailhog for local development, real inboxes for CI and staging. The approaches aren't mutually exclusive.

Common SMTP Testing Mistakes

Hardcoding production SMTP credentials in test configs. If your test suite accidentally uses production SendGrid or SES credentials, test emails go to real addresses. Use environment-specific configuration files and never share credentials between environments.

Not testing the full loop. Verifying that sendmail() didn't throw an exception isn't an email test. The email might still be malformed, missing headers, or caught by spam filters. Read it back via IMAP to verify the actual content.

Ignoring encoding issues. HTML emails with special characters, Unicode names, or non-ASCII subjects fail in specific email clients. Test with realistic data, not just ASCII strings.

Sharing a single inbox across parallel test runs. If two CI jobs send to the same test inbox simultaneously, their emails interleave and tests get flaky. Use one inbox per test suite, or filter on unique message IDs.

Testing only the happy path. Also test what happens when SMTP credentials are wrong, when the server is unreachable, and when the recipient address is invalid. Your application should handle these failures gracefully.

Setting Up SMTP Testing in Common Frameworks

Most web frameworks have a configuration file or environment variable for SMTP settings. Here's how to point common frameworks at a managed inbox:

Rails (config/environments/staging.rb):

config.action_mailer.smtp_settings = {
  address: "smtp.reusable.email",
  port: 587,
  user_name: "staging@reusable.email",
  password: ENV["SMTP_PASSWORD"],
  authentication: :plain,
  enable_starttls_auto: true,
}

Laravel (.env):

MAIL_MAILER=smtp
MAIL_HOST=smtp.reusable.email
MAIL_PORT=587
MAIL_USERNAME=staging@reusable.email
MAIL_PASSWORD=your-inbox-password
MAIL_ENCRYPTION=tls

Spring Boot (application-staging.properties):

spring.mail.host=smtp.reusable.email
spring.mail.port=587
spring.mail.username=staging@reusable.email
spring.mail.password=${SMTP_PASSWORD}
spring.mail.properties.mail.smtp.starttls.enable=true

The pattern is the same in every case: point the SMTP host at smtp.reusable.email, port 587, STARTTLS enabled, and provide the managed inbox credentials.

What's Next

For a deeper dive into building automated email tests, see How to Build an Email Testing Environment with a Disposable Email API. For the full developer overview of Reusable.Email's capabilities, start with the Email API for Developers guide.

Related Articles

← Back to all articles