Quick start

Install Nixt Server, run init, publish DNS, start the service, verify your domain, create an account and exchange your first messages.

This page takes one Linux machine from nothing to a working mail server for one domain. It uses mail.example.com as the server’s host name and example.com as the mail domain; use your own names throughout.

Before you start, read Requirements. You need a public address that other servers can reach on port 25, a PTR record for it, and access to your domain’s DNS.

1. Install the package

Get Nixt Server from the Download page, then install the package for your distribution:

# Debian and Ubuntu
sudo apt install ./versealx-server_<version>_amd64.deb

# Fedora, RHEL and similar
sudo dnf install ./versealx-server-<version>.x86_64.rpm

The package installs:

PathWhat it is
/usr/bin/versealx-serverThe server and its command-line tool.
/usr/lib/systemd/system/versealx-server.serviceThe systemd service.
/etc/versealx-server/versealx-server.toml.exampleAn annotated example configuration.
/var/lib/versealx-serverThe data directory, owned by the versealx user.

It also creates the versealx system user and group. It does not start the server: a mail server that is not configured yet should not be answering on port 25.

2. Run init

init writes the configuration, creates the data directory, creates your first tenant, domain and administrator account, generates DKIM keys, and prints every DNS record the domain needs. Run it as the versealx user so that everything it writes belongs to the service:

sudo -u versealx versealx-server init --hostname mail.example.com --domain example.com

Useful options:

OptionWhat it does
--self-signedAlso writes a certificate for the host name, signed by nobody but itself, so the server can start at once. Only you will trust it. Use it for a first test.
--relay smtp.relay.example.net:587Sends outgoing mail through that relay, and prints an SPF record that includes it. Use it when this machine cannot deliver mail directly.
--admin you@example.comThe administrator’s address. Defaults to postmaster@<domain>.

Every option is on the Command-line reference.

init refuses to run if the configuration file already exists, so it never replaces a working configuration.

What init prints

The output has four parts. Keep the terminal open or copy it somewhere safe.

  1. Where it wrote the configuration: Wrote /etc/versealx-server/versealx-server.toml.
  2. The certificate. Either where the self-signed certificate is and its SHA-256 fingerprint, or where to put your own certificate and key.
  3. Publish these records: every DNS record, one per line.
  4. The administrator’s password, after Then sign in as postmaster@example.com with:. It is shown once and stored only as a hash.

It ends with the command that marks the domain verified, and a reminder to run doctor once the server is up.

3. Put a certificate in place

The server will not start without a certificate. Choose one:

  • You ran --self-signed. Nothing to do for now. Mail apps will ask whether to trust the certificate; give their users the fingerprint init printed.
  • You have a certificate. Copy the PEM certificate chain and key to the paths init printed — /var/lib/versealx-server/tls/certificate.pem and /var/lib/versealx-server/tls/key.pem — and make them readable by the versealx user.
  • You want the server to get one. Change the [tls] table to use ACME, and make sure port 80 is reachable from the internet. See TLS certificates.

4. Publish the DNS records

Enter the records init printed at your DNS provider. At minimum:

To…Publish
Receive mailThe A (and AAAA) record for mail.example.com, and the MX record for example.com.
Send mail other servers acceptThe SPF record, both DKIM records and the DMARC record.
Prove the domain is yoursThe _versealx-verify token, a DKIM record, or the MX record. Any one of them is enough.
Let apps configure themselvesThe SRV records.
Publish an MTA-STS policy and receive TLS reportsThe _mta-sts and _smtp._tls records and the mta-sts CNAME.

DNS records explains each record and the mistakes DNS control panels invite.

5. Check the configuration and start the service

sudo -u versealx versealx-server check --config /etc/versealx-server/versealx-server.toml

When the file is valid, check prints what will run:

ok: node `mail.example.com` as mail.example.com with roles mx, submission, relay, filter, store, deliver, dav, admin, serve

Otherwise it prints versealx-server: refusing to start: followed by the reason.

Start the server and have it start at boot:

sudo systemctl enable --now versealx-server

The service runs check again before every start, and systemctl start returns once every listener is bound. If it fails, journalctl -u versealx-server shows why; Troubleshooting lists the start-up messages.

6. Mark the domain verified

The server answers autoconfig, Autodiscover and MTA-STS requests only for domains marked verified. Once the _versealx-verify record is published, run the command init printed at the end:

vsx admin post tenants/1/domains/example.com/verify

The answer is the domain record with "verified": true. The same command makes the server check DNS for proof that the domain is yours straight away; vsx admin get tenants/1/domains/example.com shows what it found under ownership, which moves from Pending to Proved once a proof is published and seen. If you run the command before the records have spread, run it again later.

7. Run doctor

vsx doctor

doctor checks the host name, the certificate, the clock, your resolver, reverse DNS, any DANE record, the store, and for each domain the MX, SPF, ownership token, DMARC, every DKIM key, MTA-STS and TLS reporting. Each line starts with ok, warn or BAD, and every problem comes with what to do about it. DNS changes can take a while to appear; run it again until it is content. See Monitoring for every check.

8. Create an account

Create a person’s account:

vsx admin post tenants/1/accounts address=alex@example.com "displayName=Alex Morgan"

The answer includes the new account’s id. A new account has no password, so give it one:

vsx admin put tenants/1/accounts/2/password "password=<a password of 14 or more characters>"

A new organisation starts at the Strict security profile (see Security posture), so passwords must be at least 14 characters, at most 256, and must not contain the part of the address before the @ when that part is three characters or longer. See Domains and accounts.

9. Change the administrator’s password

List the accounts to find the administrator’s id — init makes it the first account, id 1 — and set a password you choose:

vsx admin get tenants/1/accounts
vsx admin put tenants/1/accounts/1/password "password=<a new password>"

10. Connect a mail app and exchange messages

  1. Strict asks everyone for a second step, and a mail app that cannot ask for a code signs in with an app password instead of the account’s own. Open https://mail.example.com/account/app-passwords, sign in as alex@example.com, add an authenticator app when asked, and make an app password for your mail app. See App passwords.
  2. In your mail app, add an account for alex@example.com with that app password. Apps that support automatic setup find the server from the SRV and autoconfig records; otherwise use the settings on Connecting mail apps. Apps that sign in through the server’s own page, such as Nixt Mail, use the account’s own password and ask for the code there.
  3. From an account at another provider, send a message to alex@example.com. It should arrive within seconds.
  4. From alex@example.com, reply to that message. Check that it arrives, and look at its headers at the other end for dkim=pass and spf=pass.

If a message does not arrive, find it with the message trace:

vsx admin get trace tenant=1 address=alex@example.com day=2026-09-14

Next steps

Something unclear or out of date on this page? Tell us.