Four modern mail systems for self-hosting

Deliverability

The use of modern security standards is vital when setting up a mail server. As well as supporting secure and confidential message exchange, the standards are important for ‘deliverability’: the probability that outgoing messages can be delivered successfully. If your mail domain has a poor reputation, or if your mail server doesn’t support all modern security standards, there is a serious risk that the big mail handlers will treat your mail as spam or block it altogether. There is so much spam, phishing mail and other types of malware in circulation that they have little choice but to be strict. It’s with good reason that companies such as Facebook, Google and Microsoft have been the main proponents of the development and use of the modern mail security standards [DANE, MTA-STS, SPF/DKIM/DMARC].

However, the growing emphasis on security standards has the drawback of making it much harder for hobbyists and small service providers to set up and operate their own mail systems. If your system doesn’t support all security standards, you’re bound to have problems with the deliverability of your mail.

Four self-hosted mail systems

We have previously published detailed hands-on guides to the configuration of modern mail security standards for Postfix [DANE, SPF/DKIM/DMARC] and Exim [DANE, SPF/DKIM/DMARC]. From reader feedback, we’re aware that the guides are often used as ‘instruction manuals’ for the step-by-step creation of full-featured, secure and scalable mail systems. However, it’s also apparent from the guides that setting up all the various security mechanisms is a considerable undertaking, which requires a reasonable amount of technical know-how.

Although many people take the easiest option and have their mail hosted by one of the big (US) service providers, such a solution is at odds with the growing desire to retain greater control over one’s own data and the growing recognition of the importance of autonomy and sovereignty.

In this article, we consider 4 mail systems for the SOHO/SME market. Particular attention is paid to the (built-in) support for modern internet standards, without which there is a considerable risk that your outgoing messages will never reach the intended recipients. In all cases, our evaluation is based on the mail system being configured for the mail domain ‘example.nl’ on a Linux system using Ubuntu version 24.10.

#1: Mox

Of the 4 mail servers considered in this article, Mox offers the most comprehensive support for the security standards. The software is also very easy to install and configure. If you have a mail domain and a server system with a validating DNS resolver, you can have a basic mail server up and running in half an hour.

The installation and initial configuration of Mox involves just 3 steps. First, we create a new Unix user called ‘mox’:

  useradd -m -d /home/mox mox
  cd /home/mox/

In its compiled form, the Mox software consists of a single all-in-one binary, which, once installed, operates as the central portal via the command line. The ready-to-use Mox binary can be downloaded here, and is installed as an executable in the new home directory ‘/home/mox/’:

  cd /home/mox/
  chmod 744 mox-v0.0.14-go1.24.2
  ln -s mox-v0.0.14-go1.24.2 mox

The symlink means that we can also call up the binary using the name ‘./mox’ and that subsequent software upgrades are easy.

Quickstart

The initial configuration is performed using the ‘mox quickstart’ command:

  ./mox quickstart user@example.nl

Mox then creates 2 configuration files: ‘./config/mox.conf’ and ‘./config/domains.conf’. If necessary, the content of the files can be fine-tuned later. At the same time, the primary mail domain (‘example.nl’) and the domain’s first user (‘user@example.nl’) are created.

The quickstart function features a detailed help utility, which is very useful. If you haven’t yet installed a DNSSEC-validating DNS resolver, you’ll be given detailed advice on the configuration of Unbound.

All DNS records

DNSSEC validation is vital for the secure operation of all DNS-based mail security protocols: SPF, DKIM, DMARC, DANE, CAA (RFC 8659), MTA-STS and TLSRPT reports. Mox quickstart generates all the DNS records that your specified mail domain requires for those protocols:

 ; CAA
  example.nl.                      CAA 0 issue "letsencrypt.org"

  ; DANE
  _25._tcp.server.example.nl.      TLSA 3 1 1
      b777694f0c80f91435370cc80a1402c4dd80ba669fbc92139f7615d6068c2c76
  _25._tcp.server.example.nl.      TLSA 3 1 1
      9c4ad6560fb5f8a64acc5aa8d22a139f9efce84549ac938de94dc71c05a5332f

  ; MTA-STS
  mta-sts.example.nl.     CNAME server.example.nl.
  _mta-sts.example.nl.    TXT "v=STSv1; id=20250414T101928"

  ; TLSRPT reports for MTA-STS & DANE
  _smtp._tls.server.example.nl.    TXT
      "v=TLSRPTv1; rua=mailto:tls-reports@example.nl"
    ; was: tls-reports@server.example.nl
  _smtp._tls.example.nl.           TXT
      "v=TLSRPTv1; rua=mailto:tls-reports@example.nl"

  ; SPF
  server.example.nl.    TXT "v=spf1 a -all"
  example.nl.           TXT
      "v=spf1 ip4:192.0.2.109 ip6:2001:db8:1192::/64 mx ~all"

  ; DKIM
  2025a._domainkey.example.nl.    TXT
      "v=DKIM1;h=sha256;k=ed25519;p=9fohEgAGYtFVOlJhrxU5WJmJI4UBQYxf3IfWfFWbTKA="
  2025b._domainkey.example.nl.    TXT (
      "v=DKIM1;h=sha256;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyuJJw9uT4+ebIqo38b1KEz7ogAPQWCg1VuQx+"
      "tjlAFE2hDUyVdxmuUO+nK535QYxAKyNSLz5N6CIVjuf7ZHOZBtcfo7eQAC65QZF09UsfIynS1q9gCZsPa1v7vWv/z+ybUH4dZDq8"
      "hNTs3LAGdv58nCkMGe628b+1Iq0o02P2IGdP8ziu4l8I0bR8McTYmzyNvhBGy5tnoSzenr3ClsKUvU5Uhbg2P9fOIMyhkH++wcLc"
      "yGWbqfMaPKEae/8H4XhDs4X8s0KB4QrjzDATpoK1rZXAn/Gs/T/I+E8CxDt0wNy8RXoXFxIG18jWjqietnlsiWdLTNuPC7yULeAt"
      "beE+QIDAQAB"
      )
  2025c._domainkey.example.nl.    TXT
      "v=DKIM1;h=sha256;k=ed25519;p=TXo4YzsH1pCUe7ZwJ8Q/aZSPrVCzAnE/CA6GaR1HI9A="
  2025d._domainkey.example.nl.    TXT (
      "v=DKIM1;h=sha256;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1I9ZhaWSzSMQj83kVifH24Ea2QrFFN+h/X692"
      "KD4kR6i/wV2ZqFI+prVm5RS4QcY6EKvbldQEqCHjj7DOqnV5RnX+P8QLGsGw3H/nIuPhgH2s/czIQ8zf4sthve5+cirIMajkWZ+J"
      "xKoCkJbvV3s0VVwuzT3ODvzLadJhVTmiWqI/ARfCy4I9mV+zbK+4+QxmzdtB8W+BuuDw346aFXApk5JGimKw10t6sDzZD+rt7vWY"
      "g/hiNLPkRx4rOyjln0CMA1jFt+SOwIV1Z4uEJSfDW55iErfjiATAjMvBo18lnSi9wDXKqTw3WN2jbB7Xw36lMr2+6DdKCOLYH4g8"
      "E1hsQIDAQAB"
      )

  ; DMARC
  _dmarc.example.nl.              TXT
      "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.nl!10m"

The keys for TLS (generated using Let’s Encrypt) are located in the directory ‘./config/hostkeys/’, while the DKIM signing keys are in the directory ‘./config/dkim/’.

In addition

In addition to the MX record (which tells the outside world where to deliver mail for the domain ‘example.nl’), Mox generates all the SRV records for the mail server. Those records are used for the ‘discovery’ of internet services. The mail-related records are defined in RFC 6186.

  example.nl.                       MX 10 server.example.nl.
  mail.example.nl.                  CNAME server.example.nl.

  _imaps._tcp.example.nl.           SRV 0 1 993 server.example.nl.
  _submissions._tcp.example.nl.     SRV 0 1 465 server.example.nl.

  _imap._tcp.example.nl.            SRV 0 0 0 .
  _submission._tcp.example.nl.      SRV 0 0 0 .
  _pop3._tcp.example.nl.            SRV 0 0 0 .
  _pop3s._tcp.example.nl.           SRV 0 0 0 .

  ; Thunderbird Autoconfiguration
  autoconfig.example.nl.            CNAME server.example.nl.
  _autodiscover._tcp.example.nl.    SRV 0 1 443 server.example.nl.

The Autoconfiguration/Autodiscovery protocol was developed by Mozilla for its Thunderbird mail client. The basic idea is that new users only have to enter their name, e-mail address and password to configure the client. The technical settings for that user are then fetched (in the form of an XML file) from a web server by means of a DNS referral.

All the generated output and help information can subsequently be found in the ‘quickstart.log’ file, together with the passwords of the first user and the admin account.

Start-up

Once you’ve added all your new DNS records to your zone, it’s time to start the Mox server (as root):

  ./mox serve

However, a ‘mox.service’ file is also provided, so that you can also manage the mail server using Systemd (e.g. with the ‘systemctl’ command).

After expiry of the TTL for the propagation of the new DNS records, ordinary users can access their mail via the webmail interface (‘https://mail.example.nl/webmail’) and using IMAPS (on port 993). They can send mail using Secure Submission (on port 465). If a user goes to the central web page (‘https://mail.example.nl/’), they can configure their account further.

Administration

The administrator has their own web portal: https://localhost/admin.

The most important features for the administrator are account and domain management and the logs. Mox can also handle inbound DMARC and TLSRPT reports. In addition to the web-based admin portal, a huge number of commands and options are available via the ‘./mox’ executable.

#2: Chasquid

While Mox aims to be a complete mail solution for the SME market, Chasquid offers only a lightweight Message Transfer Agent (MTA) as an alternative to Postfix and Exim. Like Mox, Chasquid is written in the Go programming language. The source code is made available as a tarball (chasquid-1.15.1.tar.gz) and a Docker image. However, if you have a Debian or Ubuntu system, the software is also immediately available as a deb package:

  apt install chasquid
  setfacl -R -m u:chasquid:rX /etc/chasquid/

The configuration files are now placed in the directory ‘/etc/chasquid/’. We’ll start with the settings in the file ‘chasquid.conf’:

  cp chasquid.conf chasquid.conf.org
  vim chasquid.conf

    hostname: "server.example.nl"
    monitoring_address: "127.0.0.1:1099"

The configuration file is only short, so it doesn’t take long to go through it.

User management

The first user (and the first mail domain, if it hasn’t been created already) is created using the following command (which automatically asks for the user’s password):

  chasquid-util user-add gebruiker@example.nl

That results in the creation of a hierarchy of domains and users under the ‘./domains/’ directory.

However, it’s more convenient to (additionally) piggyback on Dovecot’s user management and authentication. That’s done using the setting in the ‘/etc/chasquid/chasquid.conf’ configuration file:

  dovecot_auth: true

Manual work

Chasquid is designed to be easily integrated with separately managed installations of Let’s Encrypt (for the TLS certificates) and Dovecot (a popular security-focused IMAP/POP server). However, integration does require a certain amount of manual work.

We’ll start with Let’s Encrypt, following the Chasquid user manual:

  apt install certbot acl
  certbot certonly --standalone -d mail.example.nl

Once that certificate has been retrieved (it’s installed in the ‘/etc/letsencrypt/’ directory), it has to be made available for Chasquid:

  setfacl -R -m u:chasquid:rX /etc/letsencrypt/{live,archive}
  mv /etc/chasquid/certs/ /etc/chasquid/certs-orig
  ln -s /etc/letsencrypt/live/ /etc/chasquid/certs

Let's Encrypt certificates are valid for 3 months. The following short shell script (contained in a here-document below) prompts Chasquid (and Dovecot) to automatically restart so as to load the updated certificates:

  mkdir -p /etc/letsencrypt/renewal-hooks/post/
  cat <<EOF | tee /etc/letsencrypt/renewal-hooks/post/restart
    #!/bin/bash
    systemctl restart chasquid
    systemctl restart dovecot
    EOF
  chmod +x /etc/letsencrypt/renewal-hooks/post/restart

Note that you do need to follow the Let’s Encrypt file structure in the ‘/etc/chasquid/certs/’ directory if you want to organise your certificates another way:

• example.nl/

  • privkey.pem

  • cert.pem

  • fullchain.pem

Dovecot user management and authentication

As you can see above, Chasquid can do its own user management. However, it’s also possible to piggyback on the user management and authentication functionalities of the Dovecot IMAP/POP server. Because Chasquid is designed to work in tandem with Dovecot, we advise using both in combination.

Dovecot is installed as follows:

  apt install dovecot-imapd dovecot-pop3d dovecot-lmtpd

The Dovecot user authentication can then be made accessible for Chasquid as follows:

  cat <<EOF | tee /etc/dovecot/conf.d/11-chasquid.conf
    # Allow chasquid to authorize users via dovecot.
    service auth {
      unix_listener auth-chasquid-userdb {
        mode = 0660
        user = chasquid
      }
      unix_listener auth-chasquid-client {
        mode = 0660
        user = chasquid
      }
    }
    EOF

Note: That configuration has been copied from the Chasquid documentation. Check whether the configuration you’re using is consistent with the latest version, which is available online.

For the configuration of Dovecot itself, refer to the software documentation: https://doc.dovecot.org/latest/.

Mail delivery

By default, Chasquid is set up to perform mail delivery using maildrop (part of the Courier mail server). To call up Dovecot for delivery of inbound messages, the default setting needs to be amended as follows (in the configuration file '/etc/chasquid/chasquid.conf'):

  # Deliver email via lmtp to dovecot.
  mail_delivery_agent_bin: "/usr/bin/mda-lmtp"
  mail_delivery_agent_args: "--addr"
  mail_delivery_agent_args: "/run/dovecot/lmtp"
  mail_delivery_agent_args: "-f"
  mail_delivery_agent_args: "%from%"
  mail_delivery_agent_args: "-d"
  mail_delivery_agent_args: "%to_user%"

To get Chasquid to piggyback on Dovecot’s authentication:

  # Use dovecot authentication.
  dovecot_auth: true

Anti-spam and anti-virus

If you install SpamAssassin and ClamAV, Chasquid will use them automatically (by means of hooks):

  apt install spamassassin spamc
  apt install clamdscan

The same applies to greylistd.

With Ubuntu, ‘spamd.service’ and ‘clamav-freshclam.service’ are started automatically once installed:

  systemctl status spamd.service
  systemctl status clamav-freshclam.service

You don’t therefore need to give them any further thought.

Native DKIM

Native DKIM support was also recently added to Chasquid (from version 1.14). The signing of outbound messages requires only the generation of a DKIM key pair:

  chasquid-util dkim-keygen example.nl

The new key pair can then be found in the file ‘/etc/chasquid/domains/example.nl/dkim:20250418.pem’. At the same time, Chasquid provides the DKIM record for the selector (‘20250418’):

  root@server:/etc/chasquid# chasquid-util dkim-keygen example.nl
  Key written to "/etc/chasquid/domains/example.nl/dkim:20250418.pem"

  20250418._domainkey.example.nl    TXT
      "v=DKIM1; k=rsa; p=MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKCAYEAnPU4iFLX+/Fllud5lliueK42fas2xuquYCvWKBPdDYDfxYZ6KwsraWzpFqW80ZQKoVoP46T3PTSyaJKyIP6YC3BQqB52lQxT2FNijAzAIKXGdskuchiRWpklGJcrq7k1CkLfF9qfDeNRIGNg8eT67lCtX6FVL3vsvuGMeJDhPfXyhUIHvVszWoR8x/7SUN2xCGyWQdSWkAlwcuPFRqRS0JLHxjXKlDrUVWMUPnPx9VoFKDPjhZefxNyQuRYTTF0MjuN/BTPOnlSWvTmGLDd0o/4lwyQV9aGjX0edIkpX5KoaOqG/0GaHrJ6WrEdrgVOi3M/i3iUYXXvnTJShiinyXTDLHistisH89zmJefusOdOuSIUbxmaIKwWJnazr6jlkusc8RUBEquSxTyl/CDvAt6MEbaHM6fYKJ5nB+yCwdXqu2Bu4EdynssmoJkRXkvQnLW3UZKpQgiIw4T7okQKq2mRNg32JZREBgnG98YdTE0NTgm6+aIL33UTULDJWW5kfAgMBAAE="

If you want, you can also choose your own selector or have multiple DKIM signatures attached to outbound mail.

Chasquid validates the DKIM signatures on inbound messages as a matter of course. Any message that fails validation is given an ‘Authentication-Results’ header, but is not blocked.

Other DNS records

Our basic mail system is now complete. For information about the other DNS records (that Chasquid doesn’t generate for you), see the corresponding passages of the section on Mox. Note, however, that Chasquid opens not only port 465 (Secure SMTP Submission) but also port 587 (SMTP Submission + STARTTLS).

The final thing that remains to be done is to start up the Chasquid server:

  systemctl restart chasquid.service

After that, we can open the administrator’s (local) monitoring interface: http://127.0.0.1:1099/.

#3: Stalwart

The Stalwart Mail Server is in principle a commercial product designed for scalability and security. However, the developers – Stalwart Labs – also provide a Community edition in open-source form (following the ‘open core’ model). The Community edition lacks the enterprise functionality, including AI, SAML authentication, monitoring, clustering, multi-tenancy, branding, undelete and support. Nevertheless, protection against spam, phishing and other malware is included in all editions.

Stalwart is written in Rust, a relatively new language with built-in memory safety, intended for programming fast system and network software. For our evaluation, we installed Stalwart Community version 0.11.7.

Installation script

We begin by downloading an installation script, which then installs the most recent software for us (by default in the directory ‘/opt/stalwart-mail/’):

  curl --proto '=https' --tlsv1.2 -sSf https://get.stalw.art/install.sh \
      -o install.sh
  sh install.sh

After that, we perform the rest of the configuration and administration via the web interface (note that the password for ‘admin’ is provided by the installation script): http://localhost:8080/login.

Note that the Stalwart server is started up immediately after installation. You can manage the service under the name ‘stalwart-mail.service’ using Systemd:

  systemctl status stalwart-mail.service

As an alternative to the installation script, a Docker image for Stalwart is also available.

Professional interface

Stalwart offers a neat, professional interface, where we start our configuration by creating a new domain (‘example.nl’) and a new user (‘user@example.nl’).

By default, all data is saved in embedded RocksDB databases, but a wide variety of other options are available for the various components, including cloud storage.

Listeners

On the ‘Settings’ → ‘Listeners’ screen, we can see which Listeners (software components for serving inbound connections) are available. In addition to the above, there is Sieve (on port 4190), a specification language and portal for managing mail filters centrally on the server.

Another is JMAP, a modern alternative to IMAP, based on JSON and HTTP.

Finally, like Mox, Stalwart also supports Autoconfiguration/Autodiscovery.

TLS certificates

Using the TLS settings in ‘Setting’ → ‘TLS’, you can add (or ‘create’ in the terminology of the interface) certificates yourself, or have them generated by an ACME provider (e.g. Let’s Encrypt).

DANE records

The system doesn’t provide DANE records for publication, but it’s easy to create them yourself on the basis of the certificate:

  [root@server example.nl]$ openssl x509 -in ./cert.pem -outform DER |
      openssl sha256
  SHA2-256(stdin)= f61bf58d20d9a3898a02a2ff031e6103d267c9e86e05fccba73b5de109b1032f

That hash value can then be added straight to your TLSA record:

  # DANE for mail
  _25._tcp.mx.example.nl        IN    TLSA    3 0 1
      f61bf58d20d9a3898a02a2ff031e6103d267c9e86e05fccba73b5de109b1032f

The settings for outbound mail are found under ‘Settings’ → ‘SMTP’ → ‘Outbound’ → ‘TLS’. They include various options for the use of STARTTLS and the validation of DANE and MTA-STS. There are also numerous settings for (TLS-related) TLSRPT reports.

SPF, DKIM and DMARC

In the same ‘SMTP’ menu are several configuration pages for SPF, DKIM, DMARC and ARC. The first 3 have separate settings for generating report messages. Where SPF and DMARC are concerned, only validation is covered. In the DKIM settings, you can see that 2 DKIM key pairs have immediately been created for our domain ‘example.nl’, for signing outbound messages.

DNS records

Once you’ve created a mail domain, go to ‘Directory’ → ‘Domains’, where you’ll see that the menu for the new domain includes an option ‘View DNS records’. Using that option, you can view all the information for the necessary DNS records and the zone file.

#4: Maddy

Maddy sits somewhere between Chasquid and Mox. The software is (also) written in Go and made up of functional modules, which are linked together during configuration to form an MTA. Support for SPF, DKIM, DMARC, DANE and MTA-STS is built in.

Maddy has its own IMAP implementation, but it’s still under development. For business use, the advice is to combine Maddy with Dovecot for the time being (as with Chasquid). Use of Unbound as a validating resolver (as with Mox) is also recommended.

The developers say that the software should currently be regarded as a beta product.

Installation from the source code

Maddy can be installed from the source code or as a Docker image. For our evaluation, we used the source code for version 0.8.1.

  apt install golang [gcc libc6-dev make]
  apt install git
  git clone https://github.com/foxcpp/maddy.git
  cd maddy/
  git checkout v0.8.1
  ./build.sh
  ./build.sh install

The final command above causes all the components to be put in place, including a service file for Systemd.

Because Maddy runs under a normal user, we need to create a Unix account for that user.

  systemctl daemon-reload
  useradd -mrU -s /sbin/nologin -d /var/lib/maddy -c "maddy mail server" maddy

Basic configuration

Maddy’s basic configuration is limited to definition of the host name and the primary domain:

  cp /etc/maddy/maddy.conf /etc/maddy/maddy.conf.org
  vim /etc/maddy/maddy.conf

    $(hostname) = mail.example.nl
    $(primary_domain) = example.nl
    tls file /etc/maddy/certs/$(primary_domain)/fullchain.pem
             /etc/maddy/certs/$(primary_domain)/privkey.pem

As you can see from the configuration file, Maddy expects its TLS certificates to be in the directory ‘/etc/maddy/certs/’. However, we have modified the path in the configuration to ‘primary_domain’, so that the domain name is used instead of the host name.

If you use Let’s Encrypt for your certificates, you can use a symlink, just as described above for Mox:

  setfacl -R -m u:maddy:rX /etc/letsencrypt/{live,archive}
  ln -s /etc/letsencrypt/live/ /etc/maddy/certs

Maddy reloads its certificates once a minute, so there’s no need to restart the server after refreshing or adding certificates.

First start-up

You’re now ready to start Maddy as follows:

  systemctl start maddy
  systemctl status maddy

As the following screenshot shows, Maddy creates a DKIM key pair for you as part of the first run. The DKIM settings that you need to add to your zone under the label ‘default._domainkey.example.nl’ are found in the file ‘/var/lib/maddy/dkim_keys/example.nl_default.dns’ (‘where default’ is the name of the DKIM selector).

The documentation provides examples of all the DNS records that you need to add for SPF, DKIM, DMARC, DANE, MTA-STS and TLSRPT. If – as we strongly recommend – you use DANE anchoring, MTA-STS has no added benefit. Maddy supports the validation of both for inbound mail, as well as the validation of SPF, DKIM and DMARC.

First user

Once your server is running and you’ve added all the necessary DNS records to your zone, it’s time to create the first user. Maddy saves user data in an embedded SQLite database.

  maddy creds create gebruiker@example.nl
  maddy imap-acct create gebruiker@example.nl

The first command creates the user, while the second creates an IMAP store for the user’s mail (which can also be an S3 bucket).

That separation may initially seem odd, but enables you to do things such as create multiple IMAP stores for the same user, or use a single store for multiple mail addresses.

Universal support

We were pleasantly surprised by the universal support for modern security standards provided by the 4 mail servers we looked at. Such support means that the systems are suitable for use in a world currently (still) dominated by the big mail service providers. Consequently, it’s now reasonably straightforward for a hobbyist or small professional service provider with some Linux know-how to set up their own mail system – something that was very hard to do until recently. In fact, with modern security standards integrated into all of them, the most suitable option can be selected from a range of servers on the basis of other features.

• Mox appears to be a fairly comprehensive solution, and is very easy to set up. What’s more, it’s a completely Dutch product, featuring its own (reputation-based) ‘anti-spam’ system and webmail interface. As such, it’s an ideal server for SOHO/SME users. The developers have published the roadmap for Mox, which can be found at the bottom of this page. One of the developers’ original design goals was to create a mail server that achieved a 100 per cent score on the Internet.nl test portal.

• Whereas Mox aims to be a comprehensive mail solution, Chasquid is more of an MTA. Setting it up involves a little more work and requires more Unix knowledge. It may be an attractive option for anyone looking for a clean but complete MTA for integration with other Unix software.

• The main advantage of Stalwart is that you can start with the free Community edition and possibly migrate to one of the paid editions later. That approach can be attractive for the same reasons as starting with Fedora Linux, AlmaLinux and/or Rocky Linux before going over to RHEL support at a later date. The Stalwart web interface looks neat, but does have a lot of configuration pages featuring a huge number of settings. However, many are (currently?) just small text fragments, which makes us wonder whether it wouldn’t be better to have all the settings in a textual configuration file.

• Maddy sits between Chasquid and Mox. Because the developers themselves say that this software should currently be regarded as a beta product, we would advise against using Maddy in a production environment for now.

You can check whether your set-up does indeed conform to all the modern internet standards for mail by visiting the Internet.nl test portal: https://internet.nl/.

Democratisation of the mail infrastructure

What all 4 of the mail systems we looked at have in common is that they are relatively new and part of a movement away from the big mail providers. The development of both Mox [1, 2, 3] and Stalwart [1, 2] benefitted from financial support through NLnet [1, 2] from the European Commission’s Next Generation Internet (NGI) programme.

Funding from the programme was intended to promote the availability of secure, independent and accessible mail systems for self-hosting, and was on condition of publication as open-source software, user-convenience, and support for modern security and other standards. The decentralisation (‘democratisation’) of the mail infrastructure is necessary for us to regain control over our data and communications.