Corporate Mail Server: Hosting and Reliability in the Public Sector

Where the problem starts: everyone has mail, but not everyone plans for it

Corporate email and calendars in a government organization quickly become things that stop approvals, assignments and deadline control. While the service works, people don't think about it. But once messages start to be delayed or meetings disappear from schedules, both convenience and regulatory compliance suffer.

Failures usually don't look like a complete outage, but as an accumulation of small problems. Commonly these are:

• service unavailable at peak times;
• delays in delivery of messages and calendar notifications;
• loss of some data due to storage or backup errors;
• mailboxes filling up and rejecting new messages;
• access problems from branches and mobile devices.

Most often the root cause is planning. A typical mistake is to estimate volume based on the current state and add a small buffer. In practice volume keeps growing: attachments get larger, project correspondence is kept for years, new units appear, and records-retention rules rarely get simpler. If storage and backups are underestimated from the start, costs jump: you urgently buy disks, expand servers, increase backup windows, and outages become routine.

Before choosing hosting, agree with IT and the security service on three things: allowable downtime, how many years correspondence must be kept, and how quickly the service should be restored after a failure. This immediately rules out solutions that only look cheap at the start.

Hosting options: where the mail system will physically live

The hosting choice affects not only cost but responsibility for outages, updates and security. For a government organization this is especially important: control and availability requirements often outweigh speed of deployment.

Main scenarios

On the customer site (inside the agency building). Maximum control: access to racks, media, logs, physical security. The downside is obvious — all risks are on your side: power, cooling, spare parts, on-call engineers.

Corporate data center (if the agency or a subordinate organization has one). Usually easier to provide power and climate, easier to build redundancy, and there are operation regulations. But timelines can stretch due to approvals and queues for resources.

Provider data center. Fast start and strong infrastructure, but more dependencies: access regimes, contractual maintenance windows, stricter networking and responsibility separation.

Hybrid option. The most common scenario: storage and key roles remain in a protected site, while external gateways, mobile access or some services are moved to a data center. This simplifies access from business trips and reduces pressure on internal links.

To compare fairly, check four groups of questions for each option: control (who has access to infrastructure and backups), timelines (procurement and site preparation), risks (power, fire safety, operational rules, human factor) and staffing requirements (who updates, monitors and fixes incidents).

A separate topic is communications. If you have branches and mobile work, check in advance what happens on internet loss: will calendar access remain, how quickly will synchronization recover, and will bandwidth be enough at peak times.

Seasonal loads often cause not a spike in messages but a spike in connections: reports, mass mailings, approvals, business trips. In such periods not only servers matter, but the network, attachment limits, and clear rules for access from phones and laptops.

Reliability requirements: availability, redundancy, recovery

Mail reliability in a government organization is measured not by “it should not fall” but by availability numbers. For example, 99.5% equals roughly up to 3.5 hours of downtime per month. And this is not only about the mail server itself: the system is often brought down by power, a switch, storage, a full disk, botched updates or lack of space for logs.

It is important to agree in advance what counts as an incident. If mail is available internally but branches cannot reach it due to the network, users still experience a problem. Therefore describe availability as a service: “a user can send and receive mail, open the calendar and find contacts.”

Redundancy: where things usually break

Build redundancy from weak points, not by the mantra “we will add a second server.” The minimal checklist: power (two feeds, UPS and a clear switching scheme), network (two independent paths and separate devices), disks (redundant array and spare capacity), nodes (a second server or cluster) and a plan for site unavailability.

For critical services choose enterprise-class servers with predictable support and component replacement. In Kazakhstan such projects often use locally produced racks and servers, including the GSE S200 line, but the principle is the same everywhere: failure of one element should not stop the service.

RPO and RTO in simple terms

RPO — how much data you are willing to lose: how many minutes of mail are acceptable to lose after an incident (0 minutes, 15 minutes, 1 hour). RTO — how quickly the service must be back online (for example, 2 hours).

Backups must live in a separate contour: not on the same array and not on the same server. Otherwise a ransomware attack or major hardware failure can wipe both mail and backups. Best practice is to keep copies in at least two places and regularly perform test restores.

An incident recovery plan should be documented in advance: who decides, who brings infrastructure up, who checks database integrity, who notifies users and in what order components are started. Without this even “perfect hardware” turns downtime into long manual improvisation.

Functional requirements: mail, calendars and organizational rules

Mail system features matter as much as hardware choice. The same infrastructure can behave differently depending on how users work and what rules apply in the organization.

First clarify where and how staff will work. Branches, remote work and mobile devices increase the number of simultaneous connections and background synchronization. This affects not only the network but also the disk subsystem: many small operations run constantly.

In the public sector mail is almost always tied to a user directory: single accounts, access groups, shared address books, rights to shared and service mailboxes. If integration is not thought through, administration becomes manual and permission errors become frequent.

A separate risk area is retention policies. Retention periods, deletion prohibitions, archiving, departmental shared mailboxes and position-based mailboxes directly determine how much data must be kept online.

What usually inflates storage

Volume unexpectedly grows because of business requirements: journaling (a copy of every message), audit trails and extended logs, unlimited attachments, multiple shared mailboxes per department and constant forwards, as well as duplicate archives without clear rules.

Calendars change the load profile more than expected. Shared scheduling, meeting invites, free/busy checks and phone synchronization cause many frequent server accesses even when “mail is light.”

Mailbox size: what affects size and why it always grows

Mail system volume is often underestimated because people look only at “how many GB to give each user.” In reality you store not only correspondence but service data, search indexes, logs and recovery data. So actual disk usage is usually higher than the sum of quotas.

Size is influenced not only by headcount but by mailbox types. In government organizations there are usually executives with large attachment flows, reception shared mailboxes, departmental “inquiry” mailboxes, and service mailboxes for notifications, MFDs and portals. They are rarely cleaned and grow faster than “ordinary” mailboxes.

Attachments drive growth the most. One 12 MB scan of a contract sent to 50 recipients becomes hundreds of megabytes to store, index and later back up. If policies force forwarding between departments instead of working from shared documents, growth becomes avalanche-like.

When estimating volume keep several factors in mind: number and types of mailboxes, actual consumption (with soft quotas people often use 60–90% of allowance), average attachment size and mailing frequency, retention periods and need for archive, and reserve for growth for 12–36 months.

A practical example: 600 employees with a 5 GB quota and 50 shared mailboxes at 20 GB each. By quotas that is 4 TB. But adding 3 years of retention, active attachments, indexing and backups, demand easily grows 2–3 times. So it’s better to calculate from real usage profiles and include planned reserve from the start.

How to calculate resources step by step: from people and rules to hardware

Calculation starts not with a server model but with understanding how staff actually use mail and calendars. Even a powerful platform will either be underutilized or constantly choked if input data is inaccurate.

Collect inputs in one document and clarify what you are counting: just mail or also calendar data, logs, archives and backup contours.

Five steps that give workable numbers

1. Describe user composition: how many employees, how many shared and service mailboxes, whether there are resource calendars (meeting rooms), quotas and personal archives.

2. Measure current real volume: total database size, average mailbox, top heavy users. Separately calculate monthly growth.

3. Clarify retention rules: periods, auto-archive, journaling, retention of deleted items, legal retention requirements. These policies easily double volume because of copies and metadata.

4. Translate volume into disk and performance requirements: not only terabytes matter but latency, IOPS, backup and restore times.

5. Plan for expansion without long downtime: usually plan for 24–36 months. Decide how to add capacity and performance (disks, shelves, second node) and how this affects redundancy.

A simple guideline: the formula “users × quota” almost always underestimates reality because it ignores shared mailboxes, attachments, retention, indexing and backups.

Performance: where bottlenecks usually appear

Mail systems rarely slow down due to a single factor. More often several constraints combine and cause delays: messages leave slowly, search works intermittently, calendars open with pauses. Check three zones first when choosing a platform: disks, memory and network.

The most common bottleneck is the disk subsystem. For mail capacity is not enough — the speed of many small operations matters. Indexing, search, antivirus scanning, log activity and databases create load. When disks cannot handle IOPS and latency, operation queues grow and users see “hangs.” So choose RAID and drive types for the workload, not for raw gigabytes.

Memory is simpler: extra RAM usually pays off because services actively cache data. CPU becomes a limit later, but it matters with encryption, content filtering, mass migrations and morning peaks of incoming mail.

Network becomes an issue in two cases: many branches and many concurrent connections. Evaluate the link between sites, latency to the central node and redundancy of switches and uplinks inside the server room. If a single switch or uplink disables access for everyone, that is availability, not just speed.

For monitoring, regularly look at metrics: disk latency and queue length, RAM usage and swap, average and peak CPU load, network errors and losses, and response time of key operations (web UI, send, search).

Typical mistakes: where projects most often go wrong

The most common mistake is to consider only “quota per user.” In government organizations many mailboxes are small, but some users (executives, secretariats) grow quickly due to attachments and external correspondence. Relying only on quotas leads either to overspend or sudden lack of space.

A second risk is “invisible” mailboxes: shared (reception, registry), service mailboxes for scanners and applications, archives, mailboxes of former employees that must be retained by rules. Together these add significant volume and load.

Backups and retention periods are often underestimated. If mail must be kept for 3–5 years and backups are taken daily and retained long, disk space and restore time grow faster than the mail itself.

Another mistake is planning disks “to the limit.” You need reserve not only for growth but for maintenance: array rebuilds, migrations, temporary files, quarantine and indexing.

Fault tolerance and backups are also confused. A cluster or replication helps survive hardware failure but does not protect against deletion, encryption or admin mistakes. For those you need a separate backup contour.

It’s useful to answer four questions in advance: what is the real mail volume for 6–12 months, how many shared and service mailboxes and their retention rules, what RPO/RTO are required, and what spare capacity for disks and performance is planned for 2–3 years.

Quick checklist before procurement

Before procurement, check there are no gaps in the source data. Those gaps later turn into urgent upgrades, disk shortages and arguments about who must be on call at night.

Close five points:

• users by role (including shared and service mailboxes) and growth for 1–3 years;
• retention policies: quotas, auto-archive, shared mailboxes, retention periods for messages and attachments;
• target RPO/RTO and how they are achieved in backups;
• how to expand storage and change nodes without long downtime;
• security: network segmentation, admin rights, action logging, regular audits.

Then check the organizational part. A frequent mistake: “we bought hardware but didn't agree on everything.” For example, mail is required 24/7, but response is only during business hours. Then even a strong platform won't prevent long outages.

Example scenario: an agency with 1,200 users and branches

Agency: 1,200 employees, 10 branches. Mail is used not only for messages but for approvals, so attachments are large: scans, PDFs, spreadsheets. Some users work from mobile devices and branch connectivity can be unstable, so caching and correct behavior during short outages are important.

Policies set the frame: 10 GB quota per user, archiving after 2 years, shared mailboxes for departments (reception, procurement, inquiries), plus several heavy mailboxes for HR and accounting.

For a rough estimate start from expected reality, not quota. Suppose average personal mailbox occupancy after one year is 6 GB. Then personal mail database: 1200 × 6 GB = 7.2 TB. Add 30 shared mailboxes averaging 25 GB (0.75 TB) and reserve for heavy mailboxes (another 0.5 TB). That gives about 8.5 TB of data.

Then add commonly forgotten items: growth, service data and copies. If growth is 20% per year, in two years this is already about 12 TB. Add 20–30% for indexes, logs and platform overhead. Separately, plan space for backups: at least one full copy, several incrementals and space for restore tests. In reality disk plans easily reach 25–35 TB total.

On hosting: main site in a central data center, backup site in another building or city. For branches, local caching on workstations is often enough, and between sites use asynchronous replication so a failure in the main site does not stop work for long.

Before approving the project, ask IT and security a short set of questions: allowable downtime and mail loss, whether correspondence must be retained for regulatory reasons and how archive access is arranged, who manages shared mailboxes and calendar rights, where personal data can be stored physically, how often restore from backups is tested and who is responsible.

From assessment to implementation

When user and volume numbers are calculated, translate them quickly into a clear plan. Otherwise the project stalls between IT, security and procurement and requirements start to drift.

Collect the key points into a short 2–4 page specification: number of users and mailbox types, retention and expected growth, availability and maintenance windows, security requirements (for example, two-factor authentication, mobile device rules, logging), integrations (domain, address book, calendars, external mail).

Then run a pilot not on IT staff but on real departments: registry, HR, executives, staff with active calendars and shared mailboxes. Take 50–100 users and test 2–3 weeks of typical load: attachment emails, mailings, search, delegation.

At the same time agree recovery procedures after incidents: not just “we have backups” but what exactly is restored, in what time and who decides.

If local supply and a single responsibility for infrastructure and support are important, this stage is convenient to run with a systems integrator. For example, GSE.kz as a manufacturer and integrator in Kazakhstan covers server supply, infrastructure works and 24/7 support with a service network, which helps tie reliability and hosting requirements to actual resources.

Record results with simple artifacts: agreed architecture, pilot results and a list of equipment and works. With these procurement and deployment usually go much smoother.