You run a multi domain mail server for 30 client domains. Each one needs its own MX, its own DKIM key, its own SPF record, its own DMARC policy, its own quarantine rules, and its own deliverability reputation. The question isn't "can one server handle it" — Postfix and Dovecot have done that for two decades — the question is whether the setup will survive the first time a client's outbound campaign torches your shared IP reputation.
A multi domain mail server is the right architecture for plenty of operators. It's the wrong one for many others who think it'll save them money over hosted multi-tenant. This guide walks through the architecture, the configuration patterns that don't leak tenants into each other, the three isolation failure modes that bite at scale, and the math on where self-hosting a multi domain mail server beats paying for a hosted plan like TrekMail Agency.
What a Multi Domain Mail Server Actually Is
A multi domain mail server is a single mail-transport stack accepting and sending mail for more than one domain on the same infrastructure. One Postfix instance receives for client1.com, client2.com, and client3.com; one Dovecot instance stores mailboxes for all three with isolation; one outbound queue sends with per-domain DKIM signing.
This isn't the same thing as "multi-domain email hosting" as a marketing term, which usually means "a hosted plan where you can add multiple domains under one billing account." A multi domain mail server is the operational reality below that marketing: the actual Postfix and Dovecot configuration that makes the multi-domain plan possible. Both flavours exist — self-hosted on your own VPS, or hosted on a provider like TrekMail Agency where the multi-tenancy is the provider's problem.
Three Architecture Patterns at Multi-Domain Scale
Email operators running 10 or more domains converge on three architecture patterns at scale. Each one trades off cost, control, and operational complexity differently — and the right choice depends as much on your engineering bandwidth as on raw economics. Picking the right pattern up front prevents an expensive re-architecture two years in when you've outgrown the previous choice.
Pattern 1: One mail server per domain
The simplest architecture is one Postfix/Dovecot instance per client domain. No tenant isolation needed because there are no shared tenants. Each domain has its own VPS, its own IP, its own reputation, its own everything. Works fine for 3-5 domains where each one is a meaningful business in its own right. Breaks at 20+ domains because the per-server operational overhead — patching, monitoring, certificate renewal — scales linearly with domain count.
Pattern 2: One multi-tenant multi domain mail server
The canonical agency pattern: one Postfix + Dovecot stack handling all client domains, with virtual_mailbox_domains, per-domain DKIM keys, and Dovecot multi-tenant configuration. The operator manages one server's worth of infrastructure but serves N domains. The economic case starts working at around 10 domains and the operational complexity peaks at around 200 domains, after which most operators either upgrade to a hosted multi-tenant provider or split into multiple servers by reputation tier.
Pattern 3: Hosted multi-tenant (the buy-vs-build decision)
Most agencies eventually realize that running a multi domain mail server in-house is a full-time engineering job, and that the engineering job costs more than the equivalent hosted plan. TrekMail Agency at $29 per month (or $23.25/mo on annual billing) handles 1,000 domains with full per-domain DKIM rotation, per-domain SPF/DMARC management, and isolated outbound queues — all without the agency having to write any Postfix config. The breakeven point is roughly when a single engineer's hour costs more per year than the hosted plan does.
Postfix + Dovecot: The Canonical Multi Domain Mail Server Stack
If you're running a multi domain mail server yourself, the canonical 2026 stack is Postfix for SMTP transport plus Dovecot for IMAP storage and LMTP delivery. The configuration patterns below assume Debian or Ubuntu LTS; the principles port to other distributions cleanly.
virtual_mailbox_domains and the maps file
Postfix supports multi-tenancy via the virtual_mailbox_domains directive. Instead of hardcoding domains into main.cf, you store the list in a hash map (or in a SQL or LDAP backend at scale):
# /etc/postfix/main.cf
virtual_mailbox_domains = hash:/etc/postfix/vhosts
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_alias_maps = hash:/etc/postfix/valias
virtual_transport = lmtp:unix:private/dovecot-lmtpThe /etc/postfix/vhosts file lists every domain the server accepts mail for, one per line. The /etc/postfix/vmailbox file maps each address to a delivery path on disk. The /etc/postfix/valias file handles aliases (info@client1.com → real-person@client1.com).
Dovecot multi-tenant directory layout
Dovecot stores mailboxes under a per-domain directory structure. The conventional layout is /var/vmail/<domain>/<user>/. Configure it with:
# /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:/var/vmail/%d/%n
mail_uid = vmail
mail_gid = vmailThe %d expands to the domain part, %n to the local part. Each user's mail lives under their own domain's directory, which makes per-domain backups and per-tenant operations clean — you can rsync a single tenant out without touching the others.
LMTP for the Postfix → Dovecot handoff
Modern stacks use LMTP (Local Mail Transfer Protocol) for the handoff from Postfix to Dovecot. LMTP is faster than running a separate dovecot-deliver per message and supports per-recipient quota enforcement. Configure Dovecot to listen on a Unix socket Postfix can write to.
Per-Domain SPF, DKIM, and DMARC at Scale
The hardest part of running a multi domain mail server isn't transport — Postfix handles that fine. It's keeping per-domain SPF, DKIM, and DMARC clean across every tenant simultaneously, and rotating DKIM keys on a schedule that limits compromise blast radius. This is where most self-hosted multi-domain operators fail, and where hosted plans like TrekMail Agency earn their cost.
SPF per domain
Every domain on your multi domain mail server needs its own SPF record listing the server's outbound IP. The records are simple but they live in each domain's DNS, not your server. If you add a new outbound IP, every tenant's SPF needs updating — typically via the tenant's DNS provider, which you may not control. The full SPF setup walkthrough lives in our SPF setup guide.
DKIM per domain, rotated quarterly
DKIM is where multi-tenancy gets operationally expensive at self-hosted scale. Each domain needs its own DKIM key pair. The private key signs outbound mail; the public key sits in DNS under a per-domain selector. Best practice is rotating DKIM keys quarterly — but that means publishing a new selector for every domain, every quarter, and waiting for DNS propagation before deactivating the old key. At 100 domains that's 400 DNS updates per year, manually. The DKIM setup guide walks through the rotation flow.
DMARC reporting at scale
Per-domain DMARC means per-domain aggregate reports, which arrive daily as XML files from every receiver your tenants send to. Parsing them, attributing them to the right tenant, and surfacing actionable signals (this tenant's domain is being spoofed, this other tenant has misconfigured a sender) is its own engineering project at scale. The DMARC setup guide covers the parsing flow.
Three Isolation Failure Modes That Bite
A multi domain mail server is only as good as its tenant isolation. Three failure modes break tenant isolation at scale, and each one shows up only after a real incident exposes it. Plan for these before you hit them; debugging them in the middle of an active deliverability fire is brutal.
Failure 1: Shared outbound IP reputation collapse
Every tenant on your multi domain mail server shares your outbound IP for sending. If one tenant runs a cold-outreach campaign with poor list hygiene, the IP gets flagged. Suddenly every other tenant's mail gets rate-limited at Gmail. The fix is either rotating outbound IPs per tenant (expensive) or accepting that tenant abuse is a deliverability incident across the whole pool. The damage radius of a single bad tenant is your entire customer base.
Failure 2: Shared queue back-pressure
When Postfix's queue fills up — usually because one tenant got a 4xx temp-fail wall from a receiver — every other tenant's outbound mail also slows down. The queue is shared. Postfix has per-destination queue throttling, but the global queue is global. At 50 domains a single tenant sending a 500K newsletter can stall every other tenant's transactional mail for hours.
Failure 3: Authentication cross-talk
If Dovecot's authentication database isn't strictly per-domain, a user in tenant A might inadvertently authenticate against tenant B's records when their username happens to match. The fix is making username validation domain-aware everywhere — Dovecot's auth_username_format set to %u (full email) rather than %n (local part only). It's a one-line config but the consequences of missing it are user-facing in the worst way. The full risk inventory lives in multi-domain email hosting risks.
Self-Hosted vs Hosted Multi Domain Mail Server
The buy-vs-build decision for a multi domain mail server comes down to the real cost of your time. Self-hosted looks cheap when you're calculating VPS + bandwidth; it looks expensive when you're calculating the engineering hours that vanish into Postfix tuning, blacklist appeals, DKIM rotation cycles, and the inevitable 3 a.m. deliverability incident. Three thresholds flip the answer.
| Domain count | Self-hosted multi domain mail server | Hosted (TrekMail Agency) | Honest recommendation |
|---|---|---|---|
| 1-5 domains | ~$10/mo VPS + your engineering time | $29/mo flat ($23.25 yearly), or Starter $4/mo for 50 domains | Hosted — your time is worth more than the difference |
| 5-50 domains | ~$30/mo VPS + 10-20 hrs/mo engineering | $29/mo Agency, 0 hrs/mo engineering | Hosted — the engineering hours alone exceed the plan cost |
| 50-500 domains | $100-300/mo infrastructure + 1 part-time mail engineer | $29/mo Agency, still 0 hrs/mo engineering | Hosted unless you specifically need control no provider gives |
| 500-5,000 domains | $500-2,000/mo + 1-2 FTE mail engineers | $29/mo Agency + Drive Add-on for storage scale | Mixed — usually hybrid: hosted for transactional, self-hosted for niche per-tenant requirements |
The math almost always favours hosted at every realistic scale below 5,000 domains. The exception is operators with very specific compliance requirements that no provider satisfies — for example, a tenant who needs their data physically located in a jurisdiction the provider doesn't operate in. Even then, the pattern is usually "hosted for most tenants, self-hosted for the one compliance-driven outlier" rather than self-hosting the whole stack.
What you actually get from hosted multi-tenant
A hosted multi domain mail server gives you four things you stop having to build yourself. Per-domain DKIM key rotation, automated and audited. SPF/DMARC wizards that publish the right records to each domain's DNS via DNS-provider integrations. Outbound IP-pool warmup and per-domain reputation tracking. Aggregate DMARC report parsing across all tenant domains, presented as actionable signals rather than raw XML. Each of these is months of engineering on a self-hosted stack. On TrekMail Agency they're features in the dashboard.
Hosted Multi Domain Mail Server Comparison
If you've made the buy decision, three hosted providers cover the multi-domain operator market: TrekMail, Migadu, and Workspace at enterprise scale. Each has a different model. The comparison below assumes 50 client domains with ~10 mailboxes each (500 mailboxes total) — a typical mid-size agency profile.
| Provider | Pricing model | Per-domain DKIM rotation | Outbound queue isolation | Cost at 50 domains × 10 mailboxes |
|---|---|---|---|---|
| TrekMail Agency | Flat $29/mo ($23.25 yearly) | Automated, per-customer | Per-account queue, shared IP pool | $348/yr |
| Migadu Max | $90/yr per domain | Manual rotation, per-domain | Shared per-tier | $4,500/yr (50 × $90) |
| Google Workspace | $14/user/mo | Per-domain, but per-user pricing dominates | Shared Google sending pool | $84,000/yr (500 × $14 × 12) |
At agency scale TrekMail Agency is roughly 13× cheaper than Migadu's per-domain model and 240× cheaper than Workspace's per-user model. That delta isn't a marketing flourish — it's the difference between flat-rate and per-something pricing at the right scale. The trade-off is shared outbound IP pool versus per-domain dedicated IPs, which only matters if you have a tenant whose volume profile genuinely needs reputation isolation.
When Self-Hosting a Multi Domain Mail Server Actually Wins
The buy-vs-build math we walked through earlier almost always favours hosted. There are three specific scenarios where self-hosting a multi domain mail server is the right call despite the operational tax. Knowing when to bet the other way is as important as knowing the default.
Scenario one: regulatory compliance that no provider satisfies. A tenant whose data must be physically located in a jurisdiction where TrekMail, Migadu, and the cloud suites don't operate forces self-hosting. The tax is real but unavoidable. The pattern most agencies use here is hybrid — self-host the one compliance-driven tenant, host the rest. Don't self-host the whole stack to accommodate one tenant.
Scenario two: per-tenant dedicated IPs at deliverability tiers no provider offers. Some tenants — typically high-volume newsletter operators or transactional services — need dedicated IPs for reputation isolation. Most multi-tenant hosted plans run shared IP pools. If your tenant profile genuinely needs dedicated IPs and warmup discipline, self-hosting on a VPS with reputation-tier IPs is the right architecture. This is rare; most tenants who think they need dedicated IPs actually don't.
Scenario three: in-house engineering capacity that's already paying for itself elsewhere. If you already have a mail engineer on staff for unrelated reasons, the marginal cost of adding multi-domain mail-server operations to their plate is low. The hosted-vs-self-hosted math changes when the engineering hours are already sunk.
Security Hardening for a Multi Domain Mail Server
A multi domain mail server is a high-value attack target because compromising it gives an attacker mail-flow control over every tenant simultaneously. The hardening checklist below covers the controls that actually move the needle versus the security-theatre items that look impressive but don't change much.
SMTP submission must be over port 587 with STARTTLS or port 465 with implicit TLS, and authentication must require valid TLS — never anonymous, never plaintext on the wire. Port 25 stays open for inbound mail from other servers (it has to, that's how the internet works) but should reject any local-to-local submission attempts. Most compromised multi-tenant mail servers we've audited had port 25 still configured as a fallback submission path.
Outbound rate limiting per tenant prevents a compromised mailbox from torching your IP reputation in 20 minutes. The right limits are per-mailbox per-hour and per-account per-day, tuned to your tenants' real send patterns. Without limits, a single hijacked password can burn 100K spam through your shared IP before any monitoring catches it. TrekMail's published limits — for example, 1,000 mailbox per day and 6,000 account per day on Starter, 50 messages per hour SMTP submission on Nano — are the same controls you'd build into a self-hosted Postfix; they're just configured for you.
Authentication should require strong passwords plus 2FA for any administrative access. Per-mailbox 2FA matters less than admin 2FA because per-mailbox compromise has a smaller blast radius. The admin account on your multi domain mail server is the single point of failure for tenant isolation — protect it accordingly.
Operational Checklist for Running a Multi Domain Mail Server
If you've decided to run a multi domain mail server yourself, the daily and weekly operations matter more than the initial configuration. The Postfix + Dovecot stack runs for years once set up correctly, but the operational discipline around it is what separates a clean multi-tenant stack from a deliverability disaster. Below is the realistic operational checklist.
Daily: monitor queue depth and per-tenant outbound rate. A single tenant suddenly sending 10× their baseline is either a campaign or a compromise — either way it needs eyes. Watch blacklist status for your outbound IPs at MX Toolbox or equivalent. Check that overnight cron jobs (log rotation, DMARC report ingestion, backup rotation) ran cleanly.
Weekly: review aggregate DMARC reports for every tenant domain. New senders appear constantly — a tenant subscribed to a new newsletter platform, signed up for a new payment provider, hired a new sales tool — and each adds a sender that needs to be in your SPF and DKIM coverage. Review storage growth per tenant; mailboxes growing past 30 GB on a typical plan need either an archive policy or an upgrade conversation. Check Dovecot's IMAP-connection counters per tenant; a tenant approaching the soft connection cap will start dropping client syncs intermittently and tickets will follow.
Quarterly: rotate every per-domain DKIM key. The mechanical flow is publish the new selector at the tenant's DNS, wait 48 hours for propagation, switch Postfix's signing config to the new selector, and remove the old selector after another 48 hours of overlap. At 100 domains that's roughly 8-12 hours of work per quarter — call it a 40-hour-per-year operational tax just for DKIM hygiene on a self-hosted multi domain mail server. The same hygiene happens automatically on hosted plans like TrekMail Agency.
Annually: SSL/TLS certificate renewal for SMTP and IMAP listeners (Let's Encrypt rotates every 90 days automatically, but the rare manual case still happens), full backup verification by restoring one tenant's mail to a clean Dovecot instance to confirm the backups are actually restorable, and the security audit of authentication backends. The auditing matters because Dovecot's auth backend tends to accumulate stale entries over years — former tenants whose domains were removed from Postfix but whose users are still authentication-eligible.
Next Steps
Running a multi domain mail server yourself is technically straightforward and operationally exhausting. The Postfix + Dovecot stack works the way it always has; the part that costs you weeks per year is per-domain DKIM rotation and DMARC report parsing. The math on hosted versus self-hosted almost always favours hosted at any realistic agency scale.
TrekMail Agency is $29 per month ($23.25 on annual billing) for 1,000 domains × 1,000 mailboxes per domain, 200 GB pooled storage across email and TrekMail Drive, full per-domain DKIM rotation, raw Sieve editor for custom mail filtering logic, dedicated support, 100 aliases per mailbox, and the bulk-domain import flow that lets you onboard 50 client domains in one CSV upload. The 14-day free trial requires a credit card. The free Nano tier (no card, no trial) handles 10 domains × 10 mailboxes if you want to test the dashboard before going to the Agency plan. For the per-domain risk inventory specifically, see also our multi-domain email hosting guide. The full plan comparison and current pricing is at trekmail.net/pricing.
