We outgrew Mailpit: why we built MailBench

For a long time, Mailpit did the job for us. It ran on one node in our office development VPC, every app we built pointed its SMTP there, and any developer on the network could see what was sent. Simple, and it worked.

Then clients got involved.

When we started putting staging builds in front of clients for testing, the setup stopped working. A client testing a signup flow needs to see the verification email, and they can’t see it if the inbox lives inside our VPN. Opening it to the internet without auth wasn’t an option either. Some of our clients are very careful about signup emails, because staging data often contains real names and real addresses, and an open shared inbox exposes all of it. What we needed was a shared inbox with authentication, where the right people see the right emails and nobody else does.

Why not use something that exists?

We looked at the market first: who the leader is, who follows, and how crowded it is. The hosted tools are polished but get expensive as teams and volume grow. The self-hosted ones are great (Mailpit deserves real credit here) but weren’t built around teams, shared access, or clients. And may be have some more control over one or two things we wanted for our own.

We also wanted something none of them offered: first-class support for AI code editors. More of our development now happens with an AI assistant in the editor. If the assistant writes a signup flow, it should be able to trigger it, read the verification email, and confirm it works without a human copying a link. MailBench supports MCP for exactly this.

After some debate in the team, we decided to build it. This wasn’t meant to be a weekend project. We wanted to do it properly, and learn email in more depth along the way.

The feature we didn’t ship (yet)

Early on, we planned to add a relay feature, so that emails caught in the sandbox could optionally be forwarded to real addresses. It sounds useful, and it is.

Then a friend who works on a support desk product told us what happened to theirs. Spammers found the relay and used it to send spam. Cleaning up the reputation damage took far longer than building the feature had.

We haven’t been through that ourselves, and we’d like to keep it that way. So we’re treating any feature that can send mail to the outside world as a security risk first and a feature second. So for now, this feature of relaying is not shipped because we are new to the scene, domain reputation is important. May be in near future we can add that.

Building this also taught us how many ways email can go wrong: spoofed headers, oversized messages, signup floods, open-relay probing. Thinking through those cases early shaped how we built MailBench.

Why Go

The short answer is that Go already has most of what we needed. The standard library and the ecosystem cover networking and SMTP well, so we were mostly assembling parts and not inventing them. A Go service deploys as a single binary, uses little memory, and handles many connections comfortably.

We’ll write up the full stack in a follow-up post.

Try it

The free plan includes 2,500 emails per month, with team support and MCP access.

SMTP host: [your-host]
Port:      [port]
Username:  [your inbox username]
Password:  [your inbox password]

Sign up

If something is missing or broken, tell me. Questions and feedback are welcome in the comments, and I’ll answer every one.