Back to blog
TestingDevelopmentEmail SandboxBest Practices

Email Sandbox for Developers: Test Without Sending to Real Users

What is an email sandbox? How to test emails in development without accidentally emailing real users. Compare free options: built-in sandbox, local SMTP, and cloud-based tools.

SendPigeon TeamFebruary 3, 20267 min read

An email sandbox catches outgoing emails during development so they never reach real inboxes. Instead of emailing your users every time you test a password reset or order confirmation, the sandbox captures the email and lets you inspect it.

If you've ever accidentally sent test emails to real users from a staging environment, you know why this matters.

TL;DR

Three ways to sandbox emails:

ApproachExampleCostBest for
Built-in test modeSendPigeon test keysFree (included)Teams who want zero setup
Local SMTP serverMailpit, SendPigeon CLIFreeLocal dev, offline work
Cloud sandboxMailtrapFree tier / paidTeams, CI/CD, staging

What is an email sandbox?

An email sandbox intercepts emails sent by your application and stores them for inspection instead of delivering them. You can:

  • View the full email (HTML, plain text, headers)
  • Check that dynamic content (names, links, codes) renders correctly
  • Verify your email templates look right
  • Test without worrying about spamming real users

There are three main approaches.


Approach 1: Built-in test mode

Some email APIs have a built-in sandbox. You use a test API key, and emails are captured in the provider's dashboard instead of being sent.

SendPigeon

SendPigeon includes a sandbox in every plan (including free). Use a test API key, and emails appear in your dashboard instead of being delivered:

import { SendPigeon } from "sendpigeon";

// Test key → emails captured in dashboard, never sent
const client = new SendPigeon("sp_test_your_test_key");

await client.send({
  from: "noreply@yourdomain.com",
  to: "user@example.com",
  subject: "Welcome!",
  html: "<h1>Welcome to our app!</h1>",
});

// Email appears in dashboard → not delivered to user@example.com

No configuration. No separate sandbox service. No extra bill. Switch to a live key (sp_live_...) when you're ready to send for real.

Your code stays identical between development and production. The only change is the API key.

Pros:

  • Zero setup — works immediately
  • See emails in the same dashboard you use for production
  • Works in CI/CD and staging (no localhost needed)
  • No separate subscription

Cons:

  • Requires internet connection (emails go to the API)
  • Tied to one email provider

Other providers with sandbox modes

  • Brevo has a sandbox mode for testing email sends
  • Mailtrap started as a sandbox tool (but charges separately for sandbox and sending)

Approach 2: Local SMTP server

Run a fake SMTP server on your machine. Point your app at localhost and emails are caught locally.

SendPigeon CLI

Zero install — runs via npx:

npx @sendpigeon-sdk/cli dev

SMTP on localhost:4125, web UI at localhost:4100. If you're using the SendPigeon SDK, set SENDPIGEON_DEV=true and it routes to localhost automatically.

Mailpit

The most popular open-source option:

# macOS
brew install mailpit

# Docker
docker run -p 1025:1025 -p 8025:8025 axllent/mailpit

SMTP on localhost:1025, web UI at localhost:8025.

When to use local SMTP

  • Offline development — No internet needed
  • Speed — Instant capture, no network latency
  • Privacy — Email content stays on your machine
  • Any language — Works with any app that sends SMTP

Tradeoff: Doesn't work for CI/CD or shared staging environments (each developer runs their own instance).


Approach 3: Cloud sandbox

A hosted service that acts as a fake SMTP server in the cloud. You point your app's SMTP config to the service and emails are captured in a shared web dashboard.

Mailtrap

The most established cloud sandbox:

const transport = nodemailer.createTransport({
  host: "sandbox.smtp.mailtrap.io",
  port: 2525,
  auth: { user: "your_username", pass: "your_password" },
});

Free plan: 50 test emails. Paid sandbox plans start at $17/month ($14/month billed annually).

When to use cloud sandbox

  • Team collaboration — Everyone sees the same captured emails
  • CI/CD pipelines — No local SMTP server to manage
  • Staging environments — Shared sandbox for the whole team

Tradeoff: Paid plans add up, especially if you also pay for a separate email sending service.


Which approach should you use?

Use built-in test mode if:

  • You want zero setup and zero extra tools
  • You're already using (or plan to use) an email API with sandbox support
  • You need sandbox for CI/CD and staging, not just local dev

Use a local SMTP server if:

  • You work offline or want maximum speed
  • You don't want email content leaving your machine
  • You're not using a dedicated email API (e.g., sending via raw SMTP/Nodemailer)

Use a cloud sandbox if:

  • Your team needs shared visibility into test emails
  • You need SMTP-level capture for legacy applications
  • You want spam analysis and HTML/CSS validation (Mailtrap)

Combine approaches

Many teams use both:

  1. Local dev: SendPigeon CLI (npx @sendpigeon-sdk/cli dev) or Mailpit for fast, offline testing
  2. CI/staging: SendPigeon test keys to capture emails in the cloud dashboard
  3. Production: SendPigeon live keys to send real emails
# .env.development (local)
SENDPIGEON_DEV=true
SENDPIGEON_API_KEY=sp_test_xxx

# .env.staging (CI/staging)
SENDPIGEON_API_KEY=sp_test_xxx

# .env.production
SENDPIGEON_API_KEY=sp_live_xxx

Same SDK, same code. Only the environment changes.


Comparison table

FeatureSendPigeon test keysSendPigeon CLIMailpitMailtrap
TypeBuilt-in sandboxLocal SMTPLocal SMTPCloud sandbox
SetupNone (use test key)npx commandbrew/DockerSign up + config
CostFree (all plans)FreeFreeFree (50 emails)
Works offlineNoYesYesNo
Works in CI/CDYesNoNoYes
Team sharingYes (dashboard)NoNoYes
Email content viewerYesYesYesYes
Spam analysisNoNoNoYes
Path to productionYes (same SDK)Yes (same SDK)NoSeparate product

Getting started with SendPigeon's sandbox

1

Sign up for free

Create an account at sendpigeon.dev/signup. The free plan includes 1,000 emails and built-in sandbox.

2

Get a test API key

Go to API Keys and create a key. Test keys start with sp_test_.

3

Send a test email

import { SendPigeon } from "sendpigeon";

const client = new SendPigeon("sp_test_your_key");

await client.send({
  from: "test@yourdomain.com",
  to: "anyone@example.com",
  subject: "Testing sandbox",
  html: "<p>This email won't be delivered.</p>",
});
4

View in dashboard

Open the SendPigeon dashboard. Your test email appears with full content — HTML, plain text, headers, metadata.


FAQ

What happens if I accidentally use a test key in production?

No emails are delivered. Test keys always capture to the dashboard. You'll notice quickly because users won't receive their emails.

Can I use the sandbox in automated tests?

Yes. Use a test API key in your test environment. Emails are captured in the dashboard without being delivered. You can verify sends by checking the API response.

Is the sandbox free?

SendPigeon includes sandbox in every plan, including the free tier. Mailtrap's sandbox starts free (50 emails) but paid plans are separate from their sending product. Local tools like Mailpit and SendPigeon CLI are completely free.


Related