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.
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.
Three ways to sandbox emails:
| Approach | Example | Cost | Best for |
|---|---|---|---|
| Built-in test mode | SendPigeon test keys | Free (included) | Teams who want zero setup |
| Local SMTP server | Mailpit, SendPigeon CLI | Free | Local dev, offline work |
| Cloud sandbox | Mailtrap | Free tier / paid | Teams, 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:
- Local dev: SendPigeon CLI (
npx @sendpigeon-sdk/cli dev) or Mailpit for fast, offline testing - CI/staging: SendPigeon test keys to capture emails in the cloud dashboard
- 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
| Feature | SendPigeon test keys | SendPigeon CLI | Mailpit | Mailtrap |
|---|---|---|---|---|
| Type | Built-in sandbox | Local SMTP | Local SMTP | Cloud sandbox |
| Setup | None (use test key) | npx command | brew/Docker | Sign up + config |
| Cost | Free (all plans) | Free | Free | Free (50 emails) |
| Works offline | No | Yes | Yes | No |
| Works in CI/CD | Yes | No | No | Yes |
| Team sharing | Yes (dashboard) | No | No | Yes |
| Email content viewer | Yes | Yes | Yes | Yes |
| Spam analysis | No | No | No | Yes |
| Path to production | Yes (same SDK) | Yes (same SDK) | No | Separate product |
Getting started with SendPigeon's sandbox
Sign up for free
Create an account at sendpigeon.dev/signup. The free plan includes 1,000 emails and built-in sandbox.
Get a test API key
Go to API Keys and create a key. Test keys start with sp_test_.
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>",
});
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
- 7 Best MailHog Alternatives for 2026 — Compare local email testing tools
- How to Send Email with Hono — Full tutorial with sandbox setup
- Local Email Testing Guide — Set up SendPigeon CLI
- Email Deliverability Checklist — Make sure emails reach the inbox when you go live
- SendPigeon vs Mailtrap — Detailed comparison