Zimbra Mail Server Setup and Support in Kenya
CloudSpinx installs, secures and supports Zimbra mail servers for businesses across Kenya and East Africa, whether that is a fresh build, a rescue of a box nobody has patched in years, or a migration onto or off Zimbra. We run Microsoft 365 and Google Workspace too, so the recommendation you get is the honest one rather than the one that suits us. Zimbra's source is open, but official binaries have needed a Network Edition licence since version 9, so what a mail server really costs you is licensing, the server under it, and whoever keeps it patched.
Who we build for
- 14organisations, from ISPs and payment platforms to a national regulator
- 6flagship engagements published in full, with the numbers counted
- 4thof all contributors to the open-source payment switch national systems run on
Everything in Our Zimbra Mail Server Service
Every engagement covers the full scope: no hidden extras, no upselling.
Zimbra installation and deployment
Zimbra 10.1 built on Rocky, AlmaLinux or Ubuntu, sized to your mailbox count and mail volume, with the admin console kept off the public internet where it belongs.
Managed Zimbra support
Patching on a cadence, queue and disk monitoring, blocklist watching, restore tests, and an engineer who answers when mail stops. The part most Zimbra estates are missing.
Zimbra upgrades to 10.1
Moving 8.8.15, 9.0 or 10.0 onto the only branch still receiving security fixes, staged against a copy of your data first so the cutover is boring.
Zimbra security hardening
Admin interfaces closed off, TLS and cipher policy set, proxy rate limits, two-factor on the admin accounts, and the known-exploited flaws checked off one by one.
Email migration to Zimbra
From cPanel mail, on-premises Exchange, IMAP or another Zimbra. Mail, folders, calendars, contacts and shared resources, with the source kept live until you are happy.
Zimbra to Microsoft 365 migration
The other direction, done properly. When self-hosting no longer earns its keep we move you off Zimbra and decommission it, rather than defending a server we sold you.
Deliverability: SPF, DKIM and DMARC
The DNS work that decides whether your invoices reach an inbox: SPF, a DKIM selector that actually validates, DMARC moved off p=none, and a PTR record that matches your HELO.
Zimbra backup and disaster recovery
Backups that restore a single mailbox rather than only the whole server, an offsite copy, retention matched to what your regulator expects, and restores tested on a schedule.
Multi-server Zimbra architecture
Splitting MTA, proxy, LDAP and mailbox store when one box stops being honest. Sized so adding a store later does not mean rebuilding the estate.
Zimbra proxy and failover design
Paired proxies behind a virtual IP, a second MX that actually accepts mail, LDAP replication, and a hypervisor underneath for the tier Zimbra cannot fail over itself.
Mail server monitoring
Queue depth, disk headroom on the blob store, certificate expiry, blocklist status and authentication failure rates, alerting before your users are the ones telling you.
Zimbra incident response and rescue
A compromised or wedged server, mail stuck in the queue, a domain on a blocklist, or an estate on a version that stopped getting fixes years ago. We stabilise first, then plan.
Technologies we use
How we design and run a Zimbra mail server
Four things decide whether a mail server is still trustworthy in year three: how the tiers split, whether your mail actually reaches an inbox, what each failure really costs you, and whether the version you are on still gets patched. Mailbox counts and sizing come out of your own numbers during the design phase.
Multi-server Zimbra architecture
Zimbra is four roles that most people install onto one box: the MTA that talks to the internet, the proxy that talks to your users, the LDAP directory that answers who everyone is, and the mailbox store that holds the actual mail. One box is a perfectly good answer under a couple of hundred mailboxes. Past that, the roles want separating, because the store is the one that gets big and the MTA is the one that gets attacked.
- mail and user traffic
- directory lookups
- message storage
Mail flow, SPF, DKIM and DMARC
Running your own mail server means you own its reputation. Gmail and Outlook.com decide in milliseconds whether your invoice reaches an inbox, and they decide it on DNS records and IP history rather than on anything inside Zimbra. Most of the deliverability work happens outside the server.
What Zimbra high availability actually gives you
This is the diagram we draw on the whiteboard when a client says they want their mail server to be highly available. Three of the four tiers survive a node loss cleanly. The fourth does not, and no amount of licensing changes that. Anyone selling you Zimbra without showing you the fourth card is selling you a surprise.
This is why we usually put Zimbra on a virtualisation platform we can fail over rather than on bare metal. The hypervisor gives you the restart the application does not, and it turns the worst card on this diagram into a few minutes of downtime instead of a restore from last night's backup.
Zimbra versions, end of life and the patch problem
Only one Zimbra branch is still getting security fixes. Every other version in the field stopped receiving them, and attackers know exactly which ones those are. The band at the bottom is the count of Zimbra flaws that CISA has confirmed as actively exploited, which is the number we put in front of any client still sitting on an old release.
Should you run your own mail server at all?
Start here, because for a lot of Kenyan businesses the honest answer is no. We deploy all four of these and we will tell you which one you are looking at before you spend anything.
Buy Microsoft 365 or Google Workspace
Under about fifty mailboxes, with no rule forcing your data to stay in the country, a hosted suite wins. Somebody else patches it, and a per-user bill is cheaper than a server plus the person who looks after it.
We set these up too. Saying so costs us a server sale and keeps the client.
All-in-one Zimbra
Every role on one machine. Genuinely fine up to a couple of hundred mailboxes, and the right call when the reason for self-hosting is control or residency rather than scale.
Plan the failure. One box means one outage takes everyone.
Multi-server Zimbra
MTA, proxy, LDAP and store separated, as in the first diagram. This is where you go when mail volume, a maintenance window or an auditor makes the single box untenable.
More moving parts. Worth it for the reasons above, not for their own sake.
You already run Zimbra and it is behind
The most common call we get. An 8.8.15 or 9.0 box nobody has touched in years, still serving the whole company, with an admin console facing the internet.
Start with the patch level. We assess before we quote a rebuild.
What a Zimbra mail server actually costs in Kenya
Zimbra does not publish a price list. Network Edition is sold through partners on a sliding per-mailbox scale, so the figure moves with how many mailboxes you buy and whether you qualify for the education, government or non-profit rate. That is why this page ends in a form rather than a table. Quoting a number before we know your mailbox count and your mail volume would be a guess dressed up as a price. What we can set against it is the published side of the comparison, and the arithmetic against Microsoft 365 shows where the crossover actually falls.
Is Zimbra free?
The source code is still published and still open. What changed is the binaries. Since version 9, Zimbra has not released free official installers, so a supported build now arrives with a Network Edition licence attached. Community-built packages do exist, and plenty of people run them. You are then trusting somebody else's binaries with every message your business sends, and you have nobody to call the week a zero-day lands. On a personal server that is a fair trade. For a company's mail, we will not recommend it, and we will say so before you ask us to install it. The full picture, including what building from source actually commits you to, is in our answer on whether Zimbra is still free.
The point where self-hosting stops paying
Microsoft 365 Business Basic is published at USD 7 per user per month on an annual commitment. Forty mailboxes is therefore a shade over USD 3,300 a year with no server, no patching and no 2am phone call. A self-hosted Zimbra has to beat that once you have added the hardware, the licence, the backups and the person who looks after it. Below about fifty mailboxes it usually does not, and we tell people that. Past a few hundred mailboxes, or the moment a regulator has an opinion about where the mail lives, the arithmetic turns and keeps turning.
- Mailbox count drives the licence line, and it is the first thing we ask.
- Total mail volume drives the storage, and storage is the part that grows. Nobody deletes anything.
- One server or split tiers changes both the hardware bill and how much of it you can switch off later.
- Availability expectation: surviving the loss of a node means a hypervisor underneath and somewhere to fail over to.
- Backup retention: seven days and seven years are different products with different bills.
- Managed or self-run: patching is the line item people leave out of the business case, and it is the one that ends up costing them.
Zimbra architecture: single-server and multi-server deployments
Zimbra is four roles wearing one installer: the MTA that faces the internet, the proxy that faces your users, the LDAP directory that answers who everyone is, and the mailbox store that holds the mail. Putting all four on one machine is the default and it is genuinely fine for a lot of businesses. Knowing when it stops being fine is most of the value we add here.
When one server is the right answer
Under roughly two hundred mailboxes, a single well-specified box with fast disk beats a badly-planned four-server split every time. Fewer things to patch, one backup, one restore. We build plenty of these. The trade you are accepting is that one outage takes the whole company off mail at once, so the backup and the restore test matter more here than anywhere else.
When we split the tiers
Three things push us to separate the roles. Mail volume outgrowing what one store's disk can hold. An auditor who does not want the internet-facing MTA sitting on the same box as the mailboxes. And maintenance windows: once you cannot take the store down for an hour without a board-level conversation, the tiers need to move apart so you can patch one at a time.
Sizing that survives the second year
Mail servers are sized wrong in a predictable direction. People size for today's mailbox count and forget that mail volume compounds while the user count sits still. We size the store for where your data will be in three years, keep the blob store on something we can extend without a rebuild, and leave room to add a second store rather than replacing the first one. The hardware underneath is specified from that number, not from a template.
Email deliverability: SPF, DKIM, DMARC and why your mail lands in spam
Run your own mail server and you own its reputation. This is the part nobody warns Kenyan businesses about: Gmail and Outlook.com decide whether your invoice reaches an inbox based on DNS records and IP history, and almost none of that lives inside Zimbra. We have picked up more than one estate where the server was healthy, the users were happy, and every message to a customer was quietly going to spam.
- PTR record: reverse DNS on the sending IP that matches the name the server announces. Only whoever owns the IP block can create it, which is why we settle this before the server is built rather than after.
- SPF: one record, listing what is allowed to send as you. Two SPF records is a common and quietly fatal mistake.
- DKIM: switched on inside Zimbra and the selector published in DNS. Half the failures we find are the first without the second.
- DMARC: moved off p=none once the reports are clean. Leaving it at p=none for years tells receivers you do not police your own domain.
- IP reputation: check the address is not already on a blocklist before you accept it. Recycled addresses arrive with someone else's history attached.
Zimbra security hardening and the patching problem
Eighteen Zimbra vulnerabilities sit in the CISA Known Exploited Vulnerabilities catalog, which lists only flaws confirmed as being used in real attacks. Four of those were added during 2026. One of them was first published in 2020, which tells you something sharper than any statistic about the product: a lot of Zimbra servers are installed once and never touched again, and attackers scan for exactly that. Zimbra is not uniquely insecure. It is widely deployed, permanently internet-facing, and frequently unmaintained, and that combination is what gets exploited.
What we do when a server is already compromised
Stabilise before rebuilding. Get the mail flowing, preserve what an investigation would need, work out what was reachable and for how long, then plan the rebuild on a clean machine rather than trying to scrub the old one. A mail server that has been owned is not something you patch and hand back. Where the incident touches personal data, the notification clock under the Data Protection Act starts running, and that is a conversation for our security practice as much as the mail team.
- Admin console and any management interface off the public internet, reachable over VPN or a restricted source list.
- Patch cadence agreed in writing, with a defined window for the ones that cannot wait for the window.
- Two-factor on administrator accounts, and a real inventory of who holds one.
- TLS and cipher policy set deliberately rather than left at whatever the installer chose.
- Proxy rate limiting and authentication failure alerting, because credential stuffing against webmail is constant.
- The known-exploited list walked through against your actual version, which is a short and uncomfortable meeting the first time.
Zimbra 9.0 and 10.0 are end of life: the upgrade path to 10.1
Zimbra 9.0 reached end of life on 30 June 2025. Zimbra 10.0 finished general support the same day and ran out of technical guidance on 31 December 2025. That leaves 10.1 as the only branch still receiving security fixes, with general support running to 31 December 2027 and technical guidance to 30 June 2028, per Zimbra's published lifecycle. Anything older than 10.1 is a server accruing unpatched flaws, and 8.8.15 is not even listed on that page any more. We have set out the three routes off an end-of-life Zimbra, with the exploited-vulnerability count that usually decides the urgency.
- Already on 10.0: the shortest hop, and the one to do now rather than next budget cycle.
- On 9.0: a real upgrade with an OS jump underneath it more often than not. Plan a weekend, not an evening.
- On 8.8.15: usually a build-alongside-and-migrate rather than an in-place upgrade. The old box is often too far behind on the operating system to carry a modern Zimbra.
- On a community build: we will tell you honestly what it would take to get onto a supported footing, including the licence cost you have been avoiding.
Zimbra migration: onto Zimbra, off Zimbra, and between versions
Migrating mail is the single most visible thing an IT team ever does. Everyone notices, immediately, and nobody is impressed when it works. We run every one against the same rule: the old system stays live and reachable until the new one has proved itself, and we never cut MX until the mailboxes have already been seeded.
Moving onto Zimbra
From cPanel mail, on-premises Exchange, another Zimbra, or plain IMAP. Mail, folder structure, calendars, contacts, shared mailboxes and distribution lists, seeded in batches while the old system keeps serving. The last sync happens after the cutover window opens, so nothing that arrives during the move gets stranded.
Moving off Zimbra
We do this as readily as the other direction. When the mailbox count has fallen, the residency requirement has gone away, or nobody internally wants to own a mail server any more, the honest answer is a hosted suite, and our Microsoft 365 and Google Workspace practice picks it up from there. We will decommission the Zimbra properly afterwards rather than leaving a forgotten box on your network still answering on port 25.
What actually goes wrong
Not the mail. The mail almost always copies cleanly. What breaks is everything attached to it: the shared calendar nobody mentioned, the scanner in accounts that relays through the old server with a hardcoded IP, the application that sends invoices via SMTP with credentials somebody set up in 2019 and never wrote down. We hunt those before the cutover, because finding them afterwards is how a migration gets a reputation.
Zimbra backup, restore and disaster recovery
The question is never whether you have backups. It is whether you can restore one mailbox, from a Tuesday three months ago, in front of a lawyer, without taking the server down. Plenty of Zimbra estates can do a full-server restore and nothing finer, which is not what you get asked for when it matters.
- Restore granularity that goes down to a single mailbox, folder or message, not just the whole store.
- An offsite copy, because a backup on the same hypervisor as the server is a copy, not a backup.
- Retention matched to what your sector actually requires, agreed up front rather than discovered during an audit.
- Restore tests on a schedule, with the result written down. An untested backup is a belief.
- A documented rebuild path: what it takes to stand the mail service back up from nothing, and how long that honestly takes.
Running your own email server in Kenya
Self-hosting mail in Kenya carries constraints that a generic Zimbra guide will not mention, and they shape the design more than the software does.
- The IP address is the asset: you need a static address with a PTR record you control, on a range with clean history. This is the single most common reason a self-hosted Kenyan mail server underperforms, and it is decided before installation.
- Power and cooling: a mail server in an office comms room is a mail server that goes down when the building does. Either the generator and the UPS are real, or the server belongs somewhere they are.
- Bandwidth is asymmetric: mail is mostly upload from your side. Office connections are usually sold the other way round, and it shows the first time somebody sends a large attachment to a distribution list.
- Data residency: keeping mail in Kenya is the strongest honest reason to self-host at all. Where personal data may legally sit, and what makes a cross-border transfer lawful, is something we have written up in detail for East Africa, and it belongs in the design conversation rather than the compliance review afterwards.
- Somebody has to be reachable: mail breaks at inconvenient hours. Either you have that person on staff or you contract for them, and pretending otherwise is how estates end up three versions behind.
When we tell clients not to run their own mail server
We sell mail servers. We also talk people out of them, several times a year, and it is the reason a fair number of them come back to us for something else. The four situations below are the ones where self-hosting is the wrong call, and if you are in one of them we would rather say so on the first call than eighteen months into a support contract.
- Under fifty mailboxes with no residency requirement. A hosted suite is cheaper once you count the server and the person, and it is patched by somebody else. Our managed IT practice runs those estates without a mail server in them at all.
- Nobody internally owns it. A mail server without a named owner drifts out of support in about two years. We have inherited enough of them to be confident about the timeline.
- You want it because it feels cheaper. Free software on hardware you already have is a real argument right up to the first unpatched flaw or the first blocklist entry, and then it is the most expensive option on the table.
- The requirement is really compliance theatre. Sometimes "it must be on-premises" turns out to be a preference nobody has ever tested against the actual regulation. We will read the requirement with you before quoting a server against it.
What still works if you stop paying us
Everything we build runs without us, and we treat that as the deliverable rather than a courtesy. No agent that only we can talk to, no configuration that lives in one engineer's head, no licence held in our name that leaves you stranded when the relationship ends.
- Licences bought in your name, on your account, renewable by you without going through us.
- Root and admin credentials handed over in a password manager you control, on day one rather than at the end.
- The build written down as a runbook: what is installed, why it was configured that way, and what to check when it misbehaves.
- DNS records documented and held in your own registrar account, including the DKIM selector and the DMARC policy.
- Backups landing somewhere you own, restorable with instructions written for whoever comes next, not for us.
- A standing offer to spend an afternoon handing over to your incoming engineer or your new provider. We would rather leave a working system behind than a hostage.
Tell us what you are running today
Answer what you know and skip what you do not. If you are already on Zimbra, the version matters more than anything else on this form, so check it before you send. A senior engineer reads every submission and comes back with a sizing view and a scoped price, usually within one business day. If a hosted suite is the better answer for you, we say so.
Ready to discuss Zimbra Mail Server?
A 30-minute scoping call, free, and it commits you to nothing.
How Every Zimbra Mail Server Engagement Starts
Assess what you have
Patch level, deliverability, backup reality and who actually owns the server. For an existing estate this is where the uncomfortable findings surface, and we would rather they surface now.
Design and price it
Mailbox count and mail volume turn into a shape: one server or split tiers, where it lives, what the backup looks like. You get the sizing and one figure, plus the honest recommendation if it is not Zimbra.
Build and migrate
Built alongside what you run today, seeded in batches, tested with real users before MX moves. The old system stays live and reachable until you are satisfied.
Run it or hand it over
Patch cadence, monitoring, blocklist watching and tested restores under a support agreement, or a documented handover to your team with the credentials and the runbook.