SMTP, IMAP, and a parser get an agent sending in a day. The next six months are the reason this product exists.
Do it yourself · Building it yourself claims checked July 2026
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.
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.
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.
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.
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.
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.
Every row is a claim we could defend with their documentation open beside it. Where they are ahead, the row says so.
Do it in this order. The parts that look boring are the parts that decide whether it survives contact with real recipients.
Sending, then receiving
An afternoon for the first send. A fortnight for MX, parsing, and storage that does not lose attachments.
Threading and identity
Header linkage with fallbacks, then a mailbox model with keys scoped per agent.
Abuse controls before launch
Suppression, bounce and complaint tripwires, velocity limits, and a kill switch. Not after the first incident.
The surfaces you forgot
Search, retention, an oversight UI, and the MCP server. Budget as long again as everything above.
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.
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.
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.
Not today. Enterprise arrangements around dedicated infrastructure are a conversation, but there is no self-hosted distribution.
You can build all of this. The question is whether email plumbing is what your team should be spending the next quarter on.
The free tier is 3,000 emails a month across three agent inboxes, no card, with receiving, threading, and search included. Enough to watch a real conversation happen before you decide.