Выделенный почтовый сервер на 10 000 ящиков: подбор конфигурации

Dedicated email hosting for 10,000 mailboxes

Email hosting for 10,000 mailboxes is an infrastructure project, not simply a Postfix installation. The platform must accept SMTP traffic, filter spam and malware, store IMAP mailboxes, provide webmail and mobile access, publish DNS authentication records, maintain backups, and remain available during hardware maintenance or a node failure.

A practical architecture separates externally exposed services from mailbox storage. Run Postfix for SMTP submission and inbound delivery, Dovecot for IMAP and mailbox access, Rspamd for spam filtering, Redis for Rspamd state, and a SQL directory such as MariaDB or PostgreSQL for users, domains, aliases, and quotas. Roundcube, SnappyMail, or another webmail application can run on separate web nodes. For a 10,000-mailbox environment, avoid putting every role on one machine.

VPS versus dedicated server for business email

A VPS is sufficient for a small organization, a single domain, a relay, or a low-volume mail platform with up to roughly 500 mailboxes and modest attachment traffic. A VPS with 4 vCPU, 16 GB RAM, 480 GB NVMe storage, static IPv4 address, and clean reverse DNS can serve that role if the provider permits mail delivery and the IP address has a good reputation.

For 10,000 mailboxes, use dedicated or bare-metal servers. Mail storage produces sustained random I/O from IMAP sync, indexing, antivirus scanning, backups, and concurrent mobile clients. Dedicated hardware supplies predictable CPU time, local enterprise NVMe performance, ECC memory, hardware isolation, and better control over RAID and network configuration. It also avoids noisy-neighbor I/O delays that can cause IMAP timeouts or delayed SMTP queue processing.

Move from VPS to dedicated infrastructure before reaching 3,000 mailboxes, or sooner if any of these conditions apply:

• More than 300 concurrent IMAP connections occur during business hours.
• Spam filtering exceeds 20 to 30 messages per second for sustained periods.
• Mailbox storage exceeds 1 TB or backups cannot finish inside the available backup window.
• Users require contractual uptime, shared calendars, mobile synchronization, or regulated retention.
• A single mailbox outage would affect multiple departments, customers, or tenants.

Capacity planning by mailbox count

Mailbox count is a useful starting point, but active users, average message size, retention, attachment volume, and IMAP connection count determine final capacity. A 10,000-user company with 2 GB average stored mail needs about 20 TB before snapshots, replicas, and backups. The same company with a 20 GB quota per user may eventually need more than 200 TB of usable primary storage.

For up to 3,000 mailboxes, one dedicated server can be acceptable with tested backups; from 3,000 to 10,000 mailboxes, deploy at least two dedicated mail nodes and do not treat one server as the only copy of user mail.

The 10,000-mailbox row assumes a few terabytes of active mail per node; increase storage or use replicated object storage when actual retained mail exceeds the usable RAID capacity.

Быстрый выбор

Нужен выделенный сервер?

Bare metal с NVMe в 70+ локациях — настройка и заказ за пару минут.

К серверам

Recommended architecture for 10,000 accounts

Mail transport and filtering tier

Deploy two SMTP gateways behind DNS MX records or a TCP load balancer. Each gateway should have 8 to 16 physical cores, 32 GB RAM, 480 GB to 960 GB NVMe, and a 1 Gbps port. Gateways run Postfix, Rspamd, Redis, ClamAV where required, and policy controls such as rate limits and sender restrictions. Keep inbound queues on fast local storage and monitor deferred mail closely.

Outbound delivery needs special care. Use authenticated SMTP submission on port 587 with TLS, require SMTP AUTH, rate-limit accounts, and block open relay behavior. Separate transactional application mail from user mailbox sending where possible. A compromised user account can otherwise harm the sending reputation of every domain on the platform.

Mailbox tier

Use two dedicated Dovecot mailbox nodes with 16 physical CPU cores, 64 GB ECC RAM, and RAID 1 enterprise NVMe drives. Dovecot should use Maildir or mdbox according to the operational team's preference. Maildir is simple to inspect and recover at the file level; mdbox reduces inode pressure and can be efficient for many small messages. Test backup, restore, and migration procedures before committing to either format.

For high availability, keep a replica of every mailbox on a second node using Dovecot replication, block-level replication, or storage replication designed for mail workloads. A replica is not a backup: retain immutable or versioned backup copies on independent storage and test restoration of individual messages and full mailboxes.

Directory, webmail, and monitoring

Run the user directory database on a separate database service with daily logical backups and point-in-time recovery if possible. Put webmail behind HTTPS on separate application nodes so PHP activity and web requests do not consume mailbox-server resources. Monitor SMTP queue age, disk latency, RAID state, CPU steal time, IMAP login failures, authentication errors, spam-filter latency, backup completion, certificate expiry, and free inode count.

Step-by-step setup recommendations

1. Build the operating system baseline

Use a supported Debian or Ubuntu LTS release, minimal packages, automatic security updates, a host firewall, SSH keys, and separate administrative accounts. Set the hostname to a fully qualified mail hostname such as mail1.example.com, not a generic local hostname.

2. Configure DNS before sending mail

Create forward and reverse DNS for each sending IP address. Publish MX records, SPF, DKIM, and DMARC records before onboarding users. PTR must resolve the sending address to the server hostname, and that hostname must resolve back to the same IP address. Start DMARC with p=none, review reports, then move to p=quarantine or p=reject after legitimate mail sources are aligned.

3. Install and configure the mail stack

Install Postfix, Dovecot, Rspamd, Redis, and a database client from maintained distribution repositories. Use virtual users, hashed passwords through Dovecot-supported schemes, TLS-only authentication, and separate submission settings from server-to-server SMTP settings. Disable plaintext authentication on unencrypted connections.

4. Protect submission and inbound SMTP

Permit port 25 for server-to-server SMTP and port 587 for authenticated user submission. Do not expose unauthenticated relaying. Add recipient validation, connection limits, per-account message limits, and outbound anomaly alerts. Keep a documented procedure for investigating unusual SMTP volume without deleting evidence needed for security review.

5. Set quotas and retention rules

Define mailbox quotas that match purchased storage and business policy. A 5 GB default quota for 10,000 mailboxes represents 50 TB of possible stored mail, excluding replicas and backups. Apply quota warnings at 80%, 90%, and 100%, decide how long deleted mail remains recoverable, and explain attachment-size limits to users.

6. Implement backup and recovery

Back up mail data, database data, configuration, DKIM private keys, and TLS renewal configuration. Follow a 3-2-1 approach: three copies, two storage types, and one copy outside the primary server location. Encrypt backup repositories, use immutable retention where available, and test a restore every month.

7. Add high availability carefully

Use at least two mail nodes, replicated mailbox data, redundant DNS records, and documented failover steps. Avoid automatic failover until replication consistency and split-brain behavior have been tested. A simple, rehearsed manual failover is safer than an untested automated design.

Performance optimization

• Use enterprise NVMe drives with power-loss protection. Consumer SSDs can suffer latency spikes and endurance problems under mailbox writes, indexing, and backup activity.
• Keep at least 20% free capacity on NVMe volumes. Full disks can stop SMTP delivery, corrupt indexes, and prevent logs from being written.
• Place Postfix queues, Dovecot indexes, and mailbox data on fast storage. Store long-term backups elsewhere so backup jobs do not compete with live IMAP traffic.
• Enable Dovecot index and cache files, then monitor their size and rebuild rate. Indexing reduces repeated parsing of large folders.
• Use Rspamd with Redis and tune antivirus scanning to match actual compliance needs. Scanning every message attachment with multiple engines can become CPU-bound quickly.
• Set IMAP connection limits per account and per source IP. Mobile clients can create many idle connections, especially after incorrect password changes.
• Use log rotation, central logging, and alerting for deferred queues. A queue older than 15 minutes during normal operation deserves investigation.
• Benchmark storage before migration with fio, and measure real SMTP and IMAP latency after onboarding pilot users.

Быстрый выбор

Нужен выделенный сервер?

Bare metal с NVMe в 70+ локациях — настройка и заказ за пару минут.

К серверам

Security and deliverability controls

Deliverability is based on domain authentication, sending behavior, complaint rates, content, IP reputation, and correct SMTP behavior. A new IP address may need a gradual sending ramp-up. Do not send bulk campaigns through a general employee mailbox platform; use a separate, consent-based transactional or marketing delivery process with its own controls.

Require MFA for administrative panels, restrict SSH access, use fail2ban or equivalent controls for repeated authentication failures, patch the operating system promptly, and rotate credentials after staff changes. Protect DKIM private keys with restrictive file permissions. Review mail logs for brute-force attempts, relaying denials, authentication failures, and unusual geographic access patterns.

Common pitfalls to avoid

• Assuming 10,000 mailboxes equals 10,000 active users. Size for peak concurrent IMAP sessions, message rate, and storage growth, not account count alone.
• Using one large server as the entire platform. RAID protects against a drive failure; it does not protect against motherboard failure, operating-system errors, ransomware, accidental deletion, or datacenter incidents.
• Ignoring reverse DNS and authentication records. Missing PTR, SPF, DKIM, or DMARC records can cause legitimate messages to be rejected or placed in spam folders.
• Operating an open relay. Incorrect Postfix relay settings can lead to abuse, blacklist listings, and rapid IP reputation damage.
• Underestimating storage. Quotas, deleted-mail retention, replicas, snapshots, and backups can multiply raw storage needs several times.
• Running backups only on the primary server. Local backups disappear with the same incident that affects production data.
• Failing to test restores. A backup is only useful after a successful, documented restore of messages, accounts, and configuration.
• Sharing outbound sending with untrusted tenants. One compromised or poorly managed sender can affect all domains using the same IP reputation.

Choosing the right dedicated server

For a 10,000-mailbox deployment, select dedicated servers with ECC RAM, enterprise NVMe drives, RAID monitoring, remote management, DDoS-aware network protection, clean IP allocation, IPv4 and IPv6 support, and sufficient monthly transfer. Valebyte dedicated servers are appropriate for the mailbox and SMTP roles where sustained I/O, predictable performance, and hardware isolation matter most. Start with two properly sized nodes, document growth thresholds, and add storage capacity before mailbox utilization becomes critical.