KoltrixRunning Email for Two Products From One Small Team
Two products, one small team: separate domains and reputations, shared access, distinct senders and support routing, without doubling your email work.
On this page(7 sections)
Small teams end up running two products more often than you'd expect: a side project that started earning money, an acquired tool, a spin-off for a different market. The code is usually manageable. Email is where it gets messy, because each product needs its own identity to customers while the same three people answer everything.
The goal is simple to state: customers of each product should experience it as its own company, while your team works from one place.
Separate domains, separate reputations
Each product should send from its own domain. This isn't just branding. Mailbox providers build reputation per domain, so separating them means a problem with one product can't drag down the other.
Think about what can go wrong: a bug in Product A sends a burst of duplicate notifications, complaints spike, and its domain's reputation drops for a while. If Product B shares that domain, its password resets start landing in spam too, for reasons its customers can't see and its team didn't cause.
For each product domain, set up:
- SPF authorizing the services that send for that product
- DKIM signing with a key for that domain
- A DMARC policy, ideally moving toward enforcement
- MX records if the product receives mail (support replies, inbound addresses)
If you're on Koltrix, each domain gets its own records, including a per-domain DKIM key, through the same setup wizard. The Starter plan includes two domains and Pro includes ten, so a two-product team fits on either. Use our MX lookup to confirm what each domain currently publishes.
Subdomains vs separate domains
If the second product is truly part of the first, such as a companion tool for the same customers under the same brand, a subdomain like tools.yourapp.example can make sense. Subdomains have their own reputation to a degree, but they're still associated with the parent domain.
If the products have different names, different customers or different risk profiles, use separate registered domains. When in doubt, separate. Merging later is easier than untangling a shared reputation.
One team, shared access
The trap is creating a separate set of personal mailboxes for each product and asking everyone to check them all. That doubles logins, splits customer history, and guarantees something gets missed.
A better pattern:
| Address | Product | Who has access |
|---|---|---|
[email protected] |
A | Everyone who does support |
[email protected] |
B | Everyone who does support |
[email protected] |
A | Founders, finance |
[email protected] |
B | Founders, finance |
[email protected] |
A | Founders |
| Personal addresses | Primary product only | Each person |
Shared addresses for each product, with per-person access, all visible from one inbox. Personal addresses only on the product each person mainly represents, unless there's a real reason for two.
Make sure each shared address is clearly labeled in your inbox so it's obvious which product a conversation belongs to before anyone replies. Labels or auto-label rules by recipient address work well for this.
Keep senders and signatures distinct
Customers should never get a reply that mixes the two products. Check:
- From addresses. Replies to a Product B customer go from a Product B address. Most shared inbox tools reply from the address the message was sent to by default. Confirm yours does.
- Signatures. Set a signature per address, not per person, so a support reply always carries the right product name and links.
- Canned replies. Keep separate sets, or use variables for product names and links. A reply recommending Product A's settings page to a Product B customer is an easy mistake.
- Transactional email. Each product's app should send from its own domain with its own templates. Use separate API keys per product so you can rotate or revoke one without touching the other.
Route support by product
Decide how each product's support works:
- Same team, same hours is simplest for small teams. Just make the product obvious in every conversation.
- Different response expectations may make sense if one product has paying business customers and the other is a free tool. Write the difference down so nobody has to guess.
- Separate help docs for each product, linked from that product's emails and auto-replies.
Watch for customers who use both products. They may email one address about the other product. Answer the question rather than redirecting them, and note it in the thread.
Billing and vendor accounts
Decide early whether the products share vendor accounts or have separate ones. Sharing one email workspace is efficient: one bill, one admin console, one place to manage access. Separate accounts make sense if you might sell one product, bring in a partner, or need cleanly separated costs.
If selling a product later is a realistic possibility, keep its domain registration, DNS and any product-specific services in a way you could transfer cleanly. Disentangling shared accounts during a sale is slow and stressful.
A setup checklist
- Separate domain (or deliberate subdomain) for each product
- SPF, DKIM and DMARC configured and verified for each domain
- Shared support and billing addresses per product, with per-person access
- Labels or rules that make the product obvious on every conversation
- Signatures set per address, not per person
- Canned replies separated or parameterized by product
- Separate API keys and templates for each product's transactional email
- Domain registrations documented in a way that could be transferred
Key takeaways
- Give each product its own domain so reputation problems stay contained.
- Use shared addresses per product with per-person access, all in one inbox, instead of separate mailboxes everyone has to check.
- Set signatures, canned replies and API keys per product, so customers never see the two mixed.
- Keep each product's domain and services transferable if a sale or spin-off is plausible.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
