Every project eventually needs a place to catch outbound mail during development that is not a real inbox. Three tools dominate the space, and one of them is quietly unmaintained. The numbers make the decision easier than the marketing does.
The three candidates, with receipts
- MailHog — 16,191 GitHub stars, written in Go, MIT. Its latest release is v1.0.1, published 11 August 2020. That is six years without a release, and the star count reflects a decade of accumulated recommendations rather than current activity.
- Mailpit — 10,738 stars, Go, MIT. Latest release v1.32.0, published 22 October 2026. Actively maintained, and it exposes a documented HTTP API including
/api/v1/send. - Maildev — 6,148 stars, Node.js. The SMTP server plus web interface combination that most Node projects adopt by default.
Those figures are from the GitHub API on 24 October 2026. The gap that matters is not stars, it is the release date column.
Why MailHog's popularity is a trap
MailHog became the default answer because for years it was the best answer, and blog posts from that era still rank. A team adopting it today inherits a tool with no security releases, no upstream fixes, and no maintainer responding to issues. It still works, which is exactly why the trap is effective: nothing breaks on day one, so nobody looks at the release page.
The honest framing is not "MailHog is bad." It is that a dependency you cannot get a patch for is a liability you accept on purpose or not at all. For a tool that sits in a developer loop and sometimes in CI, that is usually not a deliberate choice.
What actually differs in practice
All three do the core job: accept SMTP, hold messages, show them in a UI. The differences that bite are the ones a spec sheet does not list.
- API surface. An API means tests can assert on messages programmatically instead of scraping an interface. Mailpit documents one. This matters the moment you want to check that your app sent three messages in a specific order without a human watching a browser tab.
- Message volume behaviour. A sink that keeps everything forever becomes a memory issue in a long-lived CI container. Retention limits are a feature.
- Runtime cost. A Go binary is one process. A Node tool needs the Node runtime present in whatever image you build.
Where a local sink stops being enough
A local sink proves your application sent mail. It cannot prove the mail arrives at an external address, because nothing external was involved. The moment you test a signup flow that depends on receiving a real confirmation, a local sink is the wrong instrument — it is verifying the sending side against itself.
That is the boundary between a sink and a disposable inbox. Mailpit and friends are for "did my app call SMTP with the right payload." A disposable inbox with a real MX and a poll API is for "did the message actually traverse the internet and can a consumer read the code out of it." Both are legitimate, and neither substitutes for the other. Inboxmil runs the second kind: real domains, real MX records, and retention measured in hours rather than forever.
The takeaway
For a new project in October 2026, Mailpit is the defensible default: actively released, MIT, single binary, documented API. MailHog is the choice you make if you are already running it and have decided the maintenance risk is acceptable. Maildev remains reasonable inside a Node-only stack. Whichever you pick, check the release page before you adopt it, because star counts measure the past.