Email is one of those infrastructure components that organisations often take for granted — until something goes wrong. For larger enterprises, the stakes are particularly high: hundreds or thousands of mailboxes, strict data privacy requirements, and a workforce that expects seamless, reliable communication across devices and clients. When a client came to us with a requirement for a fully self-hosted email solution, the project turned out to be a detailed exercise in platform evaluation, careful configuration, and ongoing operational planning.
This case study walks through the full process: the business requirements that drove the decision, the platform selection methodology, the technical deployment and configuration, the security and backup architecture, and the honest trade-offs that come with running enterprise mail infrastructure on-premise.
The Client’s Requirements
The organisation in question was a medium-to-large enterprise with a substantial number of employees across multiple departments. Their existing email setup was a mix of legacy infrastructure and third-party hosted services — and neither was satisfying their requirements.
Their key drivers were:
Data privacy and sovereignty. The organisation had specific concerns about sensitive internal communications being stored on third-party infrastructure. For regulated industries and privacy-conscious organisations, the ability to control exactly where data lives — and who can access it — is a material business requirement, not just a preference.
Cost predictability. Per-seat pricing models from major hosted email providers add up quickly at scale. At several hundred mailboxes, the annual cost of hosted solutions was significant and grew with headcount. A self-hosted solution would shift cost from operational expenditure to a one-time infrastructure investment.
Feature completeness. The organisation needed not just basic SMTP/IMAP mailboxes, but a full collaboration suite: shared calendars, contact management, task lists, and a functional webmail interface that didn’t require Outlook or a thick client.
Control over spam and security policies. With a hosted provider, filtering aggressiveness and policy configuration are constrained by the vendor’s platform. The client wanted direct control over SPAM thresholds, whitelist and blacklist management, and attachment handling policies.
Evaluating the Options
For an organisation of this size and with these requirements, there are broadly three categories of solution to consider.
Fully hosted SaaS — Microsoft 365, Google Workspace, and their equivalents. These eliminate operational overhead but require trusting a third-party provider with all communications data, commit the organisation to per-seat pricing indefinitely, and provide limited customisation of security policies.
Self-hosted component stack — assembling a mail server from individual components: Postfix for SMTP, Dovecot for IMAP/POP3, SpamAssassin or Rspamd for filtering, and a separate webmail interface like Roundcube. This approach offers maximum flexibility but requires deep expertise to configure correctly, and ongoing maintenance is non-trivial.
Integrated self-hosted platform — solutions like Zimbra, Mailcow, or iRedMail that bundle all mail server components into a unified platform with a centralised administration interface.
After thorough evaluation, we recommended Zimbra Open Source Edition as the optimal fit for this specific client.
The reasoning was straightforward. Zimbra provides genuine enterprise-grade features — a full collaboration suite, mobile sync via ActiveSync, a mature administration console, and broad client compatibility including native support for Outlook — in an open-source package that is free for non-commercial use. Its architecture is proven at scale: Zimbra powers millions of mailboxes globally, including at major universities and public sector organisations. And its operational model — all components deployed on a single host for standard installations — makes it accessible to organisations without a dedicated team of mail server specialists.
Operating System and Infrastructure
We selected Ubuntu LTS as the host operating system, which aligns with Zimbra’s officially recommended and supported platforms. Running Zimbra on an unsupported OS introduces a class of subtle compatibility issues — particularly around package dependencies and OpenSSL versions — that are worth avoiding entirely in a production environment.
The server was provisioned with dedicated resources: sufficient CPU, memory sized to accommodate the expected mailbox count and concurrent user load, and storage configured with appropriate IOPS for a mail workload. Mail servers are IO-intensive; a common mistake is provisioning fast CPU while neglecting disk throughput, which shows up as latency during mailbox synchronisation under load.
A dedicated, clean hostname and properly configured forward and reverse DNS were established before installation. This is a prerequisite that is easy to overlook and difficult to correct later — mail servers that cannot resolve their own hostname reliably, or whose reverse DNS does not match their SMTP banner, will face deliverability problems from the outset.
Installation
Zimbra’s installer script significantly reduces the complexity of getting a working mail system up and running. When deploying all services — MTA, IMAP/POP3, webmail, LDAP directory, and collaboration services — on a single host, the installation process is largely automated.
The installation procedure follows these key steps:
- Prepare the host: set hostname, configure
/etc/hosts, disable any conflicting services (particularly any existing MTA or web server on ports 25 and 80), and ensure system packages are current. - Download and extract the Zimbra installation archive for the target Ubuntu version.
- Run the installer script, which performs prerequisite checks, downloads required packages, and guides through the initial configuration via an interactive menu.
- Set the admin password during installation and verify the web administration console is accessible post-install.
- Configure DNS: MX records pointing to the mail server, SPF records authorising the server to send on behalf of the domain, and DKIM signing keys generated within Zimbra and published as DNS TXT records.
The DKIM and SPF configuration step deserves particular attention. Without correct email authentication records, legitimate outbound mail from the new server will be treated as suspicious by receiving mail systems — potentially landing in spam folders or being rejected outright. This is not a Zimbra-specific concern; it applies to any self-hosted mail deployment. DMARC policy records, which specify how receiving servers should handle authentication failures, are also strongly recommended as a final layer of outbound mail authentication.
Configuration: The Complex Part
Installation is the easy half. Configuration — particularly for a production enterprise deployment — is where the real work lies.
SPAM and Anti-Virus Filtering
Zimbra Open Source Edition ships with SpamAssassin for spam scoring and ClamAV for virus scanning, both integrated into the mail processing pipeline. Out of the box, these provide a reasonable baseline, but a production deployment requires tuning.
The key configuration tasks here were:
SpamAssassin threshold tuning. The default spam score thresholds often need adjustment based on the organisation’s specific mail patterns. Too aggressive and legitimate mail gets quarantined; too permissive and the inbox fills with junk. Initial thresholds were set conservatively and refined over the first weeks of operation based on observed false positive and false negative rates.
Bayesian filtering training. SpamAssassin’s Bayesian classifier improves significantly with training on actual spam and ham (legitimate mail) samples from the target organisation. We established a workflow for users to report spam and ham to training mailboxes, with an automated process to feed these into the classifier.
RBL (Real-time Blackhole List) integration. Configuring Postfix to check incoming connections against established IP reputation lists provides an efficient first line of defence — rejecting connections from known spam sources before they even reach the content filtering layer.
ClamAV signature updates. Ensuring automatic, regular updates to ClamAV’s virus signatures is a configuration task that is easy to set up and critical not to neglect.
DOS Protection and Rate Limiting
A publicly accessible mail server is an immediate target for brute force authentication attempts, dictionary attacks against mailbox usernames, and connection floods. Several layers of protection were configured:
Postfix rate limiting was configured to throttle the number of connections and message submissions from individual source IPs, reducing the effectiveness of automated attacks. Zimbra’s built-in account lockout policy was configured to lock accounts after repeated failed authentication attempts. At the OS level, fail2ban was deployed to monitor mail-related logs and automatically block IP addresses exhibiting attack patterns — failed SMTP AUTH attempts, repeated IMAP login failures, and similar signals.
These are not optional configurations for a production mail server. A Zimbra instance accessible from the internet without these protections in place will be under active attack within hours of going live.
Alias and Distribution List Configuration
With a large number of employees across multiple departments, a significant portion of the project involved configuring mail routing correctly: department-level distribution lists, functional aliases (info@, support@, billing@), and routing rules for legacy addresses from the previous mail system to ensure a smooth cutover without lost mail.
Backup Strategy
This was one of the most important configuration decisions of the project, and the one most constrained by the choice of the Open Source Edition.
The limitation: Zimbra Open Source Edition does not support warm backups — online, incremental backups that can be performed without taking the mail system offline. Hot backup and incremental backup features are reserved for the Network Edition (the commercial product).
Given this constraint, the backup strategy was built around cold backup scripts: scheduled scripts that gracefully stop Zimbra services, archive the data directories and configuration, write the archive to a separate backup destination, and restart services. This approach is proven and reliable, but it does introduce a brief maintenance window for each backup run.
The backup architecture included:
Local backup to a separate disk volume on the same host, providing fast restore capability for day-to-day recovery needs (accidentally deleted emails, individual mailbox corruption).
Remote backup to an off-site destination, providing protection against host-level failures. The same cold backup archives were replicated off-site via an automated transfer job.
Backup verification via periodic restore tests. A backup that has never been tested is not a backup — it is a hope. Scheduled restore tests to a separate test environment were established as part of the operational runbook.
The retention policy was set to maintain daily backups for 30 days and weekly backups for 6 months, balancing storage costs against recovery flexibility.
Migration and Cutover
Migrating from the existing mail infrastructure involved exporting mailbox data in a Zimbra-compatible format and importing it via Zimbra’s migration tools. For users still on IMAP-accessible services, the migration was performed using IMAP-to-IMAP synchronisation, which allowed most historical mail to be moved without service interruption.
The DNS MX record cutover was performed during a low-traffic window, with the TTL reduced in advance to minimise the propagation delay. During the cutover window, both the old and new servers were accepting mail, with the new server becoming primary and the old server kept alive to drain any in-flight deliveries.
The Zimbra installation went live with minimal downtime and, importantly, no incidents were reported in the period following the cutover. This outcome reflects the value of careful pre-migration testing and a conservative cutover approach — particularly for a workload as operationally sensitive as email.
Ongoing Operations and Lessons Learned
The deployment has been stable since go-live. Several observations are worth sharing for organisations considering a similar approach:
Self-hosted mail demands ongoing attention. Unlike a SaaS product where updates are automatic, a self-hosted Zimbra deployment requires planned maintenance windows for version upgrades, regular monitoring of certificate expiry (SMTP, IMAP, and webmail all require valid TLS certificates), and attention to deliverability metrics — particularly sender reputation with major receiving services.
The Open Source Edition limitations are real. The absence of warm backup support and the limited high-availability options (no distributed data store without the commercial licence) mean that the Open Source Edition is appropriate for organisations that can tolerate a recovery time objective of several hours, not minutes. For organisations requiring near-zero RTO, the Network Edition or an alternative platform warrants consideration.
Spam filtering requires ongoing tuning. SpamAssassin’s Bayesian classifier is effective but not self-managing. Establishing a workflow for users to report misclassified mail, and actually running the training process regularly, makes a material difference in filtering accuracy over time.
Deliverability is an ongoing discipline, not a one-time setup. SPF, DKIM, and DMARC are set up once — but sender reputation is earned continuously. Monitoring outbound mail queue for signs of spam originating from compromised accounts, watching for the mail server’s IP appearing in RBLs, and responding promptly when deliverability problems emerge are ongoing operational responsibilities.
Is Self-Hosted Email Right for Your Organisation?
This project was a good fit for self-hosted mail because the client had clear data sovereignty requirements, the scale justified the infrastructure investment, and they had the operational capacity to maintain the platform. Not every organisation ticks all three boxes.
For smaller organisations without dedicated IT operations capability, the operational overhead of self-hosted mail can outweigh the cost and privacy benefits. Modern hosted alternatives with strong data processing agreements and EU data residency have closed much of the gap on the privacy argument. The calculus is different for every organisation.
What this project demonstrates is that for the right client profile, a well-deployed self-hosted mail platform delivers genuine enterprise capability at a fraction of the cost of commercial SaaS alternatives — and puts the organisation fully in control of one of its most sensitive communication channels.
If your organisation is evaluating self-hosted email infrastructure, or you are looking for expert guidance on enterprise IT infrastructure and managed services, we are happy to discuss your specific requirements.
Suggested external references:
