Stalwart installieren – vom leeren Server zur ersten Mail

Im Vergleich mit Mailcow habe ich erklärt, warum ich mich für Stalwart entschieden habe. Jetzt wird es praktisch: In diesem Tutorial richten wir Stalwart von Grund auf ein. Am Ende steht ein Mailserver, der Mails empfängt, verschickt, bei Gmail nicht im Spam landet – und den man mit überschaubarem Aufwand gesund hält.

Stand: Oktober 2026, Stalwart 0.16. Stalwart ist noch vor Version 1.0, Details können sich ändern. Im Zweifel gilt die offizielle Dokumentation.

Als Platzhalter verwende ich durchgehend:

Teil 1: Voraussetzungen

Der Server

Stalwart ist genügsam:

• RAM: ca. 100 MB im Leerlauf, 1 GB reicht für 5–10 Nutzer
• CPU: ein Kern genügt für einen kleinen Haushalt oder Verein
• Speicher: so viel, wie deine Postfächer brauchen – plus Reserve für Backups
• System: jedes aktuelle Linux. Ich nutze Debian in einer VM unter Proxmox.

Wichtiger als die Hardware ist das, was drumherum stimmen muss.

Eine feste öffentliche IP-Adresse

Ein Mailserver braucht eine statische IP-Adresse, die von außen erreichbar ist. Ein Heimanschluss mit wechselnder IP scheidet praktisch aus: Solche Adressen stehen bei den großen Anbietern pauschal auf Sperrlisten.

Ausgehender Port 25

Der häufigste Stolperstein überhaupt. Viele Hoster sperren ausgehende Verbindungen auf Port 25, um Spam aus ihren Netzen zu verhindern. Bei einigen Cloud-Anbietern wird die Sperre erst auf Antrag oder nach einer gewissen Zeit aufgehoben.

Teste das vor der Installation:

nc -vz -w 5 gmail-smtp-in.l.google.com 25

Steht da succeeded oder open, ist alles gut. Läuft der Befehl in einen Timeout, ist Port 25 gesperrt. Dann hilft nur: beim Hoster die Freigabe beantragen oder ausgehende Mails über einen Relay-Dienst schicken.

Reverse DNS (PTR)

Die IP-Adresse des Servers muss auf seinen Hostnamen zurückzeigen. Das stellst du nicht bei deinem Domain-Anbieter ein, sondern beim Hoster des Servers – meist im Kundenmenü bei der IP-Adresse.

dig +short -x 203.0.113.10
# soll ergeben: mail.example.com.

Aus eigener Erfahrung: Wenn der Server eine IPv6-Adresse hat, braucht auch die einen PTR-Eintrag – und zwar für die konkrete Adresse, nicht nur für das /64-Netz drumherum. Gmail hat meine Mails so lange abgelehnt, bis das stimmte.

Hostname

Der Server sollte seinen eigenen Namen kennen:

sudo hostnamectl set-hostname mail.example.com
hostname -f
# mail.example.com

Docker

Ich installiere Stalwart mit Docker Compose. Das macht Updates und Versionen besonders übersichtlich. Falls Docker noch fehlt:

curl -fsSL https://get.docker.com | sudo sh

Wer lieber ohne Docker arbeitet: Am Ende dieses Teils gibt es eine Box zur Installation als normales Programm.

Teil 2: DNS – der erste Schritt

Bevor wir installieren, legen wir die beiden Einträge an, die sofort gebraucht werden. Die übrigen Einträge erzeugt Stalwart später selbst.

Prüfen:

dig +short A mail.example.com
dig +short MX example.com

DNS-Änderungen können je nach TTL etwas dauern. Gut, das vorab zu erledigen.

Teil 3: Firewall

Diese Ports müssen von außen erreichbar sein:

Port 8080 brauchen wir nur für die Ersteinrichtung – und den öffnen wir nicht nach außen, sondern erreichen ihn per SSH-Tunnel.

Achtung, Docker und ufw: Docker trägt veröffentlichte Ports direkt in iptables ein und umgeht dabei ufw. Eine Regel ufw deny 8080 hilft also nicht. Deshalb binden wir 8080 in der Compose-Datei ausdrücklich nur an 127.0.0.1. Wer eine Proxmox- oder Hoster-Firewall vor dem Server hat, sollte die Ports zusätzlich dort freigeben bzw. sperren.

Wenn 443 schon belegt ist: Läuft auf dem Server bereits ein Reverse Proxy, kann Stalwarts HTTPS-Teil dahinter hängen. Die Mailports (25, 465, 587, 993) gehören aber direkt an Stalwart – die lassen sich nicht sinnvoll durch einen Web-Proxy schleusen.

Teil 4: Installation

Verzeichnisse anlegen

sudo mkdir -p /opt/stalwart/{config,data}
sudo chown -R 2000:2000 /opt/stalwart/config /opt/stalwart/data
cd /opt/stalwart

Der Container läuft als Benutzer mit der UID 2000. Ohne das chown kann Stalwart nicht in die Verzeichnisse schreiben.

Die Compose-Datei

/opt/stalwart/docker-compose.yml:

services:
  stalwart:
    image: stalwartlabs/stalwart:v0.16   # Version festnageln, nicht "latest"!
    container_name: stalwart
    restart: unless-stopped
    ports:
      - "25:25"
      - "465:465"
      - "587:587"
      - "993:993"
      - "4190:4190"
      - "443:443"
      - "127.0.0.1:8080:8080"   # nur lokal – Einrichtung per SSH-Tunnel
    volumes:
      - ./config:/etc/stalwart
      - ./data:/var/lib/stalwart

Zwei bewusste Entscheidungen:

• v0.16 statt latest: So bekommst du Fehlerbehebungen innerhalb der Version 0.16, aber keine größeren Sprünge, ohne es zu merken. Das empfehlen die Entwickler ausdrücklich.
• Kein POP3: Ports 110 und 995 lasse ich weg. Wer POP3 nicht braucht, sollte es auch nicht anbieten.

Starten

docker compose up -d
docker compose logs -f

Das Admin-Passwort

Beim ersten Start legt Stalwart einen vorübergehenden Admin-Zugang an und schreibt das Passwort ein einziges Mal ins Log:

docker logs stalwart 2>&1 | grep -A8 'bootstrap mode'

Benutzername admin, dazu ein zufälliges Passwort mit 16 Zeichen. Gleich in den Passwortmanager kopieren.

Tipp: Wer sich nicht auf das Log verlassen will, kann einen festen Notfall-Zugang setzen. Dafür in der Compose-Datei ergänzen:

    environment:
      - STALWART_RECOVERY_ADMIN=admin:EinLangesSicheresPasswort

Besser noch über eine .env-Datei, damit das Passwort nicht in der Compose-Datei steht.

Ohne Docker: Stalwart lässt sich auch direkt installieren:

curl --proto '=https' --tlsv1.2 -sSf https://get.stalw.art/install.sh -o install.sh
sudo sh install.sh
sudo journalctl -u stalwart -n 200 | grep -A8 'bootstrap mode'

Das Programm landet unter /usr/local/bin/stalwart, die Konfiguration unter /etc/stalwart/, die Daten unter /var/lib/stalwart/. Der Rest dieses Tutorials gilt genauso – nur systemctl statt docker compose. Beachte: Das Installationsskript holt immer die neueste Version.

Teil 5: Einrichtung

SSH-Tunnel zur Weboberfläche

Auf deinem eigenen Rechner:

ssh -L 8080:127.0.0.1:8080 benutzer@mail.example.com

Solange diese Verbindung offen ist, erreichst du die Einrichtung im Browser unter:

http://127.0.0.1:8080/admin

Anmelden mit admin und dem Passwort aus dem Log.

Der Einrichtungsassistent

Der Assistent führt in wenigen Schritten durch die Grundkonfiguration. Die wichtigsten Entscheidungen:

• Hostname: mail.example.com – exakt so, wie im A- und PTR-Eintrag.
• Speicher: Für einen einzelnen Server RocksDB. Das ist schnell, braucht keine separate Datenbank und ist die Empfehlung der Entwickler.
• Logging: Im Docker-Betrieb auf Konsole, damit die Logs bei docker logs landen.
• Zertifikate: Über ACME mit Let's Encrypt. Stalwart holt und erneuert die Zertifikate selbst.

Danach den Container neu starten:

docker compose restart

Ab jetzt ist die Verwaltung über HTTPS erreichbar:

https://mail.example.com/admin

Domain anlegen und DNS vervollständigen

In der Verwaltung legst du deine Domain example.com an. Stalwart erzeugt dabei automatisch die DKIM-Schlüssel und zeigt dir alle DNS-Einträge, die für die Domain sinnvoll sind:

• SPF: wer für die Domain Mails verschicken darf
• DKIM: der öffentliche Schlüssel für die Signatur
• DMARC: was Empfänger tun sollen, wenn SPF oder DKIM fehlschlagen
• MTA-STS und TLS-RPT: erzwingen verschlüsselte Zustellung und liefern Berichte darüber
• SRV und Autoconfig/Autodiscover: damit Mail-Apps die Einstellungen selbst finden
• optional CAA und TLSA (DANE)

Diese Einträge überträgst du zu deinem DNS-Anbieter. Wird dein Anbieter von Stalwart unterstützt, kann Stalwart die Einträge sogar selbst per API anlegen und aktuell halten – etwa wenn sich DKIM-Schlüssel ändern.

Für DMARC empfehle ich zum Start eine vorsichtige Richtlinie und schärfe sie nach ein paar Wochen nach:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Wenn die Berichte zeigen, dass alles sauber durchgeht, auf p=quarantine und später p=reject erhöhen.

Das erste Postfach

In der Verwaltung ein Konto anlegen, zum Beispiel ich@example.com. Benutze dafür nicht den admin-Zugang – Verwaltung und Postfach sollten getrennte Konten sein.

Einrichtungsport schließen

Die Einrichtung ist fertig, Port 8080 wird nicht mehr gebraucht. In der Compose-Datei die Zeile entfernen:

      - "127.0.0.1:8080:8080"

und neu starten:

docker compose up -d

Teil 6: Testen

Jetzt kommt der spannende Moment.

Mail-App verbinden

In Thunderbird, auf dem Handy oder wo auch immer:

Benutzername ist die volle Mailadresse. Wenn die Autoconfig-Einträge stimmen, finden viele Apps das sogar selbst. Bei Apple-Geräten habe ich die Einstellungen trotzdem lieber von Hand eingetragen.

Mail an Gmail schicken

Schick eine Mail an eine Gmail-Adresse, öffne sie dort und wähle „Original anzeigen“. Ganz oben steht:

SPF:   PASS
DKIM:  PASS
DMARC: PASS

Dreimal PASS – dann hast du alles richtig gemacht.

Externe Prüfwerkzeuge

• mail-tester.com – Mail an eine Testadresse schicken, Punktzahl bekommen. Ziel: 10/10.
• internet.nl – prüft die Domain auf moderne Standards wie DNSSEC, DANE und MTA-STS.
• MXToolbox – prüft DNS-Einträge und Sperrlisten.

Mail von außen empfangen

Schick von einem anderen Konto eine Mail an deine neue Adresse. Kommt sie nicht an: im Log nachsehen.

docker compose logs --since 10m | grep -i -E 'error|reject|refused'

Teil 7: Regelmäßige Pflege

Ein Mailserver ist kein Projekt, das man einmal fertigstellt. Er will gepflegt werden. Mit dieser Routine bleibt der Aufwand klein.

Backups

Stalwart speichert alles in den beiden Verzeichnissen config und data. Die Entwickler empfehlen für RocksDB: Dienst kurz stoppen, Verzeichnisse kopieren, Dienst wieder starten. Im laufenden Betrieb ist eine Kopie nicht garantiert konsistent.

Klingt nach Ausfall, ist aber harmlos: Ein Backup dauert Sekunden bis wenige Minuten, und Mailserver, die in dieser Zeit zustellen wollen, versuchen es später einfach noch einmal. Das ist bei E-Mail so vorgesehen.

Ein einfaches Skript, /usr/local/sbin/stalwart-backup:

#!/bin/sh
set -eu
ZIEL=/srv/backup/stalwart
STAMP=$(date +%F_%H%M)
mkdir -p "$ZIEL"

cd /opt/stalwart

# Startet Stalwart und prüft, ob es wirklich läuft (direkt nach "stop" klappt der erste Start nicht immer)
start_stalwart() {
  for i in 1 2 3 4 5 6 7 8 9 10; do
    docker compose start stalwart >/dev/null 2>&1 || true
    sleep 3
    [ "$(docker inspect -f '{{.State.Running}}' stalwart)" = true ] && return 0
  done
  echo "Stalwart ist nach dem Backup nicht wieder gestartet!" >&2
  return 1
}

docker compose stop stalwart
trap start_stalwart EXIT   # startet auch bei Fehlern wieder

tar -czf "$ZIEL/stalwart-$STAMP.tar.gz" config data

# Backups älter als 14 Tage löschen
find "$ZIEL" -name 'stalwart-*.tar.gz' -mtime +14 -delete

sudo chmod +x /usr/local/sbin/stalwart-backup

Jede Nacht um 03:30 per Cron:

echo '30 3 * * * root /usr/local/sbin/stalwart-backup' | sudo tee /etc/cron.d/stalwart-backup

Aus eigener Erfahrung: Mein erstes Skript startete Stalwart nach dem Sichern einfach mit docker compose start. Einmal klappte das direkt nach dem Stoppen nicht, und der Mailserver stand, bis ich es morgens bemerkte. Seitdem prüft das Skript nach dem Start, ob der Container wirklich läuft, und versucht es sonst erneut.

Zwei Regeln, die man nicht oft genug sagen kann:

1. Ein Backup auf demselben Server ist kein Backup. Die Archive gehören zusätzlich woanders hin – auf einen zweiten Server, ein NAS, in einen S3-Speicher.
2. Ein Backup, das nie zurückgespielt wurde, ist eine Hoffnung. Einmal im Quartal ein Archiv auf einer Test-VM auspacken und starten.

Wer in einer VM unter Proxmox arbeitet, hat mit Snapshots und Proxmox-Backups eine zweite Sicherheitsebene obendrauf – besonders praktisch vor Updates.

Updates

Stalwart hat noch kein automatisches Update-Werkzeug, weil manche Versionen Datenumbauten mitbringen, die man im Blick haben sollte. Die Entwickler empfehlen bis Version 1.0 sogar ausdrücklich, nur dann zu aktualisieren, wenn eine neue Version etwas mitbringt, das man braucht – oder eine Sicherheitslücke schließt.

Die Faustregel nach dem Versionsschema:

• Patch-Versionen (0.16.x): kleine Fehlerbehebungen, unkritisch
• Minor-Versionen (0.x.0): können Konfigurationsänderungen oder Datenumbauten mitbringen – vorher die Release Notes lesen

Ein Update innerhalb von 0.16:

cd /opt/stalwart
/usr/local/sbin/stalwart-backup   # vorher sichern!
docker compose pull
docker compose up -d
docker compose logs -f

Für einen Sprung auf eine neue Minor-Version (etwa auf 1.0) zusätzlich in der Compose-Datei das Tag anpassen – aber erst, nachdem du die Release Notes gelesen hast. Auch innerhalb einer Version lohnt ein Blick hinein: Im August verlangte ein Update für Installationen mit MySQL oder MariaDB einen manuellen Datenbankbefehl. Wer RocksDB nutzt, war nicht betroffen – wissen sollte man so etwas trotzdem.

Tipp: Die Release-Seite auf GitHub lässt sich abonnieren („Watch“ → „Custom“ → „Releases“). Dann kommt jede neue Version als Benachrichtigung.

Und natürlich das Betriebssystem selbst:

sudo apt update && sudo apt upgrade

Was man regelmäßig anschauen sollte

Wöchentlich (5 Minuten)

• Warteschlange: Bleiben ausgehende Mails hängen? Das sieht man in der Verwaltung unter der Mail-Warteschlange. Viele hängende Mails an einen Anbieter sind ein Frühwarnzeichen für ein Reputationsproblem.
• Logs auf Auffälligkeiten durchsehen:

  docker compose logs --since 7d | grep -i -E 'error|warn' | tail -50
  

• Speicherplatz:

  df -h /opt/stalwart /srv/backup
  

Monatlich (15 Minuten)

• DMARC-Berichte lesen. Die großen Anbieter schicken täglich Berichte an die rua-Adresse. Darin steht, ob deine Mails durchgehen – und ob jemand anderes in deinem Namen Mails verschickt.
• TLS-Berichte (TLS-RPT) prüfen: Scheitern Zustellungen an deinen Server an Verschlüsselungsproblemen?
• Sperrlisten prüfen, z. B. bei MXToolbox. Taucht deine IP auf einer Liste auf, steht dort meist auch, wie man wieder herunterkommt.
• Zertifikat: Stalwart erneuert selbst. Ein kurzer Kontrollblick schadet nicht:

  echo | openssl s_client -connect mail.example.com:465 2>/dev/null | openssl x509 -noout -enddate
  

• Release Notes neuer Versionen überfliegen.

Vierteljährlich

• Backup zurückspielen und testen.
• Konten aufräumen: Wer braucht sein Postfach nicht mehr?
• DMARC-Richtlinie prüfen – Zeit, von p=none auf quarantine oder reject zu gehen?

Sicherheit

• Admin-Zugang mit langem Passwort und Zwei-Faktor-Anmeldung absichern. Stalwart unterstützt TOTP.
• Für Mail-Apps App-Passwörter verwenden statt des Hauptpassworts.
• Brute-Force: Stalwart sperrt IP-Adressen, die wiederholt falsche Anmeldungen versuchen, von sich aus. Ein Blick in die Liste gesperrter Adressen zeigt eindrucksvoll, wie viel da draußen klopft.
• Kein offenes Relay: Stalwart nimmt Mails zum Weiterversand standardmäßig nur von angemeldeten Nutzern an. Das sollte so bleiben. Testen lässt es sich zum Beispiel bei MXToolbox.

Fazit

Wer die Vorarbeit sauber macht – feste IP, Port 25 offen, PTR gesetzt –, hat Stalwart in einer Stunde am Laufen. Der eigentliche Aufwand liegt nicht in der Installation, sondern in der Geduld: DNS-Einträge sorgfältig setzen, Berichte lesen, Reputation aufbauen.

Danach ist ein eigener Mailserver kein Schreckgespenst mehr, sondern ein Dienst wie jeder andere in der Werkstatt. Mit einer festen Routine für Backups und Updates bleibt er das auch.

Quellen: Stalwart – Installation unter Linux · Stalwart – Installation mit Docker · Stalwart – Systemvoraussetzungen · Stalwart – DNS-Einrichtung · Stalwart – Updates · Stalwart Support-Forum – RocksDB sicher sichern