"Wait, Mailtrap sends emails?" Email API/SMTP (live sending) vs Email Sandbox

Uhhm, yes, Mailtrap sends emails.

And it’s been sending emails since 2022 – when we launched Email API/SMTP, our live-sending product.

Since then, the whole Mailtrap team and I have been trying to explain that it’s a completely different thing from the fake SMTP trap most people know us for.

That trap is Email Sandbox: a virtual inbox that catches email before it reaches recipients.

Production Email API/SMTP is the other product, the one that delivers emails to your customers’ inboxes.

So now, we need to have a conversation and try, once again, to clear things up.

I’ll show you what each product does, where they overlap, and why one can’t replace the other.

TL;DR: Email API/SMTP (live sending) vs Email Sandbox

• Live sending Email API/SMTP sends production emails to recipients, both transactional (password resets, account confirmations, etc.) and bulk (product updates, terms of service updates, etc.).
• Email Sandbox captures test emails in a fake inbox that never leaves Mailtrap.
• If you’re sending live password resets, receipts, or bulk emails, you need live sending Email API/SMTP.
• If you’re still building or QA-testing email code, you need Email Sandbox. Most accounts I've seen end up running both.

Capability	Email API/SMTP (live sending)	Email Sandbox
What happens to the email	Delivered to the recipient's mail server	Captured in a fake inbox, never delivered
How you plug it in	Live SMTP relay, or the Sending API with sandbox: false	Fake SMTP credentials, or the same Sending API with sandbox: true
Deliverability management	Dedicated IPs with auto warm-up, reputation monitoring with critical alerts, DNS setup	HTML/CSS check, email client preview, spam score (SpamAssassin), blacklist report
Inspecting a message	Email logs: what was sent, to whom, and all the delivery events tracked	Raw headers, source, encoding
Performance data	Real-time opens, clicks, bounces, spam complaints	None
Automated reactions	Webhooks on delivery, bounce, and spam events	None
Receiving mail	Inbound: parses real incoming mail into structured JSON	Sandbox catches whatever your app sends
AI agent access (MCP)	Send and receive email as an agent or human	Send test mail, inspect it, check spam score through MCP
Setup required	Verified sending domain, SPF/DKIM/DMARC, and a compliance check	None: no domain, no DNS, no verification
Free tier	4,000 emails/month, no credit card required	50 test emails/month, forever

Where your emails actually go (and no, it’s not the Neverland)

Sandbox is, structurally, a mail slot that opens onto a brick wall. Something goes in, nothing comes out the other side, on purpose.

Whether you point it at a fake address or a real one, Email Sandbox traps every message on Mailtrap’s server before it goes anywhere.

It’s literally built to guarantee nothing reaches a real inbox.

Email API/SMTP is the opposite of a brick wall: a live Email API/SMTP server delivers the email to the recipient's mail server, and it lands where you told it to.

You send it to [e-mail], and your beloved corgi will get it (not sure it will be able to read it, but it WILL get it) – simple as that.

How I decide between Email API/SMTP (live sending) and Email Sandbox

There’s one very simple rule that I use to decide between live sending Email API/SMTP and Email Sandbox: everything on the Sandbox side happens before a customer is involved.

Everything on the Email API/SMTP side happens because one is.

If you need to...	Use...
Build or debug an email template	Email Sandbox
Run CI/CD or QA regression suites that trigger email	Email Sandbox
Check spam score or cross-client HTML rendering	Email Sandbox
Send password resets, receipts, or 2FA codes	Email API/SMTP (Transactional Stream)
Send a bulk campaign or newsletter	Email API/SMTP (Bulk Stream)
Pull open, click, or bounce analytics	Email API/SMTP
Give an AI agent the ability to send or receive email	Email API/SMTP, via Mailtrap MCP

What you need to get started with Email API/SMTP (live sending) and Email Sandbox

Sandbox needs nothing beyond a Mailtrap account: no domain, no DNS, and no verification.

You could go from "I just signed up" to "I'm testing my welcome email" in about ninety seconds.

Going live is a different kind of morning. You need to verify a sending domain before Email API/SMTP will send anything. I won't pretend this part is fun. It isn't. But it's also pretty simple and quick.

It’s an industry standard, as mailbox providers like Gmail, Outlook, and Yahoo only trust mail from a domain that's proven it owns the sending address.

A fake inbox doesn't need that trust, because nothing leaves Mailtrap in the first place.

Sandbox toolkit vs Live sending toolkit: what you get when you use Mailtrap

When I’m knee-deep in a broken template and need to test emails in Email Sandbox, here are the features I usually reach for.

First, I turn to a template inspector because I need to know whether variables are rendered or would show up as {{first_name}} in someone's inbox if I were sending it to my users.

So I check the Tech Info tab, look for all the variables I’ve used, then check the rendering.

Then I move to the Device Previews, which show me what my email would look like in different email clients and on different devices.

I never skip this step, because I’ve had too many emails get completely destroyed by Outlook’s rendering engine.

I also check HTML/CSS to see the market support for the elements I’m using and fix them if needed.

(Ok, I’ll admit, my obsession with dogs is getting a bit out of hand.)

Another check I like to run before moving to production is the Spam Analysis and Blacklist report, which catches issues that tank inbox placement before they become a problem.

With Email Sandbox, you can also run load testing to inspect failures or unexpected behavior when sending emails at scale, run CI/CD or QA regression suites that trigger emails, or inspect your app’s response to bounces.

When all the tests are done, and I’m ready to send emails to recipients, the question stops being "does this look right" and becomes "did this arrive," so I switch to live sending Email API/SMTP and its toolset.

I look at the real-time dashboard for opens, clicks, bounces, and spam complaints so I can catch a dip in engagement before it turns into a pattern I have to explain to someone.

I also look at mailbox provider breakdown, because deliverability can be a provider-specific problem rather than a broad issue.

Then, I review logs for that specific provider and find the root cause.

Detailed email logs matter when a specific customer says they never got their password reset: I need to trace exactly what was sent and to whom, not just trust that the API call returned success.

I have webhooks set up for delivery and bounce events so my app can react in real time instead of me checking a dashboard manually, syncing opens, bounces, and spam reports straight back into my own system.

I actively watch the Reputation Monitoring dashboard too, so I can fix deliverability issues before they get serious.

And in the background, I rely on dedicated IPs and sending infrastructure built to deliver emails to the inbox.

By now you can see the pattern - I need both Email Sandbox and live Email API/SMTP workflows - they just come into play at different stages of email development.

But Email Sandbox can never replace live Email API/SMTP for anything customer-facing.

AI agents need both Email Sandbox and live Email API/SMTP

AI agents are where I get the most questions, usually from people building with LangChain, CrewAI, or OpenClaw who assume "email for agents" is one single feature.

It isn't, for the same reason nothing else in this piece is one thing: your agent needs a way to send and receive emails, and draft replies safely.

Mailtrap MCP server plugs both products into whatever AI agent you're using.

With live Email API/SMTP, an AI agent can send emails, pull delivery stats, read logs, manage sending domains, receive replies, and handle template workflows - the same production toolset I use myself, just called by the agent instead of me.

With Email Sandbox, your agent can send itself a test email, check the spam score, and read back what it just wrote, all without a real inbox anywhere near it.

The main rule for agents is the same as with human teams: draft goes to Email Sandbox first, gets checked, either by a script or by me, and only then goes out live.

We’re not tolerating any hallucinations over here.

What you pay and what you get: Email Sandbox vs live Email API/SMTP

As of 2026, Email API/SMTP's free plan covers 4,000 emails a month, requires no card, and is generous enough to run a small app's entire transactional load without paying anything.

Paid plans start at $15 for 10,000 emails/month and scale by volume and features, with dedicated IPs on higher tiers.

Sandbox is free forever for the basics: 50 test emails a month, no card and no expiration date lurking in the fine print.

Paid plans start at $17 and add team features like shared projects and higher limits.

Exact numbers past the free tier shift with plan features, not just volume, so I'd rather send you to Mailtrap's pricing page for the current breakdown.

Email Sandbox + live Email API/SMTP: the ideal end-to-end email experience

Build and debug templates in Email Sandbox, point all your lower environments there, and run your CI/CD tests against sandbox emails.

Nobody's inbox gets touched, which is the entire point.

Once you're ready, set up the domain you'll use for live sending and switch your live environments over to Email API/SMTP.

If you're using one of Mailtrap's SDKs, this really is one config change:

// Sandbox (testing)
const client = new MailtrapClient({
  token: process.env.MAILTRAP_API_KEY,
  sandbox: true,
  testInboxId: process.env.MAILTRAP_INBOX_ID,
});

// Live sending
const client = new MailtrapClient({
  token: process.env.MAILTRAP_API_KEY,
  sandbox: false,
});

// This call doesn't change either way
client.send({
  from: { email: "[e-mail]" },
  to: [{ email: "[e-mail]" }],
  subject: "Welcome aboard",
  text: "Thanks for signing up.",
});

If you’re calling the API directly instead of using an SDK, the config flip becomes a different endpoint:

• Sandbox mail goes to sandbox.api.mailtrap.io/api/send/{inbox_id}
• Live mail goes to send.api.mailtrap.io/api/send
• Bulk mail goes to bulk.api.mailtrap.io/api/send

Same request body, different URL.

Once live, I'd check my stats and sender reputation periodically rather than assume deliverability takes care of itself, because it doesn't, not on autopilot.

Final verdict: do you need live Email API/SMTP, Email Sandbox, or both?

At this point, you probably already know the answer.

I work at Mailtrap, so of course I’ll tell you you need both.

But if you absolutely have to choose between the two:

• Email Sandbox is strictly for testing: templates in progress, CI runs, load testing, bounce emulation, etc.
• Live Email API/SMTP is strictly for sending: password resets, privacy policy updates, seasonal campaigns, or any workflows where the real person is on the other end.

You get the best results when you use both (and this is as objective as possible).

FAQ

How many free emails does Email API/SMTP (live sending) include?

4,000 a month, no credit card required to start.

Can Email Sandbox send emails to real recipients?

No, and that's by design.

The only workaround is manual or auto-forwarding a specific captured message to an address you've already confirmed; everything else stays trapped.

Do I need live Email API/SMTP if I already use Email Sandbox?

Yes.

Live Email API/SMTP is the only one of the two that actually delivers to a real recipient, and having Sandbox already set up doesn't change that.

Running both is the setup I'd recommend anyway, since testing in Email Sandbox before sending through live Email API/SMTP means fewer production issues than skipping straight to live traffic.

Consider it a bonus on top of the main point: delivery is Email API/SMTP's job alone.

How do I move from Email Sandbox to Email API/SMTP in production?

Verify a sending domain (DNS records: SPF, DKIM, DMARC), then swap your Sandbox credentials for your live API token or SMTP username and password.

Be honest: when you hear “Mailtrap,” do you still think “email testing tool,” or did you already know it sends production emails too?