Test staging emails without risking real customers
Give staging, QA, and demo their own private inboxes. It works even when the email comes from a service you do not control, not just your own app's SMTP.
Free plan includes 500 emails a month. No credit card.
Every sender ends up in one private inbox, no SMTP relay in the middle.
Why staging email leaks to real customers
Staging is meant to be a safe copy of production, but its email often is not.
Real-looking seed data
Fixtures and demo accounts using addresses like [email protected] can be real mailboxes at real companies, and a staging run can email them.
SMTP sandboxes
Tools that capture your app's own outbound SMTP need every environment's SMTP settings repointed, and one missed environment variable sends live mail.
Services you do not control
Auth providers, billing systems, and support tools send email directly, not through your app's SMTP relay, so an SMTP sandbox never sees that mail at all.
How to isolate staging email in four steps
Set it up once per environment, then every test run stays contained.
- 01
Create a project per environment
Give staging, QA, and demo their own Inceptmail project, for example inboxes on [email protected].
- 02
Point every recipient at a test inbox
Update seed data, fixtures, and any third-party service's notification settings to use the test addresses, not real-looking ones.
- 03
Run staging as normal
Sign-ups, password resets, billing receipts, and alerts all land centrally, whether your app sent them or a third-party service did.
- 04
Confirm nothing reached a real inbox
Because every recipient is a private test address, there is no real customer on the other end to accidentally notify.
What to check before you trust a staging environment
Isolation is not automatic, these are the places it usually leaks.
No real-looking domains in fixtures
Seed data and demo accounts use your Inceptmail addresses, not made-up addresses at real companies.
Third-party services configured
Auth, billing, and support tools in non-production point notification recipients at test inboxes, not a shared personal one.
Per-run isolation in CI
Parallel pipelines use their own inbox or project, so two runs never read each other's mail.
Access is restricted
Only the team that needs a staging inbox can see it, shared per inbox rather than through one shared mailbox password.
Retention matches your test cycle
Messages age out automatically (7 days on Free, 90 on Pro), so staging inboxes do not accumulate indefinitely.
Alerts and monitoring, too
Route staging's error and monitoring emails to a test inbox as well, so an on-call engineer never gets paged by a test run.
Common staging email incidents
Most of these are one misconfigured environment away from a real customer's inbox.
| Incident | What you will notice |
|---|---|
| Demo data mails a real address | A seeded account with a guessed real domain receives a live transactional email. |
| Third-party mail bypasses the sandbox | An SMTP-only test tool shows nothing, because the email never went through your app's SMTP. |
| Forgotten environment variable | One staging instance still points at the production SMTP relay. |
| Shared mailbox password | A former team member can still read staging mail after they leave. |
| CI runs collide | Two parallel pipelines both write to the same inbox and read each other's messages. |
| Unbounded staging mailbox | Years of test mail sit in one inbox with no automatic cleanup. |
Isolate staging email with Inceptmail
A real receiving address per project, so nothing depends on your app's own SMTP configuration being right in every environment.
A real address, not a relay
Inceptmail addresses receive mail from anywhere. There is no SMTP to reconfigure, and no gap for a third-party service's email to fall through.
Live delivery
Every message, from your app or a third party, appears the moment it arrives.
Preview and raw HTML
Inspect the rendered email and the underlying markup for every environment.
Per-inbox team access
Share exactly the staging inbox a teammate needs, nothing more.
Also testing signup verification emails or password resets? The same private inboxes cover both.
Staging environment email testing FAQ
How do I stop staging emails from reaching real customers?
Replace every real-looking address in seed data, fixtures, and third-party service settings with a private test inbox address. Because the address is real and receives mail from anywhere, there is no SMTP relay to misconfigure and no real customer on the other end.
Can it catch email sent by services I do not control, like Stripe or an auth provider?
Yes. Inceptmail is a real receiving address, not an SMTP capture tool, so it receives mail from any sender, including third-party services that send directly rather than through your app's own SMTP configuration.
Do I need to change my app's SMTP settings to use it?
No. You only change the recipient address in staging's configuration or seed data. Nothing about how your app or any third-party service sends email changes.
How do I share a staging inbox with my QA team?
Invite teammates to the project and grant access to the specific inbox they need, rather than sharing one mailbox's credentials.
Can I use this in an automated staging test suite?
Yes. Put a stable Inceptmail address in your staging configuration, run your suite, and inspect what arrived in the dashboard. There is no public API yet, so this step is manual today.
Is Inceptmail free for staging use?
Yes. The Free plan includes 500 emails a month, 3 inboxes per project, and 7 days of message history, with no credit card needed.
Give your test email a proper home.
Create your first inbox in under a minute. The Free plan covers a whole project.
Get started free