SmarterMail System Requirements

SmarterMail was designed to operate efficiently with multiple applications on the same server. Below are the minimum system requirements solely for SmarterMail. If SmarterMail is running on a server with other applications, those need to be taken into consideration and may add to the requirements listed below. In addition, high-load / high-volume servers may need to adjust the requirements as needed:

Supported Operating Systems

Windows Server 2016, 2019, 2022, 2025 or higher
Linux
- Debian-based: Debian 11+, Ubuntu 20.04+
- Red Hat-based: RHEL 8+, Fedora 40+, CentOS Stream 9+, AlmaLinux 9+, Rocky Linux 8.10+
Containers: Docker with Docker Compose, Kubernetes, etc.
Virtualization: ProxMox, VMware, Hyper-V, etc.

Minimum Hardware Requirements

6 GB RAM - swap file enabled on Linux
2-core CPU
1GB disk space for installation, not including mail data, file storage, etc.
Dedicated IP address
Dedicated domain name (subwebs and/or virtual directories are not supported)
Active internet connection

SmarterMail and Memory

SmarterMail's memory usage is dependent on a few different factors. For example, when using SmarterMail as a gateway — without any domains or users — less than 6 GB can be used. Servers with few users, and whose users aren't utilizing multiple syncing protocols such as EAS and MAPI & EWS (i.e., POP/IMAP only) could also work just fine with less than 6 GB as long as those mailboxes are not heavily used. (E.g., under 500 MB each). In each of these cases, 4 GB would be the recommended minimum.

When enabling things like MAPI & EWS, or even heavy usage of things like ClamAV, more RAM is always better. For example, ClamAV alone uses over 1 GB of memory, and when it is updating that usage doubles. This could lead to maxing out usage on servers with less memory. Similarly, users connecting to SmarterMail over MAPI will consume more memory than POP/IMAP connections.

Linux and Swap

In most circumstances we recommend setting up swap when installing SmarterMail on bare metal machines or VMs running Linux. (When using some cloud providers like Google, this is generally NOT recommended as it can quickly impact any IOP limits.)

For SmarterMail installations running on 4GB to 8GB of RAM, swap should be equal to the amount of RAM being used, and twice what's being used if allowing for hibernation.

Installations running 8GB - 64GB, at least a 4GB swap is recommended, and 1.5 times what's being used if allowing for hibernation. 8GB may be a decent middle ground.

For installations running over 64GB, 8GB for swap is recommended as swap starts to become less of an issue when your system has more memory to spare. If SmarterMail starts to use more and more memory, the 8GB swap can always be increased. Hibernation is not recommended on systems over 64GB.

For more information, RedHat has an article entitled Getting Started with Swap that is an excellent resource. In addition to providing recommendations for swap file size based on overall RAM, it includes information on creating a logical volume for swap in addition to how to create, extend, and remove both the logical volume and swap..

SmarterMail and Virtual Environments

SmarterMail can be installed on virtual machines, either in the cloud or on your own dedicated hardware. When using a cloud service like Azure or Google Cloud, we recommend a full VM and not serverless installs (like Cloud Run or App Engine).

Services like Azure and Amazon's platforms, as well as other cloud providers, have some things to consider when determining how well any mail server will run. For example, some cloud services don't offer static IP addresses, instead rotating the IP addresses that are used. This can cause issues with items like DNS records, (MX records, A records, etc.) and affect mail delivery. As such, a static, public IP address is required for any mail server running in the cloud.

In addition, some providers lock down the ports necessary to run a mail server in order to prevent spamming. Check to ensure you can get permission to allow Port 25 as most don't allow it by default. However, legitimate customers can bypass this restriction for their accounts, though it may take some time.

Below are some virtualization use cases, using Google's Cloud Compute platform as a guide.

Single Domain Using Docker (Linux), SmarterMail Enterprise

Machine Type: e2-medium (2 vCPUs; 4GB Memory)
Disk: Balanced Persistent Disk (SSD/Platter Hybrid)
OS: Ubuntu 24

Multiple Domains on Windows, SmarterMail Enterprise

Machine Type: e2-standard-4 (4 vCPUs; 16GB Memory)
Disk: Balanced Persistent Disk (SSD/Platter Hybrid)
OS: Windows Server 2022 or Server 2025

Multiple Domains on Linux, SmarterMail HA

Machine Type: e2-standard-4 (v vCPUs; 16GB Memory) -- same configuration for hubs and nodes
Disk: Balanced Persistent Disk (SSD/Platter Hybrid)
OS: Ubuntu 24

Virtualization Detail

In any virtualized configuration we recommend at least 2 vCPUs. This allows SmarterMail to have at least one other core available to process user requests.

For memory, ideally you'd want a minimum of 6 GB. However, for a single domain with light usage and no protocols (i.e., not using MAPI & EWS, and/or EAS) you can possibly get by with 4 GB. It all depends on usage. SmarterMail will utilize the memory allocated to it as it makes for a better user experience. Therefore, the more memory, the smoother the user experience. However, you can always start with a low, reasonable amount of memory then increase as necessary. On most cloud providers this is a relatively simple thing to do.

In terms of disks, SSD/Platter Hybrids are the minimum. Full SSD options are ideal, but cost can be a consideration. Platter drives are only really sufficient in low-use, low-user scenarios. A hybrid environment can get you the i/o needed for things like spool processing, but platter use can be used to limit the expense for things like email archiving, etc.

Regarding operating systems, we strongly recommend avoiding Beta or Dev Cycle versions of any server operating system. For Linux, sticking to LTS versions is the best course of action. We have done some extensive testing using Beta and non-LTS versions and found they can cause troubleshooting and maintenance headaches.

For addressing, many cloud providers offer both elastic and static IP addresses. Elastic IPs can be used for temporary usage, whereas static IPs are more permanent. You most definitely want static, non-elastic public IPs for your server/hub/node. This ensures the highest possible starting quality of the IPs. You can then "warm" these IPs by getting them added to SPF records as soon as possible.

For backup purposes, Google's "snapshots" (or any similar service from other providers) works effectively for both Windows and Linux based installations. An added benefit of these snapshots is that they can be leveraged for migrations, restores, cloning servers for testing purposes, etc.

Note: Each installation and environment is unique. Extra load caused by excessive messages or email accounts and/or other factors may require more disk space, memory, CPUs and/or CPU cores, database allocation, etc. SmarterTools recommends that system administrators slowly add domains to the server and watch how they impact the server. In addition, email patterns indicate that the number of email messages per account are increasing by approximately 60% every two years. It is important to keep this growth in mind when planning your rollout.