Email for a Product Portfolio: One Inbox, One Bill, the Setup That Works

Email for a product portfolio works best as one inbox and one bill: every domain you own, every address on those domains, delivering into a single mailbox you actually read, on a plan that charges per person instead of per domain or per address. The alternative, one mail plan per product, is how most founders end up with four admin consoles, four bills, and a support@ somewhere they stopped checking months ago. This is the setup we run ourselves, and the piece below is the operator's version: the failure modes, the fix, and the honest costs both ways.

We make SuperMailOS. It is literally this product, born from this problem: every product's email, one inbox, one bill. So read the pattern first, because it works with any host that supports aliases and multiple domains.

How the per-domain stack fails

The default trajectory for a founder shipping their third product:

1. First product: a mail plan. Fine.
2. Second product: another plan, because the first was per-domain. Now two logins.
3. Third and fourth: forwarding everything into Gmail, replying as the wrong address, losing the professional From: on the domain that matters most.
4. Somewhere in there, DNS for one domain rots, a renewal quietly lapses, and mail bounces for a week before anyone notices.

Each step was locally rational. The stack is globally bad. The cost is not only the money, which is real: per-person billing across four plans for the same human, roughly $22 a month in the comparison table on our homepage, versus one Business bill. The deeper cost is attention: every console is a place deliverability can fail silently, and every forwarding hop is a place mail can disappear.

The one-inbox pattern

The fix is architectural, not budgetary:

• One mailbox per person. You. Maybe a support hire later. Storage, login, and bill attach to mailboxes only.
• Every domain connected to that mailbox's account. Each product domain you own, added once, with MX and the authentication records pointed at one host.
• Addresses, not accounts. On each domain, create the handful of addresses the world will use: hello@, support@, security@ for the products that need the signal, press@ if press will ever write. Each is an alias delivering into the one inbox.
• Reply as the address it arrived on. This is the load-bearing feature: the pattern collapses if support@productb.com replies as founder@gmail.com. In SuperMailOS you reply as any address on any domain, from the one inbox.

The per-address philosophy and its spam implications are covered in catch-all vs email aliases and catch-all email spam risk: chosen aliases, unknown addresses bounce.

What it costs, honestly

Running four product domains the old way, per person: roughly a Workspace seat here, a Zoho seat there, a Fastmail seat elsewhere; the worked example on our homepage totals $22 per person per month across four example plans. The one-inbox way: Pro at $3 per mailbox monthly covers up to 3 domains; Business at $5 adds unlimited domains and both include unlimited free aliases, DKIM on every message, and DMARC reporting. If you are a team that lives inside one big suite, the crossover math can favor staying; the pricing-model comparison works through when.

The setup, end to end

Adding a domain should take minutes, and with us it does: add the domain, the DNS records come from the mail server's own zone (one click on Cloudflare, DigitalOcean, Linode, Vultr, Hetzner, Spaceship; copy-paste anywhere else), watch live verification, tap the addresses you want. An unverified domain never sends, which is the guarantee that protects every product's reputation at once. The longer architectural view, including the forwarding-based variants and their trade-offs, is in one inbox for multiple domains; the operator-level checklist lives in email hosting for multiple domains, and the agencies use case shows the client-domain version.

Frequently asked questions

How do I handle email for multiple products?

Connect every product domain to one mail account, create the addresses each product needs as aliases, and read them all in one inbox with reply-as-any-address. Avoid one-plan-per-domain; it multiplies bills, consoles, and silent failure points.

Does one inbox mean one bill?

With the right host, yes: a per-person plan with unlimited domains and free aliases bills the people, not the products. SuperMailOS Business is exactly that shape.

What if a product grows its own support team?

Graduate that domain's addresses to a second mailbox (a person) on the same account. The architecture scales by adding people, which is the thing you were paying for anyway.

Will one inbox mix everything up?

No, if labels and search do their job. Thread views, per-domain labels, and instant search replace the mental overhead of five logins with one inbox's filters. The failure to avoid is forwarding into a personal Gmail, which loses reply-as and deliverability control.