Self-hosted email for the public sector

Self-hosted email for the public sector: why sovereignty and records change the build

A public body that must keep citizen and official correspondence on infrastructure it controls should look first at OX App Suite inside openDesk. For this context, that is the main open-source groupware path, with Stalwart and mailcow as narrower options that fit smaller or more contained mail estates. The choice turns on three questions: how strictly sovereignty is defined in the mandate, how mail identities must connect to the existing directory, and whether the body needs a supported edition with contractual patch and support commitments before it can go live. Those answers decide the platform long before anyone compares mailbox features.

Sovereignty in practice means more than the server location. The reader should map where each component runs, who holds the administrative credentials, and which bundled components are pulled from which upstream. openDesk is a Kubernetes-based suite provided by ZenDiS GmbH, and it expects a CNCF-certified cluster at v1.33 or later, an ingress controller, cert-manager and production-grade external services such as PostgreSQL, Redis, object storage and an SMTP relay. OX App Suite v8 requires Istio or the basic ingress-nginx option, MariaDB, Redis 7.4.x and a distributed file system for attachments. Each of these is a separate operational owner, so the build plan should name one before procurement starts.

Records and accessibility duties then shape the design. Mail that serves as an official record needs journaling or an archive outside the mailbox server, and the retention period is set by the public body's own records schedule, not by the mail platform. Directory integration decides whether one identity governs mail, files and portal access, and openDesk supports federation with an external identity provider, so the team should confirm the federation path against its directory before design freezes. Finally, the body should confirm the support model: openDesk Enterprise Edition is the vendor's recommended route for production, and the OX release lifecycle limits how long a given version stays supported. Ask the provider to show both in the written scope.

Which public sector requirements shape the mail design

This table maps each public sector requirement that can apply to government mail to what it means for the mail platform build. Read each row as a question to settle with counsel and your assessor before design freeze, since applicability depends on your jurisdiction, mission and contracts.

Requirement	What it asks for	What it means for the mail build
NIST SP 800-53 baselines and FISMA oversight	Federal agencies select controls from the SP 800-53 Rev. 5 catalog using the low, moderate or high baseline in SP 800-53B. Inspectors General assess agency system security under FISMA and report to OMB.	Fix the impact level and baseline early, because it sets logging, access, encryption and contingency controls for mailboxes, directory and backups. Ask the assessor which control set the mail system inherits from the hosting environment and which it must implement itself.
FedRAMP scope for cloud mail	FedRAMP covers cloud products that create, collect, process, store or maintain federal information for an agency. Systems used only for one agency's own operations and not offered as a shared service fall outside scope.	If the mail platform runs only for one agency in its own cloud account, FedRAMP may not apply. If a provider, shared tenant or managed service hosts mail for several agencies or bodies, confirm the authorization status of that service before selecting the hosting model.
CJIS Security Policy v6.1 for justice bodies	Criminal justice information must use FIPS 140-3 certified cryptographic modules or FIPS 197 AES with keys of at least 256 bits, in transit and at rest outside physically secure locations. Vulnerability scanning must run at least monthly.	Mail carrying criminal justice information needs validated TLS and storage encryption, 256-bit AES keys and a scanning schedule for the mail servers and webmail. Confirm the cryptographic module validation with the vendor, and confirm the policy version in force with the state CJIS Systems Officer.
32 CFR 2002.14(h)(2) for CUI on non-federal systems	Federal agencies setting protection requirements for controlled unclassified information on non-federal systems use NIST SP 800-171, unless the CUI category's authority prescribes other safeguards.	When a contractor or partner hosts agency mail on its own systems, the mail platform must meet the protection requirements in the agency's contract. Confirm with the contracting officer which CUI categories are involved, since some categories carry their own safeguards.
ADA Title II web and mobile accessibility	State and local government web content and mobile apps, including those provided through contracts or licenses, must meet WCAG 2.1 Level A and AA from 26 April 2027 for entities serving 50,000 or more people, and from 26 April 2028 for smaller entities and special districts (28 CFR 35.200).	Webmail, admin consoles and any mobile app that a government body provides or licenses need WCAG 2.1 A and AA testing. Ask the platform vendor or partner for accessibility test evidence and build it into the procurement, since the compliance date depends on the entity's population.
NIS2 for EU public administration	NIS2 covers central government entities regardless of size and lists public administration as a sector of high criticality. Member States may extend it to local administration, and it excludes entities working in national security, public security, defense or law enforcement.	Central government mail may fall under NIS2 security and incident reporting duties, which shape logging, patching and supplier oversight for the mail stack. Confirm with national counsel whether your body is in scope, whether local administration is covered in your Member State and whether the national security exclusion applies.

How OX App Suite in openDesk changes the groupware decision

Choosing OX App Suite as a standalone groupware product is one decision. Taking it as the groupware component of openDesk, the Kubernetes-based digital workplace from ZenDiS, is a different one. openDesk is delivered with Helmfile and Helm and bundles OX App Suite for mail, calendar and contacts alongside Nubus for portal and identity, Nextcloud for files, Element for chat and Collabora for the web office. The mail platform therefore inherits the cluster, identity and operations model of the whole workplace, and a public body should evaluate it as a workplace platform rather than as a mail server with add-ons.

The platform prerequisites are the first thing to confirm. openDesk requires a CNCF-certified Kubernetes cluster at v1.33 or later, an ingress controller (haproxy-ingress or the deprecated Ingress nginx), cert-manager, an RWO volume provisioner, Helm 3.17.3 or later below v4 and Helmfile 1.0.0 or later. For production it expects external services: PostgreSQL 15, MariaDB 10, Redis 7, Memcached, Cassandra, an SMTP relay, ClamAV over ICAP, object storage and a TURN server. The project tests on kubespray clusters and does not list OpenShift as tested, so an agency standardized on OpenShift should ask the partner and ZenDiS to confirm support before any scoping begins.

Licensing and support are where the decision becomes a procurement question. ZenDiS recommends openDesk Enterprise Edition for production. It uses the same open-source core licenses but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed second and third level support and patches, sold as SaaS or for on-premises installation. Each bundled component keeps its own license, such as AGPL-3.0 for Nextcloud and GPL-3.0 for OpenProject, so legal review must cover every component. Ask for the Enterprise feature list in writing, including whether the OX features your mail design relies on, such as advanced full-text search or S3 storage, are included, and whether OX App Suite itself carries separate module fees under its own license agreement.

Which mail platforms fit public bodies and why

Public bodies usually choose between a multi-tenant groupware suite that sits inside a sovereign workplace and a smaller mail server they can run with a small team. The cards below separate those paths and flag the licensing and version checks that decide between them.

OX App Suite for large groupware

OX App Suite v8 is designed for Kubernetes and delivered as Helm charts that reference container images, with Helm 3.17.0 or newer required. It expects Istio, or a basic ingress-nginx option where Istio cannot be used, and uses Redis 7.4.x for caching and session storage. Its primary data store is MariaDB with InnoDB, with supported versions 10.6.x, 10.11.x, 11.4.x and 11.8.x. Plan for a distributed file system or object storage for mailbox attachments and drive files, and choose an LTS release such as v8.47, since standard releases are supported for a shorter window.

openDesk Enterprise Edition as a workplace

openDesk bundles OX App Suite for groupware with Nextcloud, Element, OpenProject, XWiki and Nubus identity under one Kubernetes deployment, developed by ZenDiS. ZenDiS recommends the Enterprise Edition for production, which adds SLA-backed second and third level support and patches, sold as SaaS or for on-premises installation. Confirm with ZenDiS which components and patches your edition includes, and check that your cluster meets the stated requirements, since openDesk is tested on kubespray clusters and not on OpenShift.

Stalwart for single-tenant deployments

Stalwart is an all-in-one mail and collaboration server that supports IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV, which suits a single agency or department that wants a small, standards-based footprint. It is licensed under AGPL-3.0, with an optional Enterprise License from Stalwart Labs. Before choosing it, confirm the support model, the archiving and audit features your records policy needs, and whether the AGPL terms work with your procurement and any modifications you plan to make.

mailcow for Docker-based mail

mailcow-dockerized is a GPL-3.0 stack that runs mail, with SOGo providing the webmail, calendars and contacts, on Docker. It fits bodies with a capable Linux operations team that want a well-known, containerized mail stack without a Kubernetes platform. The public sector questions to settle are the archive and retention design, the spam and malware layer, and the DNS, SPF, DKIM and DMARC records for each citizen-facing domain, since outbound deliverability is often the hardest part to maintain.

Confirm OX module entitlements in writing

Open-Xchange states that the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Open-source mirrors of the App Suite UI and middleware are published under AGPL-3.0, but that does not settle which modules your body may run without additional terms. Ask for a written list of licensed modules, support entitlements and any per-user or per-feature fees before the scope is fixed, and compare that list with the features your mailbox and calendar requirements depend on.

Deployment patterns for sovereign public sector mail

This pattern deploys the openDesk digital workplace suite on a self-managed Kubernetes cluster inside the agency's or ministry's own data centre. OX App Suite supplies the groupware, while the surrounding components, including Nubus for portal and identity, come from the same suite. The deployment automation is Helmfile and Helm based, and each bundled component keeps its own license.

Directory federation: Nubus handles portal and identity, and the openDesk federation guide covers connecting an existing external identity provider. Confirm which protocol the agency's identity provider supports and whether group membership will be synchronized.
Object storage: OX App Suite expects object storage for larger deployments, such as S3-compatible storage, while smaller sites can use NFS. Production openDesk also expects object storage as an external service.
SMTP relay and ClamAV: openDesk expects an external SMTP relay and ClamAV reached over ICAP, both deployed as production services outside the suite.
Backup and upgrades: ZenDiS plans major releases annually in Q3 and minor releases monthly, supports only the latest minor version, and does not guarantee in-place upgrades between majors.
Cluster prerequisites: openDesk requires a CNCF-certified cluster at v1.33 or later and is tested on kubespray clusters, not OpenShift.

Confirm with the vendor whether the Enterprise Edition SLA and support scope match the agency's required response times before production sign-off.

How a public body rolls out sovereign mail in phases

This sequence moves a public body from a legal and scoping decision to a supported, records-compliant mail and calendar service on infrastructure it controls, with each phase closing on a checkable output. Sequencing matters because identity, records retention and migration decisions are hard to reverse once users are live.

Scope the service and confirm the legal basis
The agency's records officer, data protection lead, and CISO agree which user groups, mailboxes, shared mailboxes and calendars move, and which legal requirements apply to each, such as records retention rules, accessibility obligations for public web content, and any national classification or cloud authorization rules that govern where citizen and internal correspondence may be stored. DeployOpen can prepare the scoping workshop and the written requirements list, but the agency owns the legal interpretation. Done when the scope, the data classes and the list of governing obligations are signed off in writing and the open questions for counsel are logged.
Confirm Kubernetes and platform readiness
The platform team checks the target environment against the vendor's published requirements before any mail data is placed in it. For an openDesk based design, this covers the cluster version, ingress controller, certificate management, storage provisioning, Helm and Helmfile versions, and the external production services the platform expects, such as PostgreSQL, MariaDB, Redis, an SMTP relay, ClamAV over ICAP and object storage. For OX App Suite v8 components, the team also confirms the service mesh, database and distributed file system choices. Done when a readiness report lists each requirement as met, waived with a reason, or blocked, and the operations team has a tested install in a non-production environment.
Design identity federation and tenancy
Architects decide how the agency's existing directory or identity provider authenticates users, how groups map to mail roles and mailbox permissions, and whether one tenant or several separate tenants will serve different departments or subsidiary bodies. They also define administrator roles, the joiner and leaver process, and how service accounts for journaling and relays are managed. Done when the federation design, the group-to-role mapping and the tenancy model are documented, tested with a small set of test accounts, and approved by the identity owner.
Run a pilot with a bounded user group
A defined group of volunteers, typically from one department and including a shared mailbox and a calendar with external guests, uses the service for an agreed period while the operations team measures delivery, login, calendar invitations and client compatibility. Testers exercise the mobile and desktop clients the agency actually uses and report defects through a single channel. Done when the pilot exit criteria agreed in phase one are met or each gap has an owner and a fix, and the agency decides in writing whether to proceed.
Configure records retention and audit logging
The records team and the platform team set retention rules, journaling or archive targets, legal hold procedures, and audit log retention before production mail arrives. This includes confirming whether the archive is part of the mail platform or a separate system, how deletion and export are controlled, and which administrative and mailbox access events are logged and reviewed. Done when a test message is journaled, retained and retrieved under a legal hold in the pilot environment, and the retention schedule is approved by the records officer.
Migrate mailboxes and run coexistence
The migration team moves mailboxes, calendars and contacts in batches while the previous service stays live, and sets up mail routing so that messages reach the right system during the transition. They configure sending domain records for the new platform and check that outbound mail from both systems passes the authentication checks the agency's recipients rely on. Done when every batch passes item count and sample content reconciliation, routing rules are tested for internal and external senders, and the migration log is retained with the records.
Cut over and decommission the previous service
The agency sets a cutover date, moves remaining users and external routing, and keeps the old service read only for a period defined in the migration plan so that late messages and records can be retrieved. Operations monitors queues, authentication failures and client errors through the first business cycles after the switch. Done when no new mail is delivered to the old service, the archived legacy data has been verified against the retention plan, and the previous tenant or contract is closed with written confirmation that data was returned or deleted under the agency's instructions.

Evidence public sector assessors ask for, and which component produces it

This table maps the evidence items an assessor typically requests for a government mail and calendar service to the component that produces each item. Read each row as a question: what is requested, which component generates the raw record, and what the operator must still assemble. DeployOpen prepares this evidence, but independent assessors and the accountable authority issue the determinations.

Evidence item	Component that produces it	What the operator must still do
System security plan and control baseline mapping	Operator documentation, Helmfile and Helm values, and the openDesk or OX App Suite architecture records	Map each implemented control to the applicable NIST SP 800-53 Rev. 5 baseline and keep it current with each release (confirm the baseline with the authorizing body)
Configuration baseline	Versioned Helm charts and Helmfile configuration in the client repository, plus the Kubernetes manifests applied to the cluster	Record the approved values, review drift, and keep the configuration under change control
Access logs and audit records	OX App Suite middleware logs, Kubernetes audit logs, the identity provider, and the Nubus or external IdP authentication records	Forward logs to a central store with retention set by policy, and test that administrator actions are attributable to individuals
Vulnerability scan results	Scanners run against the cluster, container images and the mail-facing endpoints, configured by the operator	Confirm the scan cadence the applicable policy requires (CJIS Security Policy v6.1 sets monthly scanning for systems in its scope) and track remediation
Patch and upgrade records	openDesk release notes and Helm chart version history, and OX App Suite LTS and standard release notes	Record each upgrade, the release it moved to, and the test evidence; check that the version is still within the vendor support window
Encryption and key management evidence	TLS configuration on the mail ingress, mail transport settings, and the cryptographic modules selected for data at rest	Confirm that the modules meet the FIPS validation the applicable policy names, such as FIPS 140-3 where CJIS applies
Records retention and legal hold procedures	The archive or journaling target and the mailbox storage backend, which hold the copies the retention rules govern	Define retention periods, legal hold steps and search procedures with records officers; the mailbox server alone is usually not the record
Backup and restore test results	Backup jobs for the MariaDB database, the object or NFS storage holding attachments, and the configuration repository	Run and document restore tests on a schedule, including a full mailbox and calendar recovery

How much does public sector self-hosted email cost and what does it take

What drives the cost of self-hosted email for a public agency?

The cost is set by which platform you choose, whether you buy a supported edition, and how much infrastructure you must run around it. For an openDesk or OX App Suite groupware stack, the main components are the Kubernetes platform, production-grade external services such as PostgreSQL, MariaDB, Redis, object storage and an SMTP relay, plus any licensing for OX modules or openDesk Enterprise support. Mail filtering, backup, archiving and assessment preparation add further components. Ask each vendor and partner to price these separately so you can see what is licensed, what is hosted by you and what is labor.

Which costs are one-time and which recur every year?

One-time costs usually include scoping, architecture, the initial deployment, identity federation, data migration from the current mail system, and the first round of assessment evidence. Recurring costs include licenses or subscriptions, Enterprise support, infrastructure capacity, storage growth, relay and filtering services, patching, and staff time for operations. openDesk Enterprise Edition is sold as SaaS or for on-premises installation, so ask whether its support fee recurs and whether it covers the mail component you run. Recurring costs grow with mailbox count and retention periods, so model them for the full retention term.

How long does a public sector mail rollout take?

The timeline depends on the scope you agree, not on a standard duration. The main drivers are the number of mailboxes and sites, how many directory sources must be integrated, the state of the Kubernetes platform, the amount of history to migrate, and how many approval gates your security and records policies require. Ask any partner for a written plan with milestones, dependencies and the decisions that must come from your side, such as the identity owner signing off on directory design. Treat a timeline without these inputs as an estimate that cannot be checked.

What must the agency provide during a self-hosted email project?

Several roles on your side need named owners before work starts:

An identity owner who controls the directory, group membership, and any federation with an external identity provider.
A records officer who defines retention periods, legal hold needs and how public records requests will be searched.
A network team that manages DNS, firewall rules, certificates, the SMTP relay path and connectivity to the Kubernetes cluster.
A security owner who approves the hardening baseline and receives vulnerability findings.

The engagement scope should name who signs each deliverable. Missing owners are one of the most common causes of delay in agency projects.

Can our own IT staff run self-hosted government email without a partner?

Some agencies can, but only if they already operate Kubernetes, managed database and object storage services, and have staff who can handle mail deliverability, spam tuning and upgrades on a fixed schedule. openDesk documentation states that only the latest minor version is supported, that in-place upgrades between major releases are not guaranteed, and that skipping several minor versions may need intermediate steps. Those upgrade rules alone require a regular operations cadence. Assess your team against the platform requirements and the operations workload, and consider a retainer for upgrades, patching and continuous testing if internal capacity is thin.

How does a supported edition compare with community builds for government mail?

A supported edition gives you contractual support levels, patches and, for some products, closed-source modules, while community builds give you the open-source core with support from your own team or a partner. ZenDiS recommends openDesk Enterprise Edition for production, and states that it uses the same open-source core licenses but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed second and third level support. Open-Xchange states that some modules may be subject to custom packaging or separate fees set in the license agreement. Compare both options on the same written list: support response terms, patch delivery for the components you run, which features are only in the enterprise tier, license terms, and who is accountable when a component fails. Confirm each point with the vendor before you compare prices.

Questions to ask an implementation partner before procurement

Start with the edition question. Ask the partner whether they recommend the community build of openDesk or openDesk Enterprise Edition for production, and make them name the decision criteria behind the answer. ZenDiS recommends the Enterprise Edition for production, which uses the same open-source core licenses but adds closed-source modules, an Enterprise-only registry and license file, and SLA-backed second and third level support and patches. Ask which Enterprise-only features they would depend on, such as GroupSync, the Admin Console or the OX S3 storage and advanced full-text search, and what happens to the deployment if the agency later changes edition. Also ask how the OX App Suite groupware component is licensed in their proposal, because the Open-Xchange Operations Guide says certain modules may carry separate fees or custom packaging set in the license agreement. Request that agreement and the bill of materials in writing before scope is signed.

Next, ask how upgrades are documented and tested. openDesk plans major releases annually in Q3, minor releases monthly and patch releases on demand, supports only the latest minor version, and does not guarantee in-place upgrades between majors. Ask the partner to show the runbook they will use for each step, including what they do when the target version requires intermediate minor releases, how they rehearse the upgrade on a staging cluster built from the production Helmfile configuration, and who signs off the change. On the platform side, ask how they track Kubernetes support, since openDesk requires a CNCF-certified cluster at v1.33 or later, and how they align that with the OX App Suite v8 rule of supporting Kubernetes N-1 and N-2. Ask for the OX LTS plan too: an LTS release is supported until the next LTS plus six months, and the current LTS named in the support commitment is v8.47, so the partner should state which LTS the deployment will sit on and when it must move.

Then test the compliance evidence model. Records retention, journaling and legal hold are usually delivered by a separate archive, not by the mailbox server alone, so ask which archive product the partner integrates, how journaling is configured from the mail platform, and how legal hold is applied and audited. Ask them to show a sample evidence pack covering configuration baselines, access logs, backup restore tests and change records, mapped to the control catalog the agency uses, such as the NIST SP 800-53 baseline selected for the system. Confirm that they prepare this evidence for the assessor but do not issue audit reports or attestations, and that any FedRAMP, CJIS or CMMC determination rests with the authorizing or certifying body. Finally, ask for exit and data return terms: the format in which mailboxes, calendars, contacts and archive exports are returned, the timeline for returning them, who holds the keys and backups after handover, and whether the agency keeps administrative control of the Kubernetes environment throughout.

How DeployOpen scopes, builds and supports public sector mail

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including sovereign and air-gapped networks. For public sector mail, the work starts with a written scope that separates the mail platform, directory integration, archiving and citizen-facing deliverability, so each part can be tested and handed over with evidence.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The scope names the platform, such as openDesk with OX App Suite or a standalone groupware stack, and why it fits.
The scope records which records, directory and citizen correspondence flows are in and which remain with other systems.

How we build

We deploy into your cloud accounts, data centers or disconnected networks, under your identity and certificate authorities.
We integrate mail with your directory and identity provider, then test sign-in, mailbox access and admin roles.
We configure SPF, DKIM and DMARC for your domains and test delivery to external recipients before cutover.

How we hand over

We document architecture, configuration, backup and restore procedures, and the operating runbooks your team will use.
We prepare the controls and evidence your assessors will ask for, such as access logs, retention settings and change records.
We confirm with your team which records and archive functions remain outside the mail server and who owns them.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers on the agreed scope.
Upgrades are planned against the vendor's supported release cycle, with a test environment used before production changes.
Security testing of the mail platform and its integrations can be repeated after upgrades or significant configuration changes.

Self-hosted email for the public sector