Dedicated email hosting architecture for 10,000 mailboxes
A 10,000-mailbox platform is primarily a storage, disk-I/O, spam-filtering, and operational-reliability workload. The number of accounts alone is not the whole sizing metric: mailbox quotas, active IMAP sessions, message size, inbound spam volume, retention policy, and outbound traffic determine actual resource consumption.
For a typical business email service with 5 GB quotas, 10,000 accounts represent up to 50 TB of logical mailbox capacity. Most organizations do not reach every quota, but storage planning must still account for growth, deleted-message retention, indexes, backups, and replication. Do not place 50 TB of active mail on a single small NVMe pair; use quota controls, archival storage, or a multi-node mailbox design.
A practical design uses Postfix for SMTP, Dovecot for IMAP and mailbox delivery, Rspamd for content filtering, Redis for Rspamd state, and MariaDB or PostgreSQL for virtual-domain and account records. Maildir storage is straightforward and works well with Dovecot, while Dovecot's index files should remain on fast local NVMe storage.
Recommended production layout
- Two MX/filter nodes: receive SMTP traffic, run Rspamd, enforce rate limits, and queue mail during mailbox-server maintenance.
- Primary mailbox server: Postfix, Dovecot, local NVMe mailbox storage, database, monitoring, and backups.
- Secondary mailbox server or replica: separate dedicated server in another location where possible. Replicate mail with Dovecot replication or maintain a tested restore target.
- External backups: encrypted, versioned backups held separately from the production server. RAID is not a backup.
A single dedicated server can technically serve 10,000 accounts, especially where average usage is low, but it remains a single point of failure. For paid hosting, regulated organizations, or mail that must remain available during hardware maintenance, budget for at least two physical servers.
VPS versus dedicated server for email hosting
A VPS is suitable for a small domain portfolio, a modest internal mail service, or fewer than roughly 1,000 lightly used mailboxes. Start with 4 vCPU, 16 GB RAM, and 200 GB NVMe if mailboxes have strict quotas and the VPS provider permits outbound SMTP on port 25. Confirm that the assigned IP address has no poor sending history before putting it into service.
Move to a dedicated server once filtering, IMAP activity, or mailbox data creates sustained load. At 5,000 to 10,000 mailboxes, dedicated hardware provides predictable CPU time for antivirus and spam scans, lower latency for Dovecot indexes, direct control over enterprise NVMe drives, and fewer noisy-neighbor risks. Physical isolation does not automatically create good inbox placement; SPF, DKIM, DMARC, IP reputation, complaint handling, and outbound rate limits remain essential.
For 10,000 active business mailboxes, use dedicated hardware for the primary mailbox node and ideally for its replica. A VPS can still be useful as a low-cost secondary MX relay, VPN endpoint, monitoring node, or off-site backup controller.
Mailbox scale and server specifications
For up to 1,000 lightly used mailboxes a 4 vCPU VPS is sufficient; at 10,000 mailboxes use a 16-core / 64 GB dedicated mailbox server with enterprise NVMe RAID 1, and add a second dedicated server for high availability.
| Mailboxes | vCPU / CPU | RAM | Disk | Monthly bandwidth |
|---|---|---|---|---|
| Up to 1,000, average mailbox under 2 GB | 4 vCPU | 16 GB | 200 GB NVMe | 2 TB |
| 1,000-5,000, average mailbox under 3 GB | 8 dedicated cores | 32 GB | 960 GB enterprise NVMe, RAID 1 | 10 TB |
| 5,000-10,000, average mailbox under 5 GB | 16 dedicated cores | 64 GB | 2 × 1.92 TB enterprise NVMe, RAID 1 | 20 TB |
| 10,000+, average mailbox over 5 GB | 2 mailbox nodes, each 16-24 cores | 64-128 GB per node | 4 × 3.84 TB enterprise NVMe or distributed storage | 40 TB+ |
The disk figures cover active mail only and assume quotas, cleanup rules, and separate backup storage. If 10,000 users are allowed 5 GB each, plan for 50 TB of logical capacity rather than trying to fit all potential mail into 3.84 TB. Set realistic quotas, archive older mail, or deploy multiple mailbox-storage nodes.
Storage, CPU, and network planning
Storage requirements
Email data creates many small files and metadata operations. Maildir commonly stores each message as a file, so inode capacity matters as much as raw gigabytes. Select enterprise NVMe drives with power-loss protection and endurance appropriate for continuous writes. Use RAID 1 for a two-drive server; it protects against one drive failure but does not protect against accidental deletion, ransomware, bad synchronization, or corruption replicated to another node.
Reserve 20% free capacity on the active mail filesystem. Dovecot index rebuilds, mail delivery, logs, temporary antivirus files, and database maintenance all become less reliable on a nearly full volume. Mount storage with sensible options such as noatime, and monitor free space, inode usage, filesystem errors, SMART health, and RAID state.
CPU and RAM requirements
IMAP itself is usually moderate in CPU use, but TLS, full-text search, spam scanning, attachment analysis, and antivirus can become expensive. Allocate 64 GB RAM to a 10,000-mailbox node so Dovecot, Rspamd, Redis, the database, and the operating-system page cache can coexist without swapping. Disable or tightly scope antivirus scanning if it becomes a bottleneck; Rspamd plus file-type controls and attachment limits often offers a better cost-to-benefit ratio for normal business mail.
Bandwidth requirements
A 1 Gbps port is enough for most 10,000-mailbox deployments. Monthly transfer depends heavily on attachments and IMAP synchronization. Twenty terabytes per month leaves room for normal inbound and outbound use, but large mailing lists, automated reports, and mobile-client resynchronization can raise usage quickly. Limit inbound message size to 25-50 MB unless the business has a documented need for more.
Step-by-step setup recommendations
1. Install and patch the base operating system
Use a supported Debian or Ubuntu LTS release, minimal packages, SSH keys, automatic security updates, and a separate administrative account. Apply updates before exposing SMTP or IMAP services.
apt update && apt -y full-upgrade && apt -y install postfix dovecot-imapd dovecot-lmtpd rspamd redis-server mariadb-server certbot2. Set the hostname and forward DNS
Choose a stable fully qualified hostname such as mail.example.com. Its A or AAAA record must match the server address, and the provider should set matching reverse DNS. Major receivers commonly reject or score mail poorly when forward-confirmed reverse DNS is absent.
hostnamectl set-hostname mail.example.com3. Publish essential DNS records
Create an MX record pointing to the receiving host, SPF records authorizing only legitimate sending systems, DKIM public keys, and a DMARC policy. Start DMARC with reporting, inspect reports, then move toward quarantine or reject after all valid senders are aligned.
dig +short MX example.com && dig +short TXT _dmarc.example.com4. Configure Postfix as a closed relay
Accept delivery only for hosted domains and authenticated submission users. Never use permissive relay settings. Provide SMTP submission on port 587 with TLS and SASL authentication; port 25 should accept server-to-server mail, not unrestricted client relaying.
postconf -e 'smtpd_tls_security_level=may' 'smtpd_tls_auth_only=yes' 'smtpd_sasl_type=dovecot' 'smtpd_sasl_path=private/auth' 'smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination'5. Configure Dovecot with virtual users and quotas
Store account records in a database or managed flat-file map, not as thousands of Linux system users. Use unique virtual UID and GID values, Maildir or mdbox storage, per-user quotas, TLS-only IMAP, and a separate authentication socket for Postfix.
doveconf -n6. Add TLS certificates and force encrypted client access
Issue a certificate for the mail hostname. Enable IMAPS on port 993 and authenticated submission on port 587. Test certificate renewal before its first expiry.
certbot certonly --standalone -d mail.example.com7. Deploy Rspamd, DKIM signing, and rate limits
Use Rspamd for reputation checks, Bayesian filtering, SPF, DKIM, DMARC validation, and outbound protection. Generate separate DKIM selectors by domain or tenant where appropriate. Set conservative per-account outbound limits, such as 100 recipients per hour for normal users, then approve higher limits only for verified business workflows.
rspamadm dkim_keygen -d example.com -s mail -b 2048 -k /var/lib/rspamd/dkim/example.com.mail.key > /var/lib/rspamd/dkim/example.com.mail.txt8. Configure firewall, fail2ban, and service limits
Allow only SSH, SMTP, submission, IMAPS, and required monitoring ports. Restrict administrative access by VPN or source address where possible. Use fail2ban carefully; it should block repeated authentication failures without locking out valid office networks.
ufw allow 22/tcp && ufw allow 25/tcp && ufw allow 587/tcp && ufw allow 993/tcp && ufw enable9. Test delivery, authentication, and backups
Test inbound delivery, authenticated outbound delivery, DKIM signing, spam handling, quota enforcement, and restore procedures. A backup is only useful after a successful restore into an isolated test environment.
swaks --server mail.example.com --port 587 --tls --auth LOGIN --auth-user [email protected] --to [email protected]Performance optimization tips
- Keep Dovecot indexes, Rspamd Redis data, and database files on local NVMe rather than network-mounted storage.
- Use Dovecot's IMAP process limits and per-user connection limits to prevent a few broken clients from consuming all workers.
- Set message-size limits, attachment-type rules, and SMTP recipient limits before scanning expensive content.
- Separate inbound filtering from mailbox storage at higher volume so spam bursts do not delay IMAP access.
- Use connection pooling for database lookups and cache frequently used virtual-user information.
- Monitor SMTP queue age, deferred messages, Rspamd scan time, Dovecot login failures, disk latency, RAM pressure, inode use, and backup completion.
- Run routine maintenance during low-use periods, including database optimization, log rotation, package updates, and restore tests.
Common pitfalls to avoid
- Assuming RAID is a backup: use encrypted off-site backups with retention and regular restore testing.
- Using one IP address without reputation controls: configure rDNS, SPF, DKIM, DMARC, complaint handling, and outbound throttling before sending production mail.
- Allowing unlimited mailbox quotas: quota growth can consume storage suddenly and stop delivery for every tenant.
- Operating an open relay: test relay restrictions from an external host and review Postfix logs after every major configuration change.
- Putting backups on the same server: a server loss, account compromise, or destructive command can remove both production data and backups.
- Ignoring IPv6: either configure matching IPv6 DNS, reverse DNS, and TLS correctly or disable IPv6 SMTP advertising until it is ready.
- Skipping abuse monitoring: compromised accounts often send large recipient bursts; alert on unusual outbound volume and new geographic login patterns.
Choosing the right dedicated email server
Valebyte dedicated servers are appropriate for the primary mailbox node where predictable CPU, enterprise NVMe capacity, and isolated resources matter. Start with 16 dedicated CPU cores, 64 GB RAM, and mirrored 1.92 TB enterprise NVMe for a 10,000-account deployment with controlled quotas. Add independent filtering, replication, and backup infrastructure as mailbox sizes and availability requirements increase.