Which self-hosted email server fits your team when you leave hosted email
If your team has Docker experience, can staff a patched mail host, and accepts a GPL-3.0 stack, start with mailcow. If you want a single Rust binary with a paid option for support, evaluate Stalwart. If you want an MIT-licensed set of Docker images with a smaller feature surface, evaluate Mailu. The license is a decision point in its own right: mailcow is GPL-3.0 and managed by The Infrastructure Company GmbH, which suggests support contracts through Servercow. Stalwart is dual-licensed under AGPL-3.0 and the proprietary Stalwart Enterprise License, so any commercial use that needs the enterprise features is a paid per-mailbox decision. Mailu is MIT, which leaves the fewest licensing questions for legal review.
mailcow is the most complete dockerized suite of the three, running Postfix, Dovecot, Rspamd, SOGo and ClamAV in separate containers. That gives you more moving parts to patch and more memory to budget, so confirm the current system requirements against your user count before you size hardware. Stalwart consolidates mail, JMAP, IMAP, CalDAV and CardDAV into one server with pluggable storage, which suits teams that want fewer components but accept a newer codebase and a clustering model you must test. Mailu sits between them: it provides IMAP, SMTP, submission, webmail and an administration interface through a central front container, and it aims not to bundle groupware features.
Whatever you choose, the operating effort recurs. Ask each vendor or your implementation partner to document how DKIM keys, TLS renewal, backups and version upgrades are handled, and run a test migration of one mailbox before you move the domain. Confirm the exact ports your firewall must allow, since mailcow lists a long set of incoming TCP ports. Also confirm which Stalwart features your team needs and whether they sit in the Community edition, so the licensing decision is made on facts rather than assumptions.
Which mail server fits which scenario
This table matches common team situations to the mail server stack that fits best, with the supplied fact behind each choice and the condition that would make it the wrong pick. Read each row against your user count, skills and tolerance for running extra components.
| Scenario | Best fit | Reason tied to supplied facts | When the choice is wrong |
|---|---|---|---|
| Small team wants a full suite with webmail and ActiveSync | mailcow | Runs each function in its own container, including Postfix, Dovecot, SOGo and ClamAV, and documents ActiveSync sizing in its requirements. | Hosts with less than 6 GiB of RAM plus swap, or providers that are not on its supported Linux list, such as OpenVZ, LXC or NAS devices. |
| Team wants a single Rust binary with JMAP and CalDAV | Stalwart | Written in Rust and supports JMAP, IMAP, POP3, SMTP, CalDAV, CardDAV and WebDAV in one server, with pluggable storage backends. | When you need mature, widely documented ActiveSync-style groupware behavior, or your team has no capacity to evaluate a newer server before production use. |
| Team wants a minimal MIT-licensed Docker stack with per-domain admin delegation | Mailu | Configuration, Dockerfiles and code are under the MIT license, and it offers per-domain delegation in its administration interface with a central front container. | When you need an included groupware suite with calendars and shared contacts, since Mailu aims not to ship unrelated groupware features. |
| Team already has Postfix and Dovecot skills | Hand-built Postfix and Dovecot stack | Your staff can tune every component directly, avoiding container layers and the extra services that dockerized suites bundle. | When no one on the team can own patching, TLS renewal, spam tuning and deliverability monitoring over the long term, or when the team needs a supported turnkey box. |
| Small office wants a turnkey box | Mail-in-a-Box | Designed as a single installable mail server for a small domain, so the setup is one server with fewer decisions to make. | When you expect growth, separate mail roles or per-domain admin delegation, since the stack offers less room to scale than the Docker suites. |
| Team with a hard need for a paid support contract | mailcow or Stalwart Enterprise | mailcow is maintained by The Infrastructure Company GmbH, which suggests support contracts through Servercow. Stalwart Enterprise includes Premium Support from 150 mailboxes. | When your mailbox count stays below the Stalwart Enterprise threshold and you accept community support, or when the support terms do not match your procurement needs. |
| Mail must stay in a cluster with high availability | Stalwart | Clusters through peer-to-peer coordination or with Kafka, Redpanda, NATS or Redis, which gives more clustering options than the single-stack Docker suites. | When you cannot run the extra coordination services or do not have a tested failover plan. Confirm cluster guidance with the vendor before relying on it. |
| Compliance team needs a documented license and support trail | mailcow or Stalwart (confirm terms) | Both publish license terms: mailcow is GPL-3.0, and Stalwart is dual-licensed AGPL-3.0 or the Stalwart Enterprise License. | When your policy requires an audit-ready vendor attestation, which none of these projects supplies. Ask the vendor and your assessor what evidence they accept. |
How each option works and where it stops
mailcow packages a full mail stack as Docker containers, with each service in its own container: Postfix, Dovecot, Rspamd, SOGo, ClamAV, MariaDB, Redis, Nginx, Unbound, Olefy and an ACME client for Let's Encrypt certificates. It is managed and maintained by The Infrastructure Company GmbH under GPL-3.0, and it suits teams that want a complete, opinionated mail and groupware package on a dedicated host.
- Memory: The system requirements page sets at least 6 GiB of RAM plus 1 GiB of swap for the default configuration. It recommends 8 GiB for about 5 to 10 users and 16 GiB for a company with 15 ActiveSync phones and about 50 concurrent IMAP connections.
- Disk and architecture: It needs 20 GiB of disk excluding email storage and runs on x86_64 or ARM64.
SKIP_CLAMDandSKIP_FTScan disable ClamAV and full-text search to save memory, but scanning and search are then lost. - Ports: Incoming TCP 25, 465, 587, 143, 993, 110, 995, 4190, 80 and 443 must reach the host. Confirm that your provider allows inbound port 25.
- Unsupported hosts: It does not support OpenVZ, Virtuozzo, LXC or NAS devices such as Synology and QNAP. Plan for a full virtual machine or dedicated server.
- Support route: Support contracts through Servercow are suggested. Confirm the naming rules for the mailcow word mark before you fork or rebrand the stack.
Check the requirements page against your user count, mobile sync needs and mail volume before you size the host.
Stalwart is an all-in-one mail and collaboration server written in Rust. It serves JMAP, IMAP, POP3, SMTP, CalDAV, CardDAV and WebDAV from one product, so the team runs fewer separate services than in a container stack that splits each protocol into its own component. Its license is dual: AGPL-3.0 for the community path and the proprietary Stalwart Enterprise License for commercial use.
- Storage design: Data can sit in RocksDB, FoundationDB, PostgreSQL, MySQL, SQLite, S3-compatible storage, Azure or Redis. The backend choice is an architecture decision that the team must make and document before go-live.
- Built-in filtering: The spam filter includes LLM-driven message analysis, DNS blocklist checks, greylisting and Pyzor. Confirm how the LLM analysis is configured and where message content is processed before you enable it.
- Clustering: It clusters through peer-to-peer coordination or with Kafka, Redpanda, NATS or Redis. Choose the mode that matches your availability target and test failover in your own environment.
- Licensing: Community is free with no mailbox limit. Enterprise is a per-mailbox subscription activated by a license key, and cancelling reverts to Community without data loss, according to the pricing page.
- Resource figures: No supplied fact gives a memory or disk baseline, so ask the vendor for sizing guidance for your mailbox count and backend.
The main trade-off is that a single product concentrates more of the design on the team, so review its release notes and upgrade path against your change process before committing.
Mailu is a mail server delivered as a set of Docker images, with configuration files, Dockerfiles and code under the MIT license. It provides IMAP, SMTP and submission, multiple webmails and an administration interface with per-domain delegation. It fits teams that want a mail server without bundled groupware, since its README says it does not ship proprietary software or unrelated groupware features.
- Antispam and security: Auto-learning, greylisting, DMARC and SPF checks, anti-spoofing, an antivirus scanner, outgoing DKIM and Let's Encrypt certificates are listed as features. Test each control against your own domains before relying on it.
- Routing: A central front container routes HTTP and mail traffic, so the front container is the first component to monitor and secure.
- Deployment: The documentation covers Docker Compose and Kubernetes setups. Pick the model your platform team already operates, since the two paths carry different upgrade and storage tasks.
- Administration: The admin interface includes a web UI and an internal API, which helps automation but needs its own access controls.
- Gaps: Calendar and contact features are not part of the core product, so confirm how users will get those services before you choose Mailu.
The trade-off is a lean mail core that you pair with separate tools, which means more integration work than an all-in-one suite. Release 2024.06.64 was published on October 15, 2026, so confirm the upgrade path between release series with the project's release notes.
Mail-in-a-Box is an installer aimed at standing up a complete mail system on one server with opinionated defaults. It is named here because teams leaving hosted email often start with it, but no researched facts for this page cover its components, license, release history or resource needs, so the details below are what to confirm before you shortlist it.
- Components: Confirm the services the current release installs, including whether DNS, web and mail roles are bundled and how each one is configured.
- Operating systems: Check the supported distributions and versions in the project's own documentation for the release you plan to run.
- License and support: Confirm the license and whether a paid support route exists with the project maintainers.
- Resources and ports: Ask the maintainers for memory, disk and port requirements, and test them against your expected mail volume.
- Customization: Check whether it exposes the settings you need for multiple domains, custom routing, external spam filtering or your own TLS policy.
The trade-off is that opinionated defaults shorten the first deployment but limit the choices you can make later. Confirm that its upgrade method and backup procedure fit the recovery objectives your organization already uses.
A hand-built stack assembles Postfix as the mail transfer agent and Dovecot as the IMAP and mailbox server, then adds the rest yourself: TLS, spam filtering, DKIM signing, webmail, administration, backups and monitoring. Postfix and Dovecot are mature components that many other stacks build on, so this option offers the most control over each piece. No researched facts for this page cover the license, version or resource needs of these packages, so confirm them in each project's documentation for the versions you deploy.
- Components you assemble: Each role, from submission and filtering to webmail and administration, is a separate decision with its own configuration, patching and failure modes.
- Ports and DNS: The same mail ports apply, including 25, 587 and 993, and SPF, DKIM and DMARC records must be built and maintained by hand.
- Security ownership: Your team owns TLS policy, access controls and every security patch across the stack.
- Cost driver: Staff time to design, build, test and operate the stack is the main cost. Ask any implementation partner for a written scope covering configuration, hardening, testing and handover.
- Recurring work: Updates, certificate renewal, queue monitoring and restore tests recur for the life of the system.
This option trades the lowest licensing exposure for the highest operating effort. Confirm your team can staff those recurring tasks before you choose it over a packaged suite.
What the license and paid editions mean for your mail stack
The first decision is whether you need an OSI-approved license or can accept a dual license with a commercial tier. mailcow is GPL-3.0 and Mailu is MIT, both licenses the Open Source Initiative approves, so you can run, modify and redistribute either without a per-user fee from the license itself. Stalwart is dual-licensed under AGPL-3.0 and the proprietary Stalwart Enterprise License for commercial use. The AGPL-3.0 side is open source, but the Enterprise License is not, so a commercial deployment that enables Enterprise features is under a proprietary contract. Check which terms your legal team needs to approve before you pick a mail server.
Stalwart Enterprise is priced per mailbox per year. The Stalwart pricing page lists 2.00 euros or 2.40 US dollars per mailbox per year for 25 to 499 mailboxes, with a 25-mailbox minimum and support from 150 mailboxes, and quotes above 100,000 mailboxes. Enterprise features are switched on by a license key, and cancelling reverts the server to Community without data loss, which lowers the risk of starting a subscription. Ask Stalwart how the key is issued and renewed, what happens to features you rely on during a lapse, and what support response applies below 150 mailboxes.
Support terms differ across the three. mailcow is managed and maintained by The Infrastructure Company GmbH, and its README suggests support contracts through Servercow, so ask Servercow directly what is covered, what it costs and whether it includes help with upgrades. Mailu is free software that accepts outside contributions, which means you get no vendor support contract from the project itself, so any paid help comes from a third party you choose. Confirm support terms, response times and upgrade assistance directly with each vendor in writing before you rely on them for production mail.
Where the operating effort really sits
Standing up a mail server is the visible part of the job. The work that recurs sits in DNS, certificates, exposed ports, spam handling, storage and upgrades, and it lands on the same few people every month. Check each item against the stack you are considering before you commit.
DNS records and sender reputation
Every mail stack needs correct SPF, DKIM and DMARC records, and the DKIM keys must be rotated and republished when they change. Mailu's outgoing DKIM and mailcow's Postfix and Rspamd chain both depend on DNS being right before mail reaches the big providers. Usually the domain owner or the team that manages DNS owns this, and changes need a named approver. Confirm who can edit DNS, how DKIM key rotation is handled in each candidate, and who watches the DMARC reports.
TLS certificate renewal
Mailu and mailcow both issue Let's Encrypt certificates through their own ACME tooling, and mailcow runs a dedicated ACME client container for this. Renewal fails quietly when port 80 is blocked, when DNS points elsewhere, or when a proxy sits in front of the stack. Usually the platform team owns the proxy and firewall rules, and the mail admin owns the certificate check. Confirm how each stack reports renewal failures and how it handles certificates for multiple mail hostnames.
Exposed incoming ports
mailcow asks for incoming TCP ports 25, 465, 587, 143, 993, 110, 995, 4190, 80 and 443, and each one is an internet-facing surface to review. Port 25 is often blocked by cloud providers for new accounts, so the host and network path need checking before the install. Usually the network security team signs off on the inbound rules. Confirm which ports each stack needs, whether POP3 and ManageSieve are required, and how admin interfaces are kept off the public internet.
Spam tuning and blocklist response
Spam filtering needs ongoing tuning: Rspamd rules in mailcow, auto-learning and greylisting in Mailu, and the built-in filter with DNS blocklist checks and Pyzor in Stalwart. False positives reach users, and a listing on a public blocklist can stop outbound delivery overnight. The mail administrator usually owns tuning and delisting requests. Confirm who handles blocklist removal, how quarantine and false-positive review work, and whether the spam engine needs extra memory on your host.
Backups and mailbox storage growth
Mailbox storage grows steadily, and a backup is only useful if it restores mail, the database and the DKIM keys together. mailcow's disk guidance excludes email storage, so the mail volume must be sized separately. Usually the infrastructure or backup team owns the schedule, and the mail admin owns restore tests. Confirm where each stack keeps mail, metadata and keys, how restores are tested, and how quotas and retention are enforced per mailbox.
Upgrade cadence and release tracking
The three stacks ship on different rhythms: mailcow publishes date-based releases such as 2026-09a, while Mailu and Stalwart use version tags. Each upgrade touches containers, database schemas and DNS-dependent settings, so a missed release leaves you on an unsupported path. The platform team usually owns the upgrade window, with the mail admin signing off on the change. Confirm the upgrade procedure, whether release notes flag breaking changes, and who tests a new release before production.
What moving users off hosted email costs in time and risk
Moving users off hosted email costs more in planning and parallel running than in software, so ask for a written migration plan before any cutover date is set. A workable plan covers five stages: exporting mailboxes, cutting DNS over to the new servers (MX, SPF, DKIM, DMARC and the autodiscover or autoconfig records), reconfiguring each client, moving calendars and contacts, and running old and new systems side by side until mail flow is confirmed. Pilot the whole sequence on a test domain with a few mailboxes first, and confirm that the chosen stack can import from your current host's export format, including calendar and contact data.
Several factors push the cost up. The number of mailboxes and the number of mobile clients both drive sizing and support load, and ActiveSync or other phone sync needs checking against each candidate, since mailcow's own sizing guidance scales memory with phone and IMAP connection counts. Shared mailboxes, delegated access and any legal hold or retention obligation add export and verification work that is easy to underestimate. If Stalwart Enterprise is chosen, the per-mailbox subscription is a recurring cost on top of hosting: the Stalwart pricing page lists 2.00 euros or 2.40 US dollars per mailbox per year for 25 to 499 mailboxes, with a 25-mailbox minimum, so confirm the current figure and the count you will be billed for in writing.
Switching later is harder when data sits in a format or backend you cannot easily leave. Ask which storage backend each candidate uses, such as Stalwart's pluggable options or mailcow's MariaDB and Dovecot maildir layout, and whether an export can be read by another server without vendor tooling. Also check whether calendars and contacts live in the same stack as mail, because splitting them later means a second migration. Confirm these points with each vendor or community maintainer, and test a full export and re-import on the pilot domain before committing.
How to choose and pilot a self-hosted mail server
This sequence takes a team from defining its mailboxes and licensing position to a documented runbook, so the choice between mailcow, Stalwart, Mailu and the other options rests on tested behavior in the team's own environment rather than on feature lists alone.
Define mailboxes, clients and retention needs
Start by listing the mailbox count, the domains, the shared and role accounts, and the clients people use, including desktop IMAP clients, webmail, mobile devices and any ActiveSync or CalDAV needs. Record how long mail, attachments and archives must be kept and where they must physically live. Ask the mail and compliance owners to sign off the list. This step is done when the team has a written requirements sheet that each candidate can be scored against.
Decide the license position early
Decide whether the organization accepts only OSI-approved open source or will also consider a proprietary Enterprise license. This matters because Stalwart is dual-licensed under AGPL-3.0 and a proprietary Stalwart Enterprise License, with paid features activated by a license key, while mailcow is GPL-3.0 and Mailu is MIT. Have legal review the chosen license and any support contract terms. This step is done when the license position is written into the requirements sheet and approved.
Size a test host from published requirements
Provision a test host that meets the published requirements of the candidate you plan to pilot first. For mailcow, that means reviewing the stated RAM, swap, disk and supported operating systems, and checking which optional services such as ClamAV and full-text search can be disabled to save memory. Confirm the required inbound ports are reachable from your network and that your hosting environment supports the platform, since mailcow does not support OpenVZ, LXC or NAS devices. This step is done when the host passes a clean install with all required ports open.
Pilot with a test domain and measure deliverability
Run the pilot on a test domain with a small group of real users. Configure SPF, DKIM and DMARC records, then send and receive mail with the major consumer and business providers your users write to. Track inbox placement, bounces, spam-folder rates and TLS negotiation over several days, recording results per candidate. Confirm the outbound DKIM signing and reverse DNS setup with your IP provider. This step is done when you have a comparison table of deliverability results for each candidate, and you know which problems came from configuration and which came from the platform.
Test failover and backup restore
Simulate the failures you expect: a container restart, a host rebuild and a restore from backup into a clean host. Confirm the backup covers mailboxes, the database, configuration and DKIM keys, and time the restore against your own recovery expectations. For a multi-node design, test what happens when one node is unavailable. Ask the vendor or community which components hold state, since this determines the backup scope. This step is done when a restore has completed into a clean environment and the restored mailbox opens with its messages intact.
Document and approve the operating runbook
Write the runbook that the operator will follow after go-live: update procedure, patch cadence, certificate renewal, backup schedule, monitoring thresholds, abuse handling and the escalation path to vendor or community support. Note who is paid for what, including internal staff time, any support subscription, and any external services you retain. Ask each candidate for the upgrade notes behind its latest release. This step is done when the runbook has been reviewed by the people who will run it and a named owner has accepted it.
Questions buyers ask before they hire help with mail
What does running a self-hosted mail server cost compared with hosted mail?
Self-hosting replaces a per-seat subscription with a set of costs you pay directly: the server or VM, storage for mailboxes, backups, staff time and any support contract. The software itself may cost nothing, but the cost drivers are real. Hardware and storage scale with mailbox count, message volume and retention. Staff time for patching, monitoring, deliverability work and incident response recurs every month. Licenses vary: mailcow, Mailu and the Stalwart Community edition carry no per-mailbox fee, while Stalwart Enterprise is priced per mailbox per year. Ask any provider for a quote that separates one-time setup from recurring operations and support, and compare that total against your current hosted contract over three to five years.
How long does a mail migration take?
The duration depends on drivers you can measure, not on a single standard figure. The main ones are total mailbox size, the number of accounts and aliases, how many clients you must reconfigure, whether calendars and contacts move with mail, how much DNS, SPF, DKIM and DMARC work is needed to avoid delivery problems, and how many legacy systems send mail through your domain. Cutover planning, coexistence during the switch and user communication add time as well. Ask your implementation partner for a written plan that lists these inputs and the assumptions behind each phase, and confirm how they will verify mailbox contents after import.
Can a small team run a self-hosted mail server without an outside partner?
A small team with Linux and DNS experience can run one, but the work is more than installing a container stack. The team must keep the server patched, watch the queue, manage TLS certificates, maintain spam and antivirus rules, handle blocklist issues and respond to outages at any hour. Mail is also unforgiving: a misconfigured reverse DNS record or missing DKIM signature can quietly send messages to spam. Be honest about who owns on-call duty and who has time for deliverability work. Some teams run it alone, others keep a partner for setup, hardening and periodic reviews. Both approaches are valid if the roles are written down.
Which self-hosted mail option fits my mailbox count?
Mailbox count is one input among several, and the answer depends on how you use mail. mailcow suits teams that want a broad, Docker-based suite with a web admin, ActiveSync and many components, and its own documentation sizes memory from a few users to dozens of concurrent connections. Mailu suits teams that want a simpler MIT-licensed Docker stack with per-domain delegation. Stalwart suits teams that want one Rust server with JMAP, IMAP and CalDAV in a single binary, and its Community edition has no mailbox limit. A hand-built Postfix and Dovecot stack gives full control at the cost of more engineering. Test each candidate with a realistic sample of your own mail flow before you commit.
Does Stalwart Enterprise's per-mailbox price change the answer?
It changes the answer only when you need the Enterprise features or support. Stalwart Community is free with no mailbox limit, and cancelling Enterprise reverts to Community without data loss, according to the Stalwart pricing page. Enterprise is a per-mailbox subscription, currently listed at 2.00 euros or 2.40 US dollars per mailbox per year for 25 to 499 mailboxes, dropping to 1.04 euros from 10,000 mailboxes, with a 25-mailbox minimum. Premium Support begins at 150 mailboxes, so smaller teams rely on community support. Multiply the listed rate by your mailbox count, add the internal time you would otherwise spend on support, and compare the result with a support contract from another vendor. Confirm current pricing directly with Stalwart before you budget.
Will mailcow's resource needs fit a small virtual machine?
A small VM can run mailcow only if it meets the published minimums with headroom. The default configuration needs at least 6 GiB of RAM plus 1 GiB of swap, the project recommends 8 GiB for about 5 to 10 users, and it needs 20 GiB of disk excluding email storage. Its containers include Postfix, Dovecot, Rspamd, SOGo, ClamAV, MariaDB and Redis, so memory use is significant. Disabling ClamAV or full-text search with the documented settings lowers memory use at the cost of scanning and search features. Check the operating system list, since mailcow does not support OpenVZ, LXC or NAS devices. Size your VM from the system requirements page, then load test it.
What should I ask for in a quote for a self-hosted mail project?
Ask for a written scope that names the platform and version, the number of mailboxes and domains, the hosting environment, and every component to be installed or integrated, such as antispam, antivirus, webmail, calendar and directory sync. Require a list of deliverables, including DNS records, backup and restore testing, monitoring setup, hardening steps and documentation. Ask how the work is priced (fixed scope or time and materials), what is one-time and what recurs, and what a retainer covers for patching and upgrades. Confirm who handles migration, how cutover is rolled back and what acceptance criteria apply. DeployOpen works from a written scope agreed before work starts and does not publish a price list, so expect a quote that follows from that scope.
What does a self-hosted mail project need from our internal team?
Plan for named owners across several roles, even if an outside partner does most of the build. You need someone who controls the DNS zone and can add records quickly, a person who approves the hosting environment and firewall rules for the mail ports, and an administrator who will own accounts, aliases and retention decisions. Legal or compliance staff should confirm retention and eDiscovery needs, and the help desk must be ready for client reconfiguration. After go-live, one team must own patching, backups, monitoring and incident response. Without those owners, even a well-built stack will drift out of date.
What compliance teams should confirm about a self-hosted mail stack
Running mail on your own infrastructure moves four responsibilities onto your team: retention of messages and metadata, access logging, encryption in transit and at rest, and backup and restore. No hosted provider carries these for you once the stack is yours, so compliance teams should decide who owns each one before the first user migrates. DeployOpen plans, configures and documents these controls and prepares the evidence an assessor will ask for, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination, so confirm early which framework applies and which body will assess it.
Start with logging and retention. Ask the assessor which events must be captured (authentication attempts, administrative changes, message delivery records, and access to the webmail and admin interfaces), where those logs are stored, how long they are kept, and who can read or delete them. For each candidate stack, confirm the log destinations and rotation settings with the vendor or project documentation and in your own test environment, since default log locations and retention vary by component. Then confirm encryption in transit: which TLS versions and cipher settings are enforced on the submission, IMAP and webmail ports, whether opportunistic or enforced TLS is used between mail servers, and how certificates are issued and renewed. Record the actual configuration values, not the defaults you assume.
Next, confirm admin access and backups. Map every administrative role, including who can create domains, reset mailboxes, read or export mail, and change spam or security settings, and confirm that each role is individually authenticated and logged. Ask whether the platform supports separate administrator and user roles and whether administrative actions can be traced to a named person. Finally, test a restore of mail storage, databases and configuration into a separate environment, because an untested backup is weak evidence. Document the restore time you actually observe and the recovery point you can meet. Put these answers in writing with the vendor, the assessor and your own operations team before you select a stack.
How DeployOpen scopes a mail server selection and rollout
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For self-hosted email servers, that means working through the choice between mailcow, Stalwart, Mailu and the other stacks on this page against your own environment, then building the one you select.
How we scope
- Written scope covers which mail stack, mailbox count, domains and client types are in play.
- Scope records DNS, TLS certificate, port and firewall changes needed for mail traffic.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- Ask us to confirm licensing terms and paid edition needs before the scope is signed.
How we build
- We deploy the chosen stack on the hosting platform your organization specifies.
- We configure spam filtering, antivirus, DKIM, SPF and DMARC records as part of the build.
- We test mail flow, client access and backups against the written acceptance criteria.
How we hand over
- Handover includes operating documentation for administrators, covering configuration, backups and upgrades.
- We document the migration steps and rollback plan for moving users from their current mail system.
- Evidence for compliance assessments is prepared, though independent auditors issue any formal reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainer scope should state which mail stack versions, patch windows and incident response terms apply.
- Ask for a quote built from the written scope, since DeployOpen does not publish a price list.
