# MCPmailer vs Building it yourself

SMTP, IMAP, and a parser get an agent sending in a day. The next six months are the reason this product exists.

Also searched as: build agent email infrastructure, self-hosted agent inbox, Postal Stalwart agent mail.

## What Building it yourself is

The self-hosted route is SES or Postal or Stalwart for transport, an IMAP or webhook path for inbound, a MIME parser, a Postgres table, and a cron job. Everything else on this page is, at bottom, a wrapper around roughly that, and we will not pretend otherwise.

## Where Building it yourself is the better choice

If email is your core product, or your data genuinely cannot leave your infrastructure, build it. You will understand your own pipeline better than any vendor can explain theirs, and Postal and Stalwart are good software run by people who care.

## Where MCPmailer differs

The day-one demo is easy and misleading. What follows is DKIM, SPF, and DMARC alignment on a subdomain; MIME parsing that survives real mail; threading across headers clients rewrite; bounce and complaint handling before a provider suspends you; suppression enforced on every send; quotas that tell a reply from cold outreach; a searchable store; per-agent keys; and an MCP server kept current with a spec that moves.

### Threading is the first thing to bite

In-Reply-To and References work until they do not: clients that strip them, mailing lists that rewrite them, replies that arrive with a quoted body and nothing else. Subject-based fallbacks then create their own false positives. This is a fortnight of edge cases and it never fully ends.

### Reputation is the project nobody scopes

SES suspends around 0.1% complaints or 5% bounces, account-wide, and other providers are similar. You need per-tenant metrics, pre-send suppression, tripwires that fire at a fraction of those numbers, velocity limits against a runaway agent, and somebody to answer when they trip. This is the work, and it is invisible until the week it is not.

### The surfaces after the pipeline

Then a searchable store, retention and pruning, per-agent keys, a dashboard a non-engineer can read, and an MCP server whose spec changed last quarter. We publish our own unfinished edges in PLAN.md, which is a fair preview of the list you would inherit.

## If you build it anyway

Do it in this order. The parts that look boring are the parts that decide whether it survives contact with real recipients.

1. **Sending, then receiving** An afternoon for the first send. A fortnight for MX, parsing, and storage that does not lose attachments.
2. **Threading and identity** Header linkage with fallbacks, then a mailbox model with keys scoped per agent.
3. **Abuse controls before launch** Suppression, bounce and complaint tripwires, velocity limits, and a kill switch. Not after the first incident.
4. **The surfaces you forgot** Search, retention, an oversight UI, and the MCP server. Budget as long again as everything above.

## Side by side (checked July 2026)

| | MCPmailer | Building it yourself |
| --- | --- | --- |
| Built for | Exactly this problem, so you do not have to make it your problem. | Whatever you build it for. |
| Inbox per agent | One mailbox per agent, created from the dashboard or the API, each with its own scoped key. | Yours to design. |
| Receiving and threading | MX, MIME parsing, and threading across In-Reply-To and References, including clients that mangle both. | Yours to build: MX, parsing, threading, storage. |
| MCP server | Maintained by us, including the parts of the spec that changed last quarter. | Yours to write, and to keep current with the spec. |
| Waiting for a reply | wait_for_reply long-polls the mailbox until the other side answers, up to five minutes per call. | Yours to build, including the long-poll and its timeouts. |
| Human oversight | A dashboard exists, which is the part nobody builds for themselves. | Yours to build, and the first thing to get cut. |
| Sending limits | Bounce and complaint tripwires that fire far below the thresholds that get a sender suspended. | Yours to enforce, and yours to answer for when a provider suspends you. |
| Your domain | Instant you.mcpmailer.email subdomain, then verify agents.yourcompany.com with a guided DNS wizard. | Full control, full responsibility. |
| Search | Full-text search across the workspace, exposed to the agent as search_inbox. | Yours to index. |
| Beyond the inbox | A shared contact book with per-contact memory, notes, an encrypted vault, and a public hostname per agent. | Whatever you build. |
| Free tier | 3,000 emails a month, 100 a day, 3 inboxes, no card. | Infrastructure cost plus engineering time. |
| Content privacy | We never read content. Self-hosting is still the only way to be certain. | Total, which is the real reason to do this. |

## Questions

### How long does it take to build agent email infrastructure?

Sending, an afternoon. Receiving, parsing, and threading, a fortnight or two. The abuse controls, per-tenant isolation, and the operational habit of keeping a sending reputation clean are the multi-month part, and they are not optional if strangers will read the mail.

### Is self-hosting cheaper?

In infrastructure, yes, substantially. In engineering time and account risk, usually not, until volume is high enough that the per-message difference pays a salary.

### What should I use if I do self-host?

SES or Postal or Stalwart for transport, a real MIME parser rather than a regex, Postgres with full-text search for the store, and object storage for raw MIME so you can always rebuild a thread.

### Can I self-host MCPmailer?

Not today. Enterprise arrangements around dedicated infrastructure are a conversation, but there is no self-hosted distribution.

All comparisons: https://mcpmailer.com/vs
Docs: https://mcpmailer.com/docs.md
Pricing: https://mcpmailer.com/pricing.md