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 manage
Own the inbox.Offload theserver.
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.com/inbox
Inbox3 open
Open
ProductQuestion about multi-domain setup
support@northstar.studio Inboxrule: support-primary
Your domains Your data model Your reply identity Proven delivery underneath
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.
Swap the transport layer
Move between delivery providers at the adapter boundary. Your routes, message history, and product workflow do not move with it.
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 countEvery domain you own.
Every domain you own.
One flat fee.
MailPiston is the control plane. You bring your own mail provider account, so your sending reputation, your send quota and your provider bill stay yours — and adding a domain costs you nothing here.
$0free, indefinitely
One verified domain with the full inbox — enough to run the mail for a single product or an org address.
- One domain, unlimited addresses
- Threads, routing, and reply relay
- Signed webhooks and the full API
Unlimited domains
$6/ month · indicative
Every domain you manage in one inbox, for the same price whether that is two or twenty.
- Unlimited domains and addresses
- One inbox across all of them
- Metered on messages, never on domains
At cost
Mail transport is bought from a specialist and paid for directly. We never mark it up, because we never touch it.
- Your own provider account and token
- Your sending reputation, not a shared one
- Leave whenever — the domains are yours
Why nothing is priced per domain
Because domains are not what costs money. Storage and volume are, and those scale with the mail you actually receive — so a second product, or a fifth, changes nothing on this bill. Providers that charge per domain make adding one a decision; here it is not.
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. Bind a verified personal-inbox endpoint, then enable replies on each source domain in Domains. MailPiston sends a notification from the managed address with an opaque Reply-To on that same domain. Your reply returns through MailPiston and leaves from the managed address. Forwarding pauses for a domain without that route.
Does this work for every domain I manage?
The same routing model works across multiple verified domains. Each domain still needs its own DNS and provider configuration, and each sending address needs a concrete provider alias; MailPiston shows and reconciles those records per domain.
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?
Messages, threads, routes, and events are stored in the Postgres database configured for this deployment. Attachment bytes—and raw MIME only when raw capture is enabled—use the configured object store. The provider adapter limits transport coupling, but a provider migration still requires implementation and validation work.
What does it actually cost to run?
A self-hosted deployment pays its mail provider, database, hosting, retry service, and any object storage directly. The exact total depends on the providers and message volume; MailPiston does not promise a fixed infrastructure price.