Was bauen wir?

Am Ende erkennen große Mailanbieter (Gmail, Outlook, GMX & Co.) deine Mails als authentisch und liefern sie in den Posteingang statt in den Spam. Dafür sorgen vier Mechanismen, die zusammenspielen:

• Reverse DNS (PTR): beweist, dass deine Server-IP zu deinem Mail-Hostnamen gehört – die Grundvoraussetzung, ohne die viele Server gar nicht erst annehmen.
• SPF: legt fest, welche Server im Namen deiner Domain senden dürfen.
• DKIM: signiert jede ausgehende Mail kryptografisch, sodass Manipulation und Fälschung auffliegen.
• DMARC: sagt den Empfängern, was zu tun ist, wenn SPF oder DKIM fehlschlagen – und schickt dir Berichte.

Der Nutzen ist doppelt: Deine eigenen Mails kommen zuverlässig an – und niemand kann in deinem Namen fälschen. Ohne diese Records kann jeder Angreifer Mails mit deiner Absenderdomain verschicken („Spoofing") und damit Phishing in deinem Namen betreiben. SPF, DKIM und DMARC machen genau das unmöglich: Sie verwandeln deine Domain von einem offen missbrauchbaren Absender in einen nachweisbar echten. Gerade wenn Kund:innen oder Kolleg:innen Mails von dir erwarten, ist dieser Schutz mindestens so wichtig wie die Zustellbarkeit selbst.

Diese vier Records sind unabhängig von deiner Server-Software. Ob du Mailcow oder Stalwart betreibst, ist egal – die Zustellbarkeit konfigurierst du im DNS und beim Provider.

Voraussetzungen

• Ein laufender Mailserver unter deiner Domain (z. B. aus dem Mailcow- oder Stalwart-Tutorial).

• Voller Zugriff auf die DNS-Zone deiner Domain (siehe Domain mit dem Server verbinden).

• Zugriff auf das Provider-Panel, um den Reverse-DNS-Eintrag der Server-IP zu setzen (bei netcup im SCP).

• Das Werkzeug dig zum Prüfen der Records:

  Terminal

  sudo apt install -y bind9-dnsutils

Schritt für Schritt

Schritt 1: Reverse DNS (PTR) setzen – das Fundament

Der wichtigste und am häufigsten vergessene Eintrag. Während ein normaler DNS-Eintrag einen Namen in eine IP auflöst, macht der PTR-Eintrag das Gegenteil: Er löst deine Server-IP zurück in einen Namen auf. Empfänger prüfen, ob dieser Name zu deinem Mail-Hostnamen passt. Fehlt der PTR oder zeigt er auf einen generischen Provider-Namen, gilt dein Server als verdächtig.

Den PTR-Eintrag setzt du nicht in deiner DNS-Zone, sondern beim Provider, dem die IP gehört. Bei netcup gehst du dazu ins Server Control Panel (SCP) → Netzwerk / Reverse DNS und trägst für deine IP den Wert mail.DEINE_DOMAIN ein. Nach der Propagierung prüfst du:

dig +short -x DEINE_SERVER_IP

mail.deine-domain.de.

Kommt hier mail.DEINE_DOMAIN zurück, stimmt der PTR. Zeigt er noch auf etwas wie vXXXXXXXXX.example-provider.net, ist er noch nicht gesetzt oder nicht propagiert.

Schritt 2: SPF – wer darf in deinem Namen senden?

Der SPF-Record ist ein TXT-Eintrag in deiner DNS-Zone. Er listet die IPs bzw. Hostnamen, die Mails für deine Domain versenden dürfen. Für einen einzelnen Mailserver genügt:

DEINE_DOMAIN.   TXT   "v=spf1 a:mail.DEINE_DOMAIN -all"

Zerlegt:

• v=spf1 – die SPF-Version.
• a:mail.DEINE_DOMAIN – der Server hinter diesem A-Record darf senden. Alternativ direkt die IP mit ip4:DEINE_SERVER_IP (und ip6:… bei IPv6).
• -all – alle anderen Server sind nicht autorisiert („hard fail"). Das ist die strenge, empfohlene Variante. Ein ~all („soft fail") ist nachsichtiger, aber weniger wirksam.

Prüfen – und zwar mit Filter:

dig +short TXT DEINE_DOMAIN | grep spf1

"v=spf1 a:mail.deine-domain.de -all"

Das grep ist kein Luxus: dig +short TXT gibt alle TXT-Einträge deiner Zone aus, und dort sammeln sich mit der Zeit Verifikations-Token von Google, Microsoft & Co. an. Real nachgemessen – google.com antwortet mit 16 TXT-Einträgen, microsoft.com mit 61. Ohne Filter suchst du deinen SPF-Record von Hand heraus. Kommt gar nichts zurück, existiert kein SPF-Record. Kommen zwei Zeilen zurück, hast du zwei SPF-Records – und das ist ein Fehler, siehe „Wenn es nicht funktioniert".

Versendest du zusätzlich über Dritte – etwa einen Newsletter-Dienst oder das Transaktionsmail- Gateway einer App – gehören deren Server ebenfalls autorisiert. Das machst du über include:, und zwar in einem einzigen Record:

DEINE_DOMAIN.   TXT   "v=spf1 a:mail.DEINE_DOMAIN include:_spf.dienstleister.de -all"

Schritt 3: DKIM – jede Mail kryptografisch signieren

DKIM signiert jede ausgehende Mail mit einem privaten Schlüssel; den passenden öffentlichen Schlüssel legst du als DNS-Record ab. Empfänger prüfen damit, dass die Mail wirklich von dir kommt und unterwegs nicht verändert wurde.

So läuft es ab: Beim Versand berechnet dein Server aus wichtigen Kopfzeilen und dem Nachrichtentext eine Signatur und hängt sie als DKIM-Signature-Header an. Der Empfänger holt sich deinen öffentlichen Schlüssel aus dem DNS und prüft die Signatur. Passt sie, ist bewiesen: Die Mail stammt von einem Server mit deinem privaten Schlüssel und wurde nicht verändert. Nimm 2048-Bit-Schlüssel – 1024 Bit gelten als zu schwach, und die meisten DNS-Anbieter kommen mit der Schlüssellänge inzwischen problemlos zurecht.

Den Schlüssel erzeugt dein Mailserver – du musst nur den DNS-Record veröffentlichen:

• In Mailcow: Konfiguration → ARC/DKIM-Schlüssel, Domain auswählen, Schlüssel erzeugen (2048 Bit). Mailcow zeigt dir den fertigen DNS-Record an.
• In Stalwart: Die Schlüssel entstehen im Einrichtungs-Assistenten; den Record findest du in der Konsole unter der jeweiligen Domain.

Der Record hat einen Selector (einen frei gewählten Namen, z. B. dkim oder default) und sieht so aus:

dkim._domainkey.DEINE_DOMAIN.   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkq...LANGER_PUBLIC_KEY...AQAB"

Übernimm den Wert exakt so, wie dein Mailserver ihn ausgibt. Prüfen:

dig +short TXT dkim._domainkey.DEINE_DOMAIN

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…ERSTER_TEIL" "ZWEITER_TEIL…AQAB"

Wundere dich nicht über die zwei Blöcke in Anführungszeichen: Eine einzelne Zeichenkette in einem TXT-Eintrag darf höchstens 255 Bytes tragen, ein 2048-Bit-Schlüssel ist länger. Er steht im DNS deshalb zwangsläufig als zwei aneinandergehängte Zeichenketten, und dig zeigt genau das. Das ist kein abgeschnittener Schlüssel – Empfänger setzen die Teile beim Prüfen wieder zusammen. Die meisten DNS-Panels übernehmen die Aufteilung automatisch; verlangt deines den Wert am Stück, trägst du ihn ohne Anführungszeichen und ohne Zeilenumbrüche ein.

Kommt der v=DKIM1; …-Wert zurück, ist der öffentliche Schlüssel veröffentlicht.

Schritt 4: DMARC – Regeln und Berichte

DMARC verbindet SPF und DKIM: Es sagt Empfängern, wie sie mit Mails umgehen sollen, die die Prüfung nicht bestehen, und lässt dir Berichte über die Nutzung deiner Domain schicken. Ein guter Einstiegs-Record:

_dmarc.DEINE_DOMAIN.   TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc@DEINE_DOMAIN; adkim=s; aspf=s"

Zerlegt:

• p=quarantine – nicht bestandene Mails sollen in den Spam wandern. Zum Start empfiehlt sich p=none (nur beobachten, nichts aussortieren), damit du erst die Berichte auswertest, bevor du scharf schaltest. Später gehst du auf quarantine und schließlich p=reject.
• rua=mailto:dmarc@DEINE_DOMAIN – an diese Adresse kommen die aggregierten Berichte (lege das Postfach vorher an).
• adkim=s / aspf=s – strenge Ausrichtung (der signierende bzw. sendende Absender muss exakt zur Domain passen). Der Standard laut Spezifikation ist r (relaxed) – dann genügt dieselbe Organisationsdomain, mail.DEINE_DOMAIN und DEINE_DOMAIN gelten also als ausgerichtet. Für einen einzelnen Mailserver, der alles unter derselben Domain versendet, ist s die schärfere und passende Wahl; sobald Dienste auf Subdomains mitsenden, setzt du auf r zurück.

Prüfen:

dig +short TXT _dmarc.DEINE_DOMAIN

"v=DMARC1; p=quarantine; rua=mailto:dmarc@deine-domain.de; adkim=s; aspf=s"

Schritt 5: Alles zusammen testen

Jetzt der Realitätscheck. Drei Werkzeuge – vom Gesamtbild bis zum Einzel-Record:

1. mail-tester.com: Der holistische Test. Öffne die Seite, sie zeigt dir eine Zufalls-Adresse. Schick von deinem neuen Postfach eine ganz normale Mail dorthin und klick auf „Then check your score". Du bekommst eine Wertung von 10/10 aufgeschlüsselt nach SPF, DKIM, DMARC, Reverse DNS, Inhalt und Blocklisten. Alles unter 10 zeigt dir konkret, woran es hakt.

2. Einzel-Validatoren pro Record. Zum gezielten Debuggen prüfst du jeden Baustein separat online: Du gibst deine Domain ein (bei DKIM zusätzlich den Selector, z. B. dkim) und bekommst Syntax, aufgelöste Werte und Warnungen angezeigt:

   • SPF: MXToolbox SPF-Check – zeigt auch, ob du das 10-Lookup-Limit reißt.
   • DKIM: MXToolbox DKIM-Check – Domain und Selector angeben.
   • DMARC: MXToolbox DMARC-Check – prüft Syntax und Policy; der dmarcian DMARC-Inspector zeigt die Policy besonders anschaulich.

3. Gegenprobe per dig: Prüfe alle vier Bausteine noch einmal in einem Rutsch:

   Terminal

   dig +short -x DEINE_SERVER_IP                  # PTR
   dig +short TXT DEINE_DOMAIN | grep spf1        # SPF
   dig +short TXT dkim._domainkey.DEINE_DOMAIN    # DKIM
   dig +short TXT _dmarc.DEINE_DOMAIN             # DMARC

Ein besonders guter Praxistest: Schick eine Mail an ein Gmail-Konto, öffne dort die Mail, und über „Original anzeigen" siehst du direkt SPF: PASS, DKIM: PASS und DMARC: PASS. Erst wenn alle drei auf PASS stehen, bist du auf der sicheren Seite.

Schritt 6: DMARC-Berichte auswerten und scharf schalten

An deine rua-Adresse trudeln nach ein bis zwei Tagen die ersten DMARC-Berichte ein – XML-Dateien von den Empfänger-Servern, die zeigen, welche Quellen unter deiner Domain gesendet haben und ob SPF/DKIM bestanden. Sie sind roh schwer lesbar; ein kostenloser Report-Analyzer macht sie verständlich. Sobald du in den Berichten siehst, dass deine eigenen Mails durchgehend bestehen und keine fremden Quellen auftauchen, erhöhst du die DMARC-Policy schrittweise von p=none über p=quarantine bis p=reject.

Schritt 7: Was Gmail, Yahoo und Outlook.com konkret verlangen

Du musst nicht raten, was „gut genug" ist – die großen Anbieter haben ihre Anforderungen schriftlich festgehalten.

Google und Yahoo, verbindlich seit dem 1. Februar 2024. Für jeden Absender gilt: SPF oder DKIM eingerichtet, gültige Vorwärts- und Rückwärts-DNS-Einträge, TLS beim Transport und eine Spam-Beschwerderate unter 0,3 %. Wer 5.000 Mails oder mehr pro Tag an Gmail- bzw. Yahoo-Konten schickt, muss zusätzlich SPF und DKIM setzen, einen DMARC-Record veröffentlichen (p=none genügt), die From:-Domain mit der SPF- oder der DKIM-Domain ausrichten und bei Werbe- und Abo-Mails eine One-Click-Abmeldung per List-Unsubscribe-Header anbieten.

Microsoft, verbindlich seit dem 5. Mai 2025. Für Outlook.com, Hotmail, Live und MSN gilt dieselbe Schwelle von 5.000 Mails pro Tag: SPF und DKIM müssen bestehen, ein DMARC-Record mit mindestens p=none muss existieren, und die Ausrichtung muss über SPF und/oder DKIM passen. Nicht konforme Mails landeten zunächst im Junk-Ordner; inzwischen weist Microsoft sie direkt im SMTP-Dialog ab:

550 5.7.515 Access denied, sending domain DEINE_DOMAIN does not meet the required authentication level

Ein Detail, das gern übersehen wird: Die Schwelle ist klebrig. Hat eine Domain sie einmal überschritten, gelten die Anforderungen dauerhaft – auch wenn du später wieder deutlich weniger versendest.

Als Selbsthoster wirst du die 5.000er-Marke selten reißen. Trotzdem ist genau das die Messlatte, an der du dich orientieren solltest – und die gute Nachricht: Die Anforderungen sind exakt das, was du in den Schritten 1 bis 4 gebaut hast. Wer PTR, SPF, DKIM und DMARC sauber gesetzt hat, erfüllt die Regeln der drei größten Anbieter, ohne noch einmal nachlegen zu müssen.

Schritt 8: Die IP-Reputation aufwärmen

Perfekte DNS-Records sind die Eintrittskarte – aber große Anbieter vertrauen einer frischen Server-IP trotzdem nicht sofort. Sie beobachten dein Sendeverhalten und bauen über Tage bis Wochen ein Reputationsbild auf. Zwei Dinge helfen entscheidend:

• Klein anfangen, regelmäßig senden. Ein neuer Server, der aus dem Stand hunderte Mails verschickt, sieht aus wie eine Spam-Schleuder. Sende anfangs wenige, echte Mails und steigere langsam. Kontinuität schlägt Menge.
• Nur an existierende Adressen senden. Jede Mail an ein nicht existierendes Postfach (ein „bounce") verschlechtert deine Reputation. Halte deine Empfängerlisten sauber.

Ein Sonderfall ist Microsoft (Outlook, Hotmail, Live): Deren Filter sind bei neuen IPs besonders misstrauisch, selbst bei tadellosen Records. Die Authentifizierung aus Schritt 7 ist dort die Eintrittskarte, ersetzt aber keine Reputation. Hier hilft nur Geduld – und, falls nötig, die Anmeldung zu Microsofts Absender-Programmen (SNDS/JMRP), über die du Einblick und einen Draht zur Reputationsbewertung bekommst.

Wenn es nicht funktioniert

Wartung & Backups

Zustellbarkeit ist Dauerpflege, keine Einmalaktion:

• DMARC-Berichte beobachten. Ein regelmäßiger Blick zeigt sofort, wenn jemand deine Domain missbraucht oder ein eigener Dienst plötzlich durchfällt.
• DKIM-Schlüssel rotieren. Alle ein bis zwei Jahre einen neuen Schlüssel erzeugen (neuer Selector, alten noch eine Weile stehen lassen), um die Sicherheit hochzuhalten.
• Reputation im Blick behalten. Prüfe gelegentlich Blocklisten und das Sendevolumen. Ein plötzlicher Anstieg ausgehender Mails ist fast immer das Zeichen eines gekaperten Kontos.
• Records sichern. SPF-, DKIM- und DMARC-Records gehören in deine Doku bzw. dein Backup – gehen die DKIM-Schlüssel auf dem Server verloren, musst du ohnehin neue erzeugen und den DNS-Record ersetzen (siehe die Backup-Abschnitte der Mailserver-Tutorials).

Sind alle vier Bausteine gesetzt und getestet, hast du die halbe Miete des seriösen Mail-Selbsthostens – den Rest macht ein sauber betriebener, nicht als Spam-Schleuder missbrauchter Server.

Was bauen wir?

Am Ende läuft Stalwart 0.16.14 als einzelner Docker-Container auf deinem Server und stellt alles bereit, was ein vollwertiger Mailserver braucht:

• SMTP (Senden/Empfangen) auf den Ports 25, 465 und 587,
• IMAP (993) und das moderne JMAP für schnelle, effiziente Clients,
• ManageSieve (4190) für serverseitige Filterregeln,
• einen eingebauten Spam- und Phishing-Filter (kein separater Rspamd/ClamAV nötig),
• einen integrierten Speicher (RocksDB) – keine externe Datenbank,
• eine moderne Weboberfläche zur Verwaltung von Domains, Konten und Einstellungen.

Der große Unterschied zu Mailcow: Es ist ein Prozess, ein Container, wenige Hundert Megabyte Image. Das senkt RAM-Bedarf, Angriffsfläche und Wartungsaufwand deutlich. Getestet mit Docker 29 auf Debian 13.

Warum lohnt sich der schlanke Ansatz? Ein klassischer Mailserver-Stack besteht aus einem guten Dutzend Diensten – Postfix, Dovecot, Rspamd, ein Datenbankserver, ein Virenscanner, Redis, ein Webserver – die alle einzeln laufen, aktualisiert und aufeinander abgestimmt werden müssen. Jeder davon ist eine potenzielle Fehlerquelle und ein Stück Angriffsfläche. Stalwart bündelt dieselbe Funktionalität in einer einzigen, in Rust geschriebenen Anwendung. Rust bringt zudem Speichersicherheit von Haus aus mit – für eine Software, die ungefiltert Daten aus dem ganzen Internet entgegennimmt, ist das ein echtes Sicherheitsargument.

Voraussetzungen

• Ein eigener Server mit Debian 13 und installiertem Docker, auf dem die Mail- und Web-Ports frei sind (kein Reverse Proxy, der 25/443 belegt).
• Eine Domain, deren DNS du selbst steuerst – für den A-Record des Mailservers und den MX-Record.
• Port 25 ausgehend muss offen sein. Viele Provider sperren ihn gegen Spam; bei netcup schaltest du ihn per Support-Ticket frei. Ohne offenen Port 25 kannst du keine Mails an fremde Server zustellen.
• Ein PTR-/Reverse-DNS-Eintrag für die Server-IP (im netcup-SCP), der auf deinen Mail-Hostnamen zeigt.

Stalwart ist genügsam – für den Einstieg reicht ein kleiner Server. Wie viel dein Setup insgesamt braucht, schätzt dir der Server-Rechner.

Schritt für Schritt

Schritt 1: DNS-Records anlegen

Richte zuerst die DNS-Einträge ein – sie brauchen Zeit zum Propagieren. DEINE_DOMAIN ist deine Mail-Domain, DEINE_SERVER_IP die IPv4-Adresse des Servers:

mail.DEINE_DOMAIN.   A     DEINE_SERVER_IP
DEINE_DOMAIN.        MX    10 mail.DEINE_DOMAIN.

Der MX-Record verweist andere Mailserver an mail.DEINE_DOMAIN. Dieser Hostname ist die Identität deines Servers. SPF, DKIM und DMARC ergänzen wir im Zustellbarkeits-Tutorial – die DKIM-Schlüssel erzeugt Stalwart im Setup selbst.

Schritt 2: Die compose.yaml schreiben

Lege einen Ordner an und wechsle hinein:

mkdir -p /opt/stalwart && cd /opt/stalwart

Erstelle die Datei compose.yaml:

services:
  stalwart:
    image: stalwartlabs/stalwart:v0.16.14
    container_name: stalwart
    restart: unless-stopped
    ports:
      - "25:25"       # SMTP (Server-zu-Server)
      - "465:465"     # SMTPS (Senden, implizites TLS)
      - "587:587"     # Submission (Senden, STARTTLS)
      - "143:143"     # IMAP
      - "993:993"     # IMAPS
      - "4190:4190"   # ManageSieve
      - "8080:8080"   # Weboberfläche & JMAP (Ersteinrichtung)
      - "443:443"     # HTTPS (nach der Einrichtung, eigenes Zertifikat)
    volumes:
      - stalwart_data:/opt/stalwart
volumes:
  stalwart_data:

Das Wichtigste: ein Service, ein Volume für alle Daten. Stalwart holt sich sein TLS-Zertifikat später selbst per Let’s Encrypt – einen separaten Reverse Proxy brauchst du dafür nicht. Achte darauf, dass Port 443 auf dem Host frei ist (Stalwart nutzt ihn auch für den Zertifikatsabruf, siehe Schritt 4).

Schritt 3: Den Container starten und das Startpasswort holen

Starte Stalwart:

docker compose up -d

Beim allerersten Start läuft Stalwart im Bootstrap-Modus: Es gibt noch keine Konfiguration, und Port 8080 ist für die Ersteinrichtung offen. Dabei erzeugt es ein einmaliges Administrator-Passwort, das du aus den Logs abliest:

docker compose logs | grep -A2 "temporary administrator"

🔑 Stalwart bootstrap mode - temporary administrator account
   password: <EINMAL-PASSWORT>

Notiere dieses Passwort – es wird nur einmal angezeigt. (Wenn du lieber ein festes Passwort setzt, kannst du in der compose.yaml unter environment: ein STALWART_RECOVERY_ADMIN=admin:DEIN_PASSWORT hinterlegen.)

Schritt 4: Anmelden und den Einrichtungs-Assistenten durchlaufen

Rufe die Weboberfläche im Browser auf: http://DEINE_SERVER_IP:8080/admin. Du landest auf der Anmeldung. Melde dich als Benutzer admin mit dem Einmal-Passwort aus Schritt 3 an – die Eingabe erfolgt in zwei Schritten (erst Benutzername, dann Passwort):

Nach der Anmeldung begrüßt dich der Einrichtungs-Assistent. Im ersten Schritt legst du die Server-Identität fest:

• Server Hostname: mail.DEINE_DOMAIN – der FQDN aus deinem A-Record.
• Default Email Domain: DEINE_DOMAIN – deine Mail-Domain.
• Automatically Obtain TLS Certificate aktiviert lassen – Stalwart holt das Let’s-Encrypt-Zertifikat selbst. Dafür muss Port 443 von außen erreichbar sein: Stalwart nutzt standardmäßig die TLS-ALPN-01-Challenge über 443, Port 80 braucht es dafür nicht.
• Generate Email Signing Keys aktiviert lassen – das erzeugt gleich deine DKIM-Schlüssel.

Klick dich durch die weiteren Schritte des Assistenten:

• Speicher (Storage): Die Voreinstellung RocksDB ist ein eingebetteter Schlüssel-Wert-Speicher und für Einzelserver-Setups perfekt – kein externer Datenbankserver nötig. Nur für große, geclusterte Installationen greifst du zu PostgreSQL o. Ä.
• Verzeichnis (Directory): Das interne Verzeichnis verwaltet Konten und Passwörter direkt in Stalwart. Wer bereits ein zentrales LDAP/Active Directory betreibt, kann es hier stattdessen anbinden – für den Einstieg bleibst du beim internen Verzeichnis.
• Logging: Legt fest, wie ausführlich Stalwart protokolliert. Info ist im Alltag ein guter Kompromiss; bei Problemen drehst du kurzzeitig auf Debug.
• DNS: Für den Anfang genügt die manuelle Verwaltung – die anzulegenden Records zeigt dir Stalwart später unter der jeweiligen Domain an.

Zum Abschluss erzeugt Stalwart dein dauerhaftes Administrator-Konto und zeigt dessen Passwort ein einziges Mal an – schreib es dir sofort weg. Ab jetzt ist der Bootstrap-Modus beendet und Port 8080 nicht mehr offen für die Einrichtung; die Konsole erreichst du künftig über HTTPS.

Schritt 5: Domain und erstes Postfach anlegen

Nach dem Setup bist du in der Verwaltungskonsole. Über die linke Navigation erreichst du Directory → Domains und Directory → Accounts. Lege bei Bedarf weitere Domains an und dann dein erstes Postfach:

Über Create account (bzw. Konto anlegen) legst du ein Postfach an – E-Mail-Adresse, angezeigter Name und ein starkes Passwort (Passwortmanager!). Dieses Konto kann sich anschließend per IMAP/JMAP und SMTP anmelden:

Schritt 6: In einem Mailprogramm einrichten

Trage das neue Konto in deinem Mailprogramm ein. Stalwart unterstützt Autodiscovery, meist reicht also E-Mail-Adresse und Passwort. Manuell nutzt du:

IMAP:        mail.DEINE_DOMAIN, Port 993, SSL/TLS
SMTP:        mail.DEINE_DOMAIN, Port 587, STARTTLS
Benutzer:    die volle E-Mail-Adresse

Neben dem altbewährten IMAP spricht Stalwart auch JMAP – ein modernes, JSON-basiertes Protokoll, das für heutige Netze entworfen wurde. JMAP überträgt nur echte Änderungen statt ganze Ordner neu zu synchronisieren, kommt mit einer einzigen Verbindung aus und ist damit spürbar sparsamer mit Akku und Datenvolumen – gerade auf dem Handy. Unterstützt dein Mail-Client JMAP (z. B. die Thunderbird-Familie in neueren Versionen), profitierst du direkt davon; ansonsten bleibst du bei IMAP, das genauso funktioniert.

Eine Mail von dir an dich selbst sollte sofort im Posteingang landen – das beweist, dass lokale Zustellung, IMAP und SMTP stehen. Der Härtetest ist aber das Senden nach außen und der Empfang von außen, und da entscheidet die Zustellbarkeit.

Schritt 7: Spam-Filter und Sieve-Regeln

Ein großer Vorteil von Stalwart: Der Spam- und Phishing-Filter ist bereits eingebaut und aktiv – du musst keinen separaten Rspamd-Container betreiben und pflegen. Er bewertet eingehende Mails anhand zahlreicher Merkmale (Reputation, SPF/DKIM/DMARC-Ergebnis, Inhaltsheuristiken) und markiert oder blockiert Verdächtiges. In der Konsole unter Settings → Spam Filter kannst du die Empfindlichkeit anpassen und Absender auf Allow- oder Blocklisten setzen.

Für eigene Regeln beim Ein- und Ausgang unterstützt Stalwart Sieve – die standardisierte Filtersprache. Damit sortierst du z. B. Newsletter automatisch in einen Ordner oder leitest bestimmte Absender weiter. Sieve-Skripte verwaltest du serverseitig (über ManageSieve auf Port 4190) oder direkt in der Weboberfläche, sodass die Regeln unabhängig vom Mailprogramm greifen – auch dann, wenn dein Rechner aus ist.

Wenn es nicht funktioniert

Wartung & Backups

Updates. Stalwart ist ein einzelner Container – ein Update ist entsprechend einfach:

cd /opt/stalwart
docker compose pull && docker compose up -d

Lies vor größeren Sprüngen die Release-Notes auf GitHub; bleib bei einem konkreten Versions-Tag (wie hier v0.16.14) statt latest, damit Updates reproduzierbar bleiben.

Backups. Alle Daten – Nachrichten, Konten, Konfiguration und die DKIM-Schlüssel – liegen im Volume stalwart_data. Sichere dieses Volume regelmäßig weg vom Server, am saubersten verschlüsselt mit restic. Weil Stalwart die Daten im laufenden Betrieb schreibt, sicherst du am konsistentesten, indem du den Container kurz stoppst (docker compose stop), das Volume sicherst und wieder startest. Die DKIM-Schlüssel sind besonders wichtig: Gehen sie verloren, brechen nach einer Wiederherstellung deine Signaturen, bis du die DNS-Records neu setzt. Ein Backup, das du nie zurückgespielt hast, ist nur ein Hoffnungswert – teste die Wiederherstellung einmal auf einem Testsystem.

Reputation im Blick behalten. Prüfe gelegentlich, ob deine Server-IP auf einer Blockliste gelandet ist, und wirf einen Blick in die Stalwart-Konsole unter Observability. Ein kompromittiertes Postfach, das Spam verschickt, ruiniert die Reputation deiner ganzen Domain schnell.

Was bauen wir?

Am Ende läuft ein vollständiger Mailserver-Stack auf deinem Server, erreichbar als Webmail unter https://mail.DEINE_DOMAIN mit gültigem Let’s-Encrypt-Zertifikat. Enthalten sind:

• Postfix als SMTP-Server (Senden/Empfangen),
• Dovecot für IMAP/POP3 (Abruf durch Mail-Programme),
• Rspamd als moderner Spam- und Signaturfilter,
• SOGo als Webmail samt Kalender und Kontakten (CalDAV/CardDAV),
• eine Admin-Oberfläche zum Anlegen von Domains, Postfächern und Aliassen.

Das Ganze kommt als mailcow-dockerized – ein fertig geschnürtes Compose-Projekt aus 18 Containern, das das notorisch komplizierte Mailserver-Setup handhabbar macht. Wir setzen auf Debian 13 mit Docker 29.6 und Compose v5.3 auf; mailcow ist ein Rolling Release und wird über Monats-Tags gepflegt (du aktualisierst per update.sh, es gibt keine klassische Versionsnummer). Getestet haben wir gegen den Stand 2026-07b mit Postfix 3.10.12, Dovecot 2.3.21.1, Rspamd 4.1.4 und SOGo 5.12.10.

Voraussetzungen

• Ein eigener Server mit Debian 13, auf dem Docker installiert ist und der nur für mailcow da ist (Ports 80/443 und die Mail-Ports frei).
• Mindestens 6 GB RAM – der Spam-Filter (Rspamd) und der optionale Virenscanner (ClamAV) brauchen Luft. Mit weniger wird es zäh oder ClamAV muss aus.
• Eine Domain, deren DNS du selbst steuerst. Ohne passende Records (v. a. MX und Reverse DNS) nimmt kein anderer Mailserver deine Post an.
• Port 25 ausgehend muss offen sein. Viele Provider sperren ihn standardmäßig gegen Spam – bei netcup schaltest du ihn per Support-Ticket frei. Ohne offenen Port 25 kannst du keine Mails an andere Server zustellen.
• Ein PTR-/Reverse-DNS-Eintrag für die Server-IP, den du im Provider-Panel setzt (bei netcup im SCP). Er muss auf mail.DEINE_DOMAIN zeigen.

Mailcow ist RAM-hungrig, deshalb empfehlen wir mindestens den VPS 2000. Wie viel dein konkreter Bedarf ist, schätzt dir der Server-Rechner.

Schritt für Schritt

Schritt 1: DNS-Records anlegen

Bevor du irgendetwas installierst, richte die DNS-Einträge ein – sie brauchen Zeit zum Propagieren, und mailcow holt beim Start das TLS-Zertifikat für den Hostnamen. Lege bei deinem DNS-Anbieter (siehe Domain mit dem Server verbinden) diese Einträge an. DEINE_DOMAIN ist deine Mail-Domain (z. B. beispiel.de), DEINE_SERVER_IPV4 die IPv4-Adresse des Servers:

mail.DEINE_DOMAIN.   A      DEINE_SERVER_IPV4
mail.DEINE_DOMAIN.   AAAA   DEINE_SERVER_IPV6      (falls du IPv6 nutzt)
DEINE_DOMAIN.        MX     10 mail.DEINE_DOMAIN.

Der MX-Record sagt anderen Mailservern: „Post für @DEINE_DOMAIN nimmt mail.DEINE_DOMAIN entgegen." Der Hostname mail.DEINE_DOMAIN ist der FQDN des Mailservers – nicht zu verwechseln mit der Mail-Domain selbst. Die weiteren Records für Zustellbarkeit (SPF, DKIM, DMARC) und den PTR-Eintrag behandeln wir im Folge-Tutorial zur Zustellbarkeit ausführlich; der PTR-Eintrag sollte aber schon jetzt gesetzt sein, weil viele Server sonst gar nicht erst annehmen.

Schritt 2: Voraussetzungen auf dem Server installieren

Melde dich per SSH auf dem abgesicherten Server an. Mailcows Konfigurations-Generator braucht neben Docker auch git und jq – letzteres wird gern vergessen, und der Generator bricht sonst mit Cannot find command 'jq' ab. Installiere beides:

sudo apt update && sudo apt install -y git jq

Prüfe, dass Docker und das Compose-Plugin laufen:

docker --version && docker compose version

Du solltest zwei Versionszeilen sehen – bei uns Docker version 29.6.1 und Docker Compose version v5.3.1. Mailcow verlangt mindestens Docker 24; darunter bricht der Konfigurations-Generator ab. Fehlt etwas, hol das Docker-Setup nach, bevor du weitermachst.

Schritt 3: Mailcow klonen und konfigurieren

Mailcow wird als Git-Repository ausgeliefert und nicht über einen einzelnen Image-Tag gepflegt. Klone es nach /opt und wechsle hinein. Wichtig ist die umask 0022, damit die erzeugten Dateien die richtigen Rechte bekommen:

sudo su
umask 0022
cd /opt
git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized

Jetzt erzeugst du die zentrale Konfigurationsdatei mailcow.conf mit dem interaktiven Generator:

./generate_config.sh

Zuerst prüft er, ob die IP deines Servers auf der Spamhaus-Bad-ASN-Liste steht – ein sinnvoller Frühwarner, denn aus manchen Netzen nimmt kaum ein Mailserver Post an:

Detecting if your IP is listed on Spamhaus Bad ASN List...
Check completed! Your IP is clean

Danach stellt er dir nacheinander diese Fragen:

• Mail server hostname (FQDN): Trage hier mail.DEINE_DOMAIN ein – den Hostnamen des Servers, nicht deine Mail-Domain. Der Wert muss zum A-Record aus Schritt 1 passen.
• Timezone: Meist schon korrekt vorausgefüllt (z. B. Europe/Berlin) – mit Enter bestätigen.
• Choose the Branch with it’s number [1/2/3]: Wähle 1 für den master-Branch – das ist der stabile, empfohlene Stand. 2 ist nightly (Testing), 3 der abgekündigte legacy-Branch.

/etc/docker/daemon.json not found. Create it with IPv6 settings? [Y/n]

Wirf danach einen Blick in die erzeugte mailcow.conf. Die wichtigsten Werte stehen oben:

grep -E "^(MAILCOW_HOSTNAME|TZ|HTTP_PORT|HTTPS_PORT|SKIP_CLAMD|ENABLE_IPV6)=" mailcow.conf

Auf unserem Testserver sah das so aus – SKIP_CLAMD=n heißt „ClamAV läuft mit":

MAILCOW_HOSTNAME=mail.DEINE_DOMAIN
HTTP_PORT=80
HTTPS_PORT=443
TZ=Europe/Berlin
SKIP_CLAMD=n
ENABLE_IPV6=true

Die Datei enthält auch alle Port-Belegungen. In der Standardkonfiguration nimmt mailcow diese Host-Ports in Beschlag:

25    SMTP     (Server-zu-Server-Zustellung)
465   SMTPS    (Senden mit impliziter TLS)
587   Submission (Senden durch Mailprogramme, STARTTLS)
143   IMAP  /  993 IMAPS   (Abruf durch Mailprogramme)
110   POP3  /  995 POP3S
4190  Sieve    (serverseitige Filterregeln)
80    HTTP  /  443 HTTPS   (Webmail + Admin + ACME)

Diese Ports müssen auf dem Host frei sein – darum der eigene Server. Läuft dort schon ein Reverse Proxy auf 80/443, kollidiert mailcow damit.

Schritt 4: Firewall öffnen

Deine UFW-Firewall muss die Mail- und Web-Ports durchlassen. Neben SSH gibst du frei:

sudo ufw allow 25/tcp
sudo ufw allow 80,443/tcp
sudo ufw allow 465,587/tcp
sudo ufw allow 143,993/tcp
sudo ufw allow 110,995/tcp
sudo ufw allow 4190/tcp

Nutzt du zusätzlich die netcup-Firewall im SCP, gib dieselben Ports auch dort frei – sonst blockt die Perimeter-Firewall den Verkehr, bevor er den Server erreicht.

Schritt 5: Den Stack starten

Jetzt lädst du die Images und startest den Stack. Rechne mit rund 4,5 GB auf der Platte – der Stack besteht aus 18 Diensten, die dicksten sind SOGo, Dovecot und Postfix:

docker compose pull
docker compose up -d

Das erste Hochfahren dauert ein paar Minuten – Datenbank, Suchindex und die einzelnen Dienste initialisieren sich. Beobachte den Fortschritt mit:

docker compose ps

In der Spalte STATUS steht bei jedem Dienst Up …; die Container mit eigenem Healthcheck (etwa unbound-mailcow und clamd-mailcow) melden zusätzlich (healthy). Mailcow holt in dieser Zeit im Hintergrund über seinen eingebauten ACME-Client das Let’s-Encrypt-Zertifikat für mail.DEINE_DOMAIN. Dafür müssen der A-Record und Port 80 von außen erreichbar sein – ist das nicht der Fall, bleibt der acme-mailcow-Container in einer Wiederhol-Schleife und du siehst das in seinen Logs (docker compose logs acme-mailcow).

Schritt 6: Erste Anmeldung an der Admin-Oberfläche

Rufe https://mail.DEINE_DOMAIN im Browser auf. Du landest in der mailcow-UI. Melde dich mit den Standard-Zugangsdaten an:

Benutzer:  admin
Passwort:  moohoo

Zeigt die Maske „Anmeldung als Benutzer", klick unten auf „Als Admin anmelden" – das Login-Formular auf der Startseite meldet dich sonst als Postfach-Nutzer an, nicht als Administrator.

Nach dem Login landest du im mailcow-Dashboard mit dem Überblick über deine Dienste:

Schritt 7: Mail-Domain und erstes Postfach anlegen

In mailcow trennst du Domain (z. B. beispiel.de) und Postfach (z. B. kontakt@beispiel.de).

Über E-Mail → Konfiguration in der oberen Navigationsleiste verwaltest du Domains und Postfächer in getrennten Reitern:

1. Klick auf dem Reiter Domains auf Domain hinzufügen und trage deine Domain DEINE_DOMAIN ein. Die Standardwerte (Postfach- und Alias-Kontingente) sind für den Anfang in Ordnung. Speichere unten mit „Domain hinzufügen und SOGo neustarten" – nicht mit „Nur Domain hinzufügen". Warum, steht gleich im Kasten darunter.

   

2. Wechsle auf den Reiter Mailboxen und klick auf Mailbox hinzufügen – Benutzername, Domain, voller Name und ein starkes Passwort (Passwortmanager!). Dieses Postfach kann sich anschließend an der Webmail und per IMAP/SMTP anmelden.

   

Nach dem Anlegen der Domain zeigt dir mailcow unter dem Domain-Eintrag den DKIM-Schlüssel und die empfohlenen DNS-Records an. Die brauchst du für die Zustellbarkeit – dazu gleich mehr.

Schritt 8: Webmail testen

Öffne https://mail.DEINE_DOMAIN/SOGo/ (oder klick in der mailcow-UI oben rechts auf Apps → Webmail). Bist du noch nicht angemeldet, landest du zuerst auf der mailcow-Anmeldemaske „Anmeldung als Benutzer" – dort meldest du dich mit der vollen Mail-Adresse und dem Postfach-Passwort an und wirst direkt in den SOGo-Webmailer mit Posteingang, Kalender und Kontakten durchgereicht. Eine Test-Mail von dir an dich selbst sollte sofort im Posteingang liegen – das beweist, dass lokale Zustellung, IMAP und Webmail funktionieren.

Der eigentliche Härtetest ist aber das Senden nach außen und das Empfangen von außen – und genau da entscheidet sich, ob deine Mails im Postfach oder im Spam-Ordner des Empfängers landen. Das hängt an SPF, DKIM, DMARC und dem PTR-Eintrag und ist eigenständig genug für ein eigenes Rezept.

Wenn es nicht funktioniert

Wartung & Backups

Ein Mailserver lebt von Pflege – plane sie fest ein.

Updates. Mailcow bringt ein eigenes Update-Skript mit. Führe es regelmäßig (etwa monatlich) aus; es aktualisiert die Compose-Datei und alle Images auf den neuesten Stand:

cd /opt/mailcow-dockerized
sudo ./update.sh

Das Skript legt vor dem Update automatisch eine Sicherung der Konfiguration an und startet den Stack neu. Lies die angezeigten Release-Hinweise – bei größeren Sprüngen stehen dort gelegentlich manuelle Schritte.

Backups. Deine Mails, die Datenbank und die Krypto-Schlüssel (DKIM!) liegen in Docker-Volumes. Mailcow bringt dafür ein fertiges Backup-Skript mit:

cd /opt/mailcow-dockerized/helper-scripts
sudo BACKUP_LOCATION=/opt/mailcow-backups ./backup_and_restore.sh backup all

Sichere das Zielverzeichnis anschließend weg vom Server – am saubersten verschlüsselt mit restic. Besonders wichtig sind die DKIM-Schlüssel: Gehen sie verloren, brechen nach einer Wiederherstellung deine Signaturen, bis du die DNS-Records neu setzt. Ein Backup, das du nie zurückgespielt hast, ist nur ein Hoffnungswert – teste die Wiederherstellung einmal auf einem Testsystem.

Reputation im Blick behalten. Prüfe gelegentlich, ob deine Server-IP auf einer Blockliste gelandet ist (z. B. über einen der gängigen Blocklist-Checker) und wirf ab und zu einen Blick in das Rspamd-Dashboard der mailcow-UI. Ein gehacktes oder falsch konfiguriertes Postfach, das Spam verschickt, ruiniert die Reputation deiner ganzen Domain schnell.