KoltrixMerging Email After Acquiring a Small Product
Buying a small SaaS product means inheriting its domains, senders and lifecycle emails. A practical plan for taking over its email without breaking anything.
On this page(8 sections)
- Before closing: ask for the email inventory
- Week one: secure, don't change
- Weeks two to four: map what's actually there
- Find every sender
- List every automated email
- Find where replies go
- Tell customers, carefully
- Decide: keep separate, or merge?
- Merging, step by step
- A post-acquisition email checklist
- Key takeaways
Small SaaS acquisitions are increasingly common: a founder sells a side project, a company buys a complementary tool, an operator picks up a profitable product from a marketplace. The code and the customers transfer at closing. The email setup usually transfers as a pile of credentials and a seller saying "I think that's everything."
It's rarely everything. This guide covers how to take over an acquired product's email, from the first week of discovery to the eventual merge, without breaking the receipts and password resets its customers depend on.
Before closing: ask for the email inventory
If you can, get answers before the deal closes. Add these to your due-diligence list:
- Which domains does the product use for email? Including subdomains like
mail.ornotify.. - Who is the registrar, and whose account is the domain in? A domain registered to the seller's personal account is a transfer task, not a footnote.
- Where is DNS hosted?
- Which services send email as the product's domain? Mailbox host, transactional API, newsletter tool, help desk, billing, CRM.
- Which addresses receive customer mail, and who reads them?
- What automated emails does the product send, and where are the templates?
- Is there a suppression list, and can it be exported?
A seller who can answer all of these quickly has probably run a tidy operation. Vague answers tell you where to budget time.
Week one: secure, don't change
The first priority after closing is control, not consolidation. Make sure you can't be locked out, and that nothing stops working.
- Transfer the domain to a registrar account you control, or at minimum change the account's login email, password and two-factor authentication. Turn on auto-renew.
- Take over DNS hosting credentials the same way.
- Rotate every email-related credential: mailbox passwords, API keys, SMTP credentials, webhook secrets. The seller and any former contractors shouldn't retain working access.
- Check for forwarding rules on mailboxes that send copies to the seller's personal address.
- Update the account contact email on every email vendor to an address you control.
- Don't change MX records, SPF or sending providers yet. You don't yet know what depends on them.
Weeks two to four: map what's actually there
Now build a real picture. The seller's list is a starting point, not the truth.
Find every sender
Look at the domain's SPF record, its DKIM selectors and, ideally, DMARC aggregate reports. If the domain doesn't publish DMARC with a reporting address, add a monitoring-only record so reports start arriving:
_dmarc.acquired-product.example TXT "v=DMARC1; p=none; rua=mailto:[email protected]"The domains are placeholders. After a week or two, the reports show which services actually send as the domain, including ones nobody mentioned. Our guide to inventorying everything that sends as you covers this in more detail.
List every automated email
Go through the product's code and every connected tool, and list each automated email: trigger, template location, sending service, from address and reply-to. Acquired products often have emails nobody remembers, such as a trial reminder in an old automation tool or a weekly report sent by a cron job on a forgotten server.
Find where replies go
For each address customers write to or reply to, confirm a person on your team now reads it. Customer replies sitting unread in a mailbox only the seller checked are the most common early failure in a small acquisition.
Tell customers, carefully
Customers should hear about the change from you, plainly, before they notice something different. A short email from the product's existing domain works best:
- What's changing, in one sentence (the product now belongs to your company).
- What isn't changing: their account, data, billing and support address, at least for now.
- Who to contact.
- When to expect any visible changes, such as a new sender name or domain.
Avoid sending it from a brand-new domain customers don't recognize. A surprise email from an unfamiliar domain announcing that someone else now has their data looks exactly like phishing.
Decide: keep separate, or merge?
Once the inventory is done, decide on the long-term setup. Neither answer is always right.
| Keep the product's email separate | Merge into your main email stack |
|---|---|
| The product keeps its own brand | The product is being folded into your brand |
| Its customers are a different audience | Customers overlap with yours |
| Its sending reputation is good and independent | Its setup is messy and easier to rebuild |
| Low ongoing maintenance | You want one stack to maintain |
Many acquirers keep the domain and brand but move the infrastructure onto their own providers, so day-to-day operations live in one place while customers see no change.
Merging, step by step
If you merge, follow the same order as any migration:
- Authenticate the acquired domain on your providers, in parallel with the existing setup. SPF can include both during the transition, within the limit of 10 DNS lookups.
- Move application sending first, one email type at a time, starting with low-stakes notifications. Import the old suppression list before sending anything.
- Move shared addresses and mailboxes, then change MX on a quiet day with a low TTL set in advance. Our Google Workspace cut-over checklist shows the order of operations.
- Retire old services once traffic has moved: remove SPF includes and DKIM records, cancel subscriptions, export anything you need to keep.
- Tighten DMARC to an enforcing policy once reports show only legitimate senders.
If the acquired product moves onto a provider that hosts multiple domains in one workspace, the support team can handle both products' mail from a single inbox without either brand's addresses changing.
A post-acquisition email checklist
- Domain transferred or registrar account secured, auto-renew on
- DNS hosting credentials taken over
- All email credentials, API keys and webhook secrets rotated
- Seller forwarding rules removed
- DMARC reporting enabled; all senders identified
- Every automated email listed with its trigger and sender
- Every customer-facing address read by someone on your team
- Customers told, from the familiar domain
- Keep-or-merge decision made and written down
- Old services retired and DNS cleaned up after any merge
Key takeaways
- Ask for the email inventory during due diligence, and expect it to be incomplete.
- In week one, secure domains and credentials but change nothing that delivers mail.
- Use DMARC reports and the codebase to find every sender and every automated email.
- Tell customers from the domain they already know, then decide deliberately whether to keep the product's email separate or merge it.
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.
