October 21, 2026 · 5 min read
Hosting multiple domains on one mail server (without burning them)
1 domain, 1 instance, 3 mailboxes is the safe default. When you can pack 2 domains on one server, and when custom SMTP/IMAP overrides are the better call.
A question we get constantly: do I really need a whole server for every domain? The honest answer is no — but the caveats matter more than the headline.
The safe default
sendzy's default allocation is one private server per domain, with three mailboxes on it. Why: reputation isolation. If one domain's campaign goes sideways, the blast radius is exactly one domain on one box. You delete, re-register, move on. Nothing else on your sending roster is touched.
When sharing an instance is fine
- Both domains are yours and both send to similar audiences at similar volume.
- Combined daily volume stays modest — think dozens of messages per mailbox, not hundreds.
- You monitor bounce rates per domain and stop on spikes.
Under those conditions, two domains on one instance halves your infrastructure cost with no practical downside. sendzy allows this by default: an instance hosts up to two domains before a new one is provisioned.
When you should never share
- Different verticals or geographies — a spam trap hit on one list shouldn't contaminate the other program.
- One domain sends cold outreach while the other handles replies and support.
- Volume is high enough that rate limits on a single IP become the bottleneck.
Bring your own infrastructure
Every sendzy mailbox exposes its SMTP and IMAP host and port. If you already run mail infrastructure — on-prem or with another provider — point the mailbox at your own hosts via the API:
curl -X PATCH https://app.sendzy.dev/api/mailboxes/mbx_123 \
-H "X-Api-Key: sk_yourkey.yoursecret" \
-H "Content-Type: application/json" \
-d '{
"smtp_host": "mail.yourdomain.com",
"smtp_port": 587,
"imap_host": "mail.yourdomain.com",
"imap_port": 993
}'The console and the API still work identically — campaign routing, round-robin, threads — your servers just carry the mail. Infrastructure flexibility shouldn't be a religious argument; it should be a field in an API call.
Ready to send? Create your organization or browse the API docs.