Three names come up in every conversation about catching test mail, but they answer different questions. Mailpit is a tool you run yourself. MailHog is the tool it replaced. Mailtrap is a service you pay for (or use on a metered free tier). None of them is “the best” in the abstract — the right answer depends on two things: who should run the thing, and where the test data is allowed to live.
Side by side
| Mailpit | MailHog | Mailtrap (and other hosted sandboxes) | |
|---|---|---|---|
| Who runs it | you: single binary or container | you (no longer maintained) | the vendor |
| Status | actively developed | unmaintained for years | commercial service |
| Cost | free (MIT) | free (MIT) | free tier, then per message / inbox / user |
| Where the mail lives | your host | your host | vendor servers |
| SMTP / UI ports | 1025 / 8025 | 1025 / 8025 | a vendor-provided host and port |
| API | REST API, live web sockets | JSON API | API key, vendor-specific |
| Message tooling | HTML, link and spam checks, search, screenshots, tagging | basic list and view | depends on the plan |
| Extra protocols | optional POP3, SMTP relay and forwarding | release to a real SMTP server | n/a |
| Retention | automatic pruning (500 messages by default, configurable) | in memory, MongoDB or files | per the plan |
| Team features | none — it is a local tool | none | shared inboxes, roles, SSO, audit (paid) |
| Webhook capture | no | no | usually no |
| Maintenance | you | you (and nobody upstream) | the vendor |
Where each one wins
- Mailpit — when the mail must stay on infrastructure you control, and you are fine with a container or a static binary. It is the modern default for local development and CI, it has an API for assertions, and its checks (HTML rendering, links, spam score) catch the mistakes that screenshots do not.
- MailHog — only when it already runs and nobody wants to change anything this quarter. Mailpit uses the same default ports, so the migration is an image swap: see MailHog alternative: what to use instead.
- Mailtrap and the commercial sandboxes — when someone else must run it: shared inboxes for a team, SSO, an audit log, a support contract and an SLA. That is what you are paying for, and it is a legitimate reason. The trade-offs are metering, vendor policy on your test data, and an account for every developer.
- This instance — a middle path: SMTP and webhook capture on one address, no metering, nothing to maintain, read-only share links, and a JSON export so scripts and AI assistants can read what was captured. Not self-hostable, which is the whole point of the trade.
Two questions decide it
- Do you want to run it? Yes → Mailpit (or smtp4dev on .NET). No → a hosted option: this instance, or a commercial sandbox if you need team features and a contract.
- Must the test data stay inside your infrastructure? Yes → Mailpit, on your own host. No → a hosted option is the cheaper answer, including in maintenance time.
If the answer to the second question is “yes” and to the first is “no”, then the requirement is contradictory: a hosted service cannot guarantee that test payloads never leave your perimeter. It is better to notice that before the migration.
Where the webhooks go
None of the three catches HTTP callbacks: Mailpit and MailHog speak SMTP only, and hosted mail sandboxes stay in the mail world. If half of your debugging is Stripe, GitHub or Telegram callbacks, you need a catcher for those too — see How to test webhooks locally without ngrok.
Next steps
- MailHog alternative: what to use instead in 2026 — the migration path, in detail.
- Mailtrap alternatives: free, open-source and self-hosted options — the full list, including Mailcatcher and MailDev.
- How to test email sending without sending anything — set up any of them in four steps.