Alex Morganalex@fieldnotes.co
Hi there,
Can I connect two product domains and keep the conversations together, or would each address need a separate workspace?
Alex
Email control plane · every domain you manageOwn the inbox.
Own the inbox.
Offload the server.
MailPiston gives every address on every domain you manage a programmable, reply-ready inbox - while proven providers handle SMTP, MX, and delivery.
One control plane. Your domains, data, and reply identity.
mailpiston.vercel.app/inbox
Inbox3 open
Open
ProductQuestion about multi-domain setup
support@northstar.studio Inboxrule: support-primary
The better boundary
You should not have to choose between control and becoming an SMTP company.
Keep the parts that compound in value. Hand off the parts that demand a specialist network.
Keep the canonical record
Inbound and outbound mail live in one thread model you control - not scattered across private inboxes and provider dashboards.
Protect private identities
Forward a message to the mailbox you already use, then relay the reply through the public address your customer expects.
Route on your terms
Send each address to a webhook, a private inbox, a group, or a combination - without changing the underlying conversation.
A thread, not a forwarding trickReceive. Route. Reply.
Receive. Route. Reply.
Without losing the plot.
Provider events stop at an adapter boundary. Inside MailPiston, every message follows one stable model your application can understand.
message.received
Inbound, made legible.
A provider accepts the message. MailPiston verifies the event, stores the canonical message, and attaches it to the right conversation.
Thread createdMaximum ownership, sensibly placedOwn the control plane.
Own the control plane.
Rent the plumbing.
Infrastructure independence is not about cloning a provider. It is about keeping provider-specific details behind an adapter so your product and history remain yours.
“
As much ownership as possible from both worlds.
MailPiston owns
- Domains & addresses
- Threads & messages
- Routes & policies
- Reply authorization
- Application experience
clean adapter
Provider operates
- SMTP transport
- MX receiving
- Deliverability
- Reputation systems
- Abuse operations
Public identitysupport@yourdomain.comWhat your customer sees
signed relay
Private destinationyou@personal.comNever used as the visible sender
Familiar inbox, protected identity
Reply where you already work. Show only the address you chose.
Private forwarding becomes an operator interface - not an identity leak. MailPiston keeps the thread context and public sender between your customer and your personal mailbox.
- Signed, expiring reply authorization
- Header rewriting and loop prevention
- One audit trail for received and sent mail
Priced on volume, not domain countRun it yourself for nothing.
Run it yourself for nothing.
Or let us run it for you.
Every plan bills the same way underneath: a flat product fee, with provider, storage, and volume costs left visible instead of buried in a tier maze.
$0MailPiston product fee
Deploy the control plane on your own infrastructure and pay your providers directly, at their prices.
- Full application ownership
- Your database, your object storage
- Infrastructure costs stay visible
Hosted
$12/ month, billed yearly
The managed control plane, for operators who would rather not run the application layer themselves.
- Managed MailPiston workspace
- Multiple domains and reply identities
- Provider and usage costs billed at cost
Custom
Migration and configuration help for teams moving several domains or an existing mail flow across.
- Domain and route planning
- Provider migration support
- Custom integration review
The pricing principle
A simple base fee funds the managed product. Large provider, storage, and volume costs stay transparent rather than hidden inside a confusing tier maze - and nothing is priced per domain, because domains are not what costs money.
Clear before clever
The questions behind the architecture.
Mail infrastructure is already complicated. The product boundary should not be.
Is MailPiston another email delivery provider?
No. MailPiston is the control plane above a delivery provider. It owns your application workflow, identities, routes, messages, and threads while a specialist handles SMTP, MX, spam filtering, and delivery operations.
Can I receive support mail and reply from my personal inbox?
Yes - it is the workflow MailPiston is built around. It forwards the message to your private destination, then turns your authorized reply into a thread-aware message from the public support identity. Header rewriting, signed reply tokens, loop prevention, and strict sender matching keep your private address off the wire entirely.
Does this work for every domain I manage?
Yes. The architecture is domain-general and nothing in it scales with domain count. Once a domain and sending identity are verified, the same endpoint, routing, inbox, and reply concepts apply across all of its addresses.
Do I have to self-host the mail infrastructure?
No. The point is to own the valuable control layer without becoming a mail operator. MailPiston uses established providers for the hard transport work, behind a boundary that stays replaceable - no controller, component, or repository knows which provider is underneath.
What happens if I want to leave, or switch provider?
Your messages, threads, routes, and events are rows in your own Postgres database, and attachments are objects in your own bucket. Switching delivery providers means implementing one interface; leaving means taking a database with you.
What does it actually cost to run?
You pay your delivery provider, your database, and your object storage directly, at their prices. Enhanced Protection at Forward Email covers unlimited domains and aliases for a few dollars a month, so the bill tracks mail volume rather than how many domains you added.