mailcow Toolkit – Anleitung

Bevor du beginnst

mailcow-dockerized unter Linux (getestet mit 2026-09 und 2026-09a), installiert zum Beispiel in /opt/mailcow-dockerized.
Root-Zugang auf dem Host und diese Befehle: docker mit docker compose, git, jq, flock, curl, tar, sha256sum und systemd.
Ausgehendes HTTPS zu medialab.works vom Server aus (Lizenzprüfung, Test, Toolkit-Updates).
Dein Lizenzschlüssel aus deinem medialab.works-Konto oder eine E-Mail-Adresse für den kostenlosen 30-tägigen Test.
Ein zweiter Hostname für Webmail (zum Beispiel webmail.example.com) im DNS und ein Reverse Proxy, der ihn ausliefern kann.
Ein Ordner für Backups, zum Beispiel /srv/backup/mailcow.
Optional, für DNS & Cloudflare: ein Cloudflare-Konto, in dem die Zonen deiner Domains liegen. Um die öffentlichen Adressen des Servers zu finden, fragt das Toolkit ip4.mailcow.email und ip6.mailcow.email ab (wie mailcows eigene DNS-Prüfung).

Installation

Lade mailcow-toolkit-<version>.tar.gz aus deinem medialab.works-Konto herunter, packe es auf dem mailcow-Host aus und führe es als root aus:

sudo ./install.sh --mailcow-dir /opt/mailcow-dockerized \
  --webmail-url https://webmail.example.com --backup-dir /srv/backup/mailcow

--mailcow-dir — wo mailcow-dockerized installiert ist (Standard /opt/mailcow-dockerized).
--webmail-url — die Webmail-Adresse, https:// + Hostname (ein optionaler Port ist erlaubt). Ohne sie behält die SOGo-Schaltfläche das Standardverhalten von mailcow.
--backup-dir — wohin die Backups vor Updates geschrieben werden. Ohne ihn läuft Update now ohne vorheriges Backup (der Installer warnt dich).
--name — nur, wenn du mehrere mailcow-Installationen auf demselben Host hast: ein Name pro Installation (Buchstaben, Ziffern und -).

Der Installer legt die Web-Dateien in mailcows data/web ab (von mailcows Git ausgeschlossen), den gemeinsamen Ordner in data/hooks/phpfpm/.mlw-toolkit, den Host-Agent in /usr/local/sbin/mlw-mailcow-agent-<name>, die Einstellungen in /etc/mlw-mailcow-toolkit/<name>.conf, eine Kopie der installierten Version in /var/lib/mlw-mailcow-toolkit/<name>/package und aktiviert fünf systemd-Units: eine, die die Anfragen aus der Admin-Oberfläche ausführt, einen Timer, der beim Serverstart und einmal täglich die Lizenz prüft und nach einer neuen mailcow-Version sucht, mlw-mailcow-rdns-<name>.timer, der alle 6 Stunden das Reverse DNS prüft, und mlw-mailcow-domains-<name>.timer, der alle 2 Minuten nach neuen mailcow-Domains sucht (er tut nichts, solange sowohl die automatische Cloudflare-Einrichtung als auch der neue Domain-Assistent aus sind), und, ab 0.4.0, mlw-mailcow-accounts-<name>.timer, der alle 5 Minuten die Aufgaben von Sign-up for mailcow und Cashier for mailcow ausführt. Ab 0.4.0 installiert das Paket außerdem Sign-up und Cashier (ihre Tabellen mlw_su_* und mlw_ca_* in mailcows Datenbank); sie bleiben ausgeschaltet, bis jedes seine eigene Lizenz hat. Zum Schluss lädt es php-fpm neu und prüft die Lizenz; bis die Lizenz aktiv ist, weist es dich an, den Abschnitt License zu öffnen.

Das Toolkit aktualisieren: über den Abschnitt License (siehe unten) oder indem du install.sh erneut aus der neuen Version ausführst. Deine frühere Webmail-Adresse und dein Backup-Ordner bleiben erhalten, wenn du sie weglässt. Die Aktualisierung auf 0.3.0 über den Abschnitt License aktiviert außerdem die beiden neuen Timer; die Seite DNS & Cloudflare erscheint dann im Menü System.

Lizenz und kostenloser Test

Öffne System > Updates (Toolkit) (nur Administratoren). Der Abschnitt License oben zeigt den Status der Lizenz und funktioniert auch ohne eine:

Enter your license key und drücke Activate. Der Schlüssel befindet sich in deinem medialab.works-Konto.
Oder starte den kostenlosen 30-tägigen Test: Gib deine E-Mail-Adresse ein, wähle, ob es danach monatlich oder jährlich weitergehen soll, und drücke Start the free trial. Öffne die Stripe-Bezahlseite über den angezeigten Link: Dort wird die Karte abgefragt und in den 30 Tagen nicht belastet. Wenn die Adresse bereits ein medialab.works-Konto hat, wird der Link stattdessen dorthin per E-Mail geschickt. Die Seite aktiviert das Toolkit dann von selbst, sobald der Test beginnt. Der Test kann einmal pro Server und pro E-Mail-Adresse genutzt werden.
Ab 0.4.0 zeigt die Seite je Produkt eine License-Karte (License · mailcow Toolkit, License · Sign-up for mailcow, License · Cashier for mailcow), jede mit eigenem Schlüssel und eigenem Test. Ein Schlüssel des mailcow-Pakets wird in jeder Karte eingetragen. Updates des Pakets können von der Karte eines beliebigen Produkts mit gültiger Lizenz aus gestartet werden. Siehe die Anleitung zu Sign-up und die Anleitung zu Cashier.
Mit aktiver Lizenz zeigt der Abschnitt den Schlüssel (teilweise verdeckt), den Typ, das Enddatum, die letzte Prüfung, bis wann das Toolkit ohne Verbindung weiterarbeitet, und die ID dieses Servers. Check now prüft sofort (zusammen mit Updates und Rollbacks höchstens zweimal pro Stunde).
Remove from this server (nachdem du die Bestätigung angehakt hast) gibt die Lizenz frei, sodass du sie auf einem anderen mailcow-Server nutzen kannst; das Toolkit stoppt hier.

Die Lizenz wird beim Serverstart und einmal täglich geprüft. Wenn medialab.works nicht erreichbar ist, arbeitet das Toolkit noch 7 Tage nach der letzten erfolgreichen Prüfung weiter.

Ohne gültige Lizenz (noch keine, abgelaufen, entfernt, auf einen anderen Server übertragen oder seit mehr als 7 Tagen nicht geprüft) stoppen die Funktionen des Toolkits: Die SOGo-Schaltfläche behält das Standardverhalten von mailcow, die mailcow-Update-Prüfung, E-Mails und Updates laufen nicht, die DNS-Prüfungen, der Reverse-DNS-Indikator, Cloudflare und der neue Domain-Assistent stoppen, und die Seite zeigt nur noch den Abschnitt License. Es wird nichts gelöscht.

Das Toolkit aktualisieren oder zurücksetzen

Mit gültiger Lizenz zeigt der Abschnitt License die installierte und die neueste veröffentlichte Version:

Update the Toolkit to x.y.z lädt das signierte Archiv von medialab.works herunter, prüft seine Größe und SHA-256 und reiht es für den Host-Agent ein, der es erneut prüft, das install.sh dieser Version ausführt und die vorherige Version behält: Schlägt die Installation fehl, wird die vorherige Version wieder installiert. Die Seite zeigt den Fortschritt und lädt sich nach Abschluss neu.
Roll back to x.y.z macht dasselbe mit der vorherigen Version, die deine Lizenz erlaubt.

Wenn deine Lizenz die installierte Version nicht abdeckt (zum Beispiel eine Lifetime-Lizenz, deren Update-Zeitraum vor dieser Version endete), stoppt das Toolkit, und der Abschnitt License bietet Roll back to auf die letzte Version, die deine Lizenz erlaubt, sowie den Link zum Verlängern des Update-Passes.

Der Webmail-Hostname

SOGo als Postfach funktioniert nur unter einem anderen Hostnamen als dem der mailcow-Oberfläche, weil der Browser pro Hostnamen ein Sitzungs-Cookie speichert.

Lass den Webmail-Hostnamen (zum Beispiel webmail.example.com) im DNS auf deinen Server zeigen.
Liefere ihn in deinem Reverse Proxy genau wie die mailcow-Oberfläche aus: dasselbe Backend, dieselben Header. Es ist dasselbe mailcow, nur unter einem anderen Namen.
Gib ihm ein TLS-Zertifikat, wie der Oberfläche.

SOGo als Postfach aktivieren

Setze in mailcow.conf ALLOW_ADMIN_EMAIL_LOGIN=y und wende es aus dem mailcow-Ordner mit docker compose up -d an.
Stelle sicher, dass der Administrator die Berechtigung Login as mailbox user hat.

Dann öffnet in E-Mail > Configuration, Registerkarte Mailboxes, die Schaltfläche SOGo neben einem Postfach einen neuen Tab auf dem Webmail-Host, in SOGo als dieses Postfach angemeldet. Dein Admin-Tab bleibt angemeldet. Der Link hinter der Schaltfläche funktioniert einmal und nur 60 Sekunden lang; wenn ein Tab This link has expired zeigt, klicke in der Postfachliste erneut auf SOGo.

Die Schaltfläche ist nur für den Plattform-Administrator: Domain-Administratoren behalten mailcows eigene SOGo-Schaltfläche. Inaktive Postfächer werden abgelehnt.

Was protokolliert wird: Jede Nutzung erscheint im Anmeldeprotokoll dieses Postfachs in mailcow als SSO-Anmeldung und im Audit-Log des Toolkits (wer welches Postfach wann und von welcher Adresse geöffnet hat).

mailcow aktualisieren

Mit gültiger Lizenz zeigt System > Updates (Toolkit) unter dem Abschnitt License:

die installierte Version und die letzte Prüfung (Up to date oder Update available, mit den neuen Änderungen);
den letzten Lauf (läuft, fertig oder fehlgeschlagen) mit seiner Meldung;
das Protokoll des letzten Updates.

Check now sucht sofort nach einer neuen Version; sonst prüft der Server einmal täglich.

Update now ist verfügbar, wenn die letzte Prüfung eine neue Version gefunden hat. Nach deiner Bestätigung läuft es in dieser Reihenfolge:

ein Backup von crypt, redis, rspamd, postfix und mysql in deinen Backup-Ordner, mit mailcows eigenem Backup-Skript; Backups, die älter als 14 Tage sind, werden entfernt. Schlägt das Backup fehl, stoppt das Update und nichts wird geändert;
mailcows update.sh;
ein Warten von bis zu 5 Minuten, bis jeder Container läuft und die Oberfläche antwortet.

Während des Updates starten die Container neu; E-Mail und Oberfläche sind für ein paar Minuten nicht erreichbar. Die Seite zeigt das Protokoll weiter an und lädt sich neu, sobald der Server zurück ist. Wenn das Update fertig ist, wird eine E-Mail an die Benachrichtigungsadresse geschickt.

Benachrichtigungen

Auf derselben Seite trägst du unter Notifications die Adresse ein, die die E-Mails empfangen soll, und speicherst. Der Server schickt dann eine E-Mail pro neuer mailcow-Version (nicht täglich eine) und eine, wenn ein Update fertig ist. Eine leere Adresse schaltet die E-Mails aus.

DNS & Cloudflare

Öffne System > DNS & Cloudflare (nur Administratoren). Ohne gültige Lizenz zeigt die Seite nur einen Hinweis, und im Hintergrund läuft nichts.

Domain-Status

Oben stehen eine Zusammenfassungszeile (wie viele Domains critical sind oder Warnungen haben) und eine Auswahl Domain mit jeder mailcow-Domain und Alias-Domain, die schlimmste zuerst, jede mit ihrem Status. Die Seite merkt sich die zuletzt gewählte Domain.

critical — E-Mails können nicht zugestellt oder gesendet werden oder landen im Spam: der A- (oder AAAA-)Eintrag des Mail-Hosts, MX, SPF, DKIM oder DMARC fehlt, ist falsch oder proxied; kein DKIM-Schlüssel in mailcow; ein falsches Reverse DNS des Servers; oder die Domain ist SOGo noch nicht bekannt (siehe SOGo und neue Domains unten).
warning — optionale Einträge fehlen: autodiscover, autoconfig, SRV, CalDAV / CardDAV, MTA-STS, TLS-RPT.
all good — alles, was die Domain braucht, ist vorhanden.

Die Ansicht einer Domain listet What needs attention, zuerst critical, mit dem Warum und How to fix it, dann die Zonendatei, die Cloudflare-Aktionen der Domain, den Assistenten und die vollständige Eintragstabelle. Die Status werden im Hintergrund alle 10 Minuten aktualisiert; Re-check now prüft die gewählte Domain sofort. Die Einstellungen für alle Domains (Reverse DNS, Cloudflare-Zugangsdaten und -Automatisierung, Dienst-Ports, der Assistent, SOGo) stehen unten in aufklappbaren Abschnitten.

Die Einträge jeder Domain

Die Eintragstabelle der gewählten Domain zeigt, was mailcow für sie braucht, anhand von mailcows eigener DNS-Prüfung:

required: der A-Eintrag von MAILCOW_HOSTNAME, für die Domain, deren Zone den Hostnamen enthält (in Cloudflare DNS-only, weil SMTP und IMAP den Proxy von Cloudflare nicht durchlaufen können); MX 10 → MAILCOW_HOSTNAME; SPF; DKIM mit mailcows Selektor und Schlüssel; DMARC;
recommended: die CNAMEs autodiscover und autoconfig → MAILCOW_HOSTNAME (DNS-only; stattdessen wird auch ein A-Eintrag mit der IP des Servers akzeptiert); die SRV-Einträge _autodiscover, _imaps, _submissions, _submission, _pop3s (wenn POP3 erlaubt ist), _caldavs und _carddavs mit einem path=/SOGo/dav/-TXT (wenn SOGo läuft); wenn MTA-STS für die Domain in mailcow aktiv ist, der mta-sts-CNAME, der _mta-sts-TXT und der TLS-RPT-Eintrag _smtp._tls;
für eine Alias-Domain: MX, SPF, DKIM (die Zeile bleibt unknown, bis mailcow einen Schlüssel für sie hat), DMARC und, mit MTA-STS, die TXT-Einträge _mta-sts und _smtp._tls.

Der vorgeschlagene SPF ist v=spf1 ip4:<IPv4> -all. Wenn bereits ein SPF existiert, das den Server nicht abdeckt, ergänzt der Vorschlag die Adresse des Servers und behält den Rest bei; wenn er auf include oder redirect setzt, sagt dir die Seite, dass du ihn prüfen sollst.

DMARC: Ein vorhandener gültiger DMARC-Eintrag bleibt, wie er ist. Sonst lautet der Vorschlag v=DMARC1; p=quarantine;, mit rua=mailto:dmarc@<domain> (oder postmaster@<domain>), nur wenn diese Adresse in mailcow existiert. Die TLS-RPT-Berichte gehen an tls-rpt@ oder postmaster@ der Domain.

Jede Zeile wird mit drei Quellen verglichen: öffentlicher DNS, einer importierten Zone (falls du eine hochgeladen hast) und der Cloudflare-Zone (mit Zugangsdaten). Der Status ist OK, missing, different, proxied — must be DNS-only, fix by hand (zum Beispiel A-Einträge, wo der CNAME stehen sollte, oder mehrere SPF-Einträge) oder unknown (noch kein DKIM-Schlüssel in mailcow, oder die öffentliche IPv4 noch nicht bekannt).

Zonendatei: Export und Import

Download BIND zone file speichert die Einträge der Domain als Zonendatei. Importiere sie in Cloudflare unter DNS > Records > Import and Export > Import DNS records: Die Einträge, die DNS-only bleiben müssen, tragen cf_tags=cf-proxied:false. Zeilen, die noch unknown sind, werden weggelassen.
Compare with a zone file liest einen Cloudflare-Export (DNS > Records > Import and Export > Export) oder eine beliebige BIND-Zonendatei, bis zu 1 MB, und fügt dem Vergleich eine Spalte Imported zone hinzu. Forget the imported file entfernt sie.

IPv4 und IPv6

Standardmäßig arbeitet das Toolkit nur mit IPv4: kein AAAA-Eintrag, im SPF nur ip4:, und das IPv6-Reverse-DNS wird nicht geprüft. Ein Server, der AAAA veröffentlicht, ohne einen passenden IPv6-PTR zu haben, bekommt seine E-Mails über IPv6 von Gmail und anderen abgelehnt. Wenn der IPv6-PTR des Servers gesetzt ist, schalte Use IPv6 (publish AAAA, SPF ip6, check the IPv6 rDNS) ein und speichere.

Dienst-Ports

Die Karte Service ports (SRV records) setzt die Ports, die die SRV-Einträge ankündigen: IMAPS (993), Submission (STARTTLS, 587), SMTPS (465), POP3S (995) und HTTPS (443, für autodiscover, CalDAV und CardDAV). Jedes Feld ist optional (1–65535). Wenn es leer bleibt, kommt der Port aus mailcow.conf, wenn dort eine einfache Zahl steht, oder es ist der Standardport, wenn mailcow.conf eine Adresse wie 127.0.0.1:12587 bindet (ein Proxy oder NAT ist davor); ein leeres HTTPS-Feld verwendet den Port der Admin-Seite. Unter jedem Feld zeigt die Seite den verwendeten Port und woher er kommt. Der Export, der Vergleich und Cloudflare (manuell und automatisch) verwenden alle diese Ports.

Cloudflare-Zugangsdaten

Die Cloudflare-Aktionen einer Domain (die Live-Spalte, Vorschau und Anwenden, Provision now) erscheinen nur, wenn die gespeicherten Zugangsdaten jetzt funktionieren und DNS in der Zone dieser Domain ändern dürfen; sonst sagt die Seite, warum (keine Zugangsdaten, Verbindung abgelehnt, die Zone nicht im Konto oder nicht in den Zone-Ressourcen des Tokens oder Zone > DNS > Edit fehlt). Run wizard funktioniert ohne Cloudflare.

In der Karte Cloudflare wählst du eines von:

API token (empfohlen): In Cloudflare unter My Profile > API Tokens > Create Token, mit Zone > DNS > Edit und Zone > Zone > Read auf allen Zonen. Füge Zone > Zone > Edit nur hinzu, wenn das Toolkit fehlende Zonen anlegen darf. Wenn so ein Token abhandenkommt, kann er DNS-Einträge ändern und nichts sonst, und er kann einzeln widerrufen werden.
Global API Key mit der Konto-E-Mail: Er funktioniert auch, aber er kann alles im gesamten Cloudflare-Konto (Abrechnung, Mitglieder, jedes Produkt). Verwende ihn nur, wenn du dieses Risiko akzeptierst.

Check and save prüft die Zugangsdaten zuerst bei Cloudflare. Sie werden verschlüsselt (AES-256-GCM) im Ordner des Toolkits auf deinem Server gespeichert; der Schlüssel liegt in mailcows redis, nicht neben der Datei, sodass eine Kopie des Ordners oder von mailcows Backups sie nicht offenlegt. Sie werden nie wieder angezeigt: Die Seite zeigt nur den Typ und die letzten 4 Zeichen. Remove the credentials löscht sie und schaltet die automatische Einrichtung aus. Die Zugangsdaten bleiben auf deinem Server und werden nur an die API von Cloudflare geschickt.

Einträge auf Cloudflare anwenden

Wähle die Domain. Die erforderlichen Einträge und die als proxied angezeigten sind angehakt; hak die anderen an oder ab.
Preview changes for Cloudflare listet auf, was erstellt oder aktualisiert würde, mit dem Wert jetzt und danach.
Apply to Cloudflare speichert zuerst ein JSON-Backup der gesamten Zone und erstellt oder aktualisiert dann nur diese Einträge. Es wird nichts gelöscht. Wenn sich die Zone seit der Vorschau geändert hat, wird nichts angewendet und du machst eine neue Vorschau; eine Vorschau läuft nach 15 Minuten ab.

Jedes Backup wird unter Cloudflare backups aufgelistet: Download speichert das JSON, Undo these changes macht diese Änderung rückgängig (aktualisierte Einträge bekommen ihre alten Werte zurück; erstellte Einträge werden gelöscht, nur wenn sie seitdem nicht geändert wurden). Jede Anwendung und jedes Zurücknehmen wird im Audit-Log des Toolkits geschrieben.

Automatische Einrichtung neuer Domains

Mit gespeicherten Zugangsdaten schaltest du Configure new mailcow domains in Cloudflare by themselves ein. Dann schreibt das Toolkit innerhalb von etwa 2 Minuten, nachdem eine Domain oder Alias-Domain in mailcow hinzugefügt wurde (aus der Oberfläche oder der API), ihre Einträge in die vorhandene Cloudflare-Zone:

Es wartet bis zu 10 Minuten auf mailcows DKIM-Schlüssel; ohne ihn setzt es die anderen Einträge und ergänzt DKIM später (es versucht es jede Stunde erneut);
fehlende Einträge werden erstellt und falsche aktualisiert; der A-Eintrag des Mail-Hosts und die CNAMEs werden DNS-only gesetzt;
Einträge, die es nicht verwaltet, werden niemals gelöscht; eine vorhandene abweichende SPF-, DMARC- oder TLS-RPT-Richtlinie bleibt left as it is (existing policy) und wird gemeldet (die manuelle Vorschau kann sie trotzdem aktualisieren);
vor jeder Änderung wird ein Backup der Zone gespeichert, wie beim manuellen Anwenden;
wenn die Zone nicht in Cloudflare ist, zeigt die Domain zone missing. Mit Create the zone in Cloudflare if it does not exist (braucht Zone > Zone > Edit oder den Global API Key) erstellt das Toolkit sie und zeigt die Cloudflare nameservers, die du bei deinem Registrar setzt. Wenn die Zugangsdaten mehrere Cloudflare-Konten sehen, wählt Cloudflare account for new zones das Konto (standardmäßig das erste);
mit E-mail the notification address when provisioning fails wird ein Fehler an die Adresse unter Notifications auf der Seite Updates (Toolkit) geschickt; das Toolkit versucht es nach 15 Minuten erneut.

Domains, die beim Einschalten bereits existieren, bleiben unberührt: Verwende Provision now neben einer Domain, um sie auf dieselbe Weise einzurichten.

Neuer Domain-Assistent

Die Karte New domain wizard: role addresses erstellt für jede neue mailcow-Domain die Rollen-Adressen als mailcow-Aliase, sodass sie nicht gegen das Postfach-Limit der Domain zählen:

die Adressen: postmaster, abuse, hostmaster, webmaster, contact, info, office, dmarc, tls-rpt, noreply, security, jede optional, plus eigene lokale Teile (kommagetrennt);
Destination (all role addresses): wohin sie zustellen; jede Domain kann in ihrer Ansicht ein eigenes Ziel haben (leer = das globale);
dmarc@ und tls-rpt@ können an eine separate reports-Adresse gehen;
noreply@ nutzt mailcows „discard silently“ (null@localhost): E-Mails dorthin werden angenommen und verworfen.

Schalte Create the role addresses for new domains by themselves ein (dazu braucht es ein Ziel). Der Assistent läuft vor der Cloudflare-Einrichtung, sodass die DMARC- und TLS-RPT-Einträge einer neuen Domain ihre Berichte an ihre dmarc@- und tls-rpt@-Adresse schicken. Eine Adresse, die bereits als Postfach oder Alias existiert, wird niemals angefasst: Sie wird übersprungen und gemeldet. Alias-Domains werden übersprungen, weil mailcow sie bereits auf die Adressen der Ziel-Domain abbildet. Die Aliase werden über mailcows eigene Funktionen angelegt und erscheinen daher in mailcows Protokoll. Domains, die beim Einschalten des Assistenten bereits existierten, bleiben unberührt: Verwende Run wizard neben einer Domain.

SOGo und neue Domains

SOGo liest mailcows Domains beim Start. Eine später hinzugefügte Domain ist SOGo unbekannt; ihre Postfächer bekommen daher in SOGo und in der SOGo-Schaltfläche des Toolkits „Unauthorized“, bis SOGo neu startet (die fehlgeschlagene Abfrage wird außerdem in memcached gehalten).

Mit gültiger Lizenz prüft das Toolkit alle 2 Minuten, ob SOGo jede mailcow-Domain kennt. Wenn eine fehlt, startet es nur den SOGo-Container neu und leert memcached, etwa 3 Minuten nach der ersten fehlenden Domain (damit mehrere neue Domains einen Neustart teilen) und höchstens einmal alle 10 Minuten: in der Praxis innerhalb von etwa 3 bis 10 Minuten nach dem Hinzufügen der Domain. Webmail-Sitzungen sind für wenige Sekunden unterbrochen. Jeder Neustart wird ins Audit-Log geschrieben.

Während eine Domain wartet, zeigt die DNS-Seite eine Warnung mit einer Schaltfläche Restart SOGo (dieselbe Schaltfläche steht im Abschnitt SOGo, mit dem letzten Neustart). Wenn du mailcows eigene Option Restart SOGo beim Hinzufügen der Domain ankreuzt, kennt SOGo sie sofort, und ein zweiter Neustart entfällt.

Reverse DNS (PTR)

Andere Mailserver prüfen, dass jede öffentliche IP deines Servers einen PTR-Eintrag gleich MAILCOW_HOSTNAME hat und dass MAILCOW_HOSTNAME zurück auf dieselbe IP auflöst (Forward-Confirmed Reverse DNS). Das Toolkit prüft das alle 6 Stunden für jede öffentliche IPv4 (und IPv6, mit Use IPv6); Check now auf der DNS-Seite führt die Prüfung sofort aus.

Schlägt die Prüfung fehl, erscheint ein rotes ! neben dem Menü System auf jeder Admin-Seite und eine Zeile Reverse DNS (PTR) unter System > Information. Ohne Use IPv6 löst eine IPv6-Adresse es nie aus.

So behebst du es: Der PTR-Eintrag einer IP gehört dem, wem die IP gehört, nicht deiner DNS-Zone. Setze ihn im Kontrollpanel deines Hosting- oder VPS-Anbieters (oft „Reverse DNS“ oder „PTR“ neben der IP) – oder frag deinen ISP –, exakt auf MAILCOW_HOSTNAME. Stelle dann sicher, dass MAILCOW_HOSTNAME einen A-Eintrag mit derselben IP hat (in Cloudflare DNS-only).

Der Server findet seine öffentlichen Adressen über ip4.mailcow.email / ip6.mailcow.email, sonst über seine Netzwerkschnittstellen. Hinter NAT oder bei mehreren Adressen listest du sie in RDNS_IPS auf (siehe Einstellungen).

Einstellungen

/etc/mlw-mailcow-toolkit/<name>.conf (der Standardname ist default) enthält:

BACKUP_DIR — der Backup-Ordner (leer = kein Backup vor dem Update, nicht empfohlen);
BACKUP_COMPONENTS — was gesichert wird, standardmäßig crypt redis rspamd postfix mysql;
BACKUP_KEEP_DAYS — wie lange Backups aufbewahrt werden, standardmäßig 14;
RDNS_IPS — die öffentlichen IPs, deren Reverse DNS geprüft wird, durch Leerzeichen getrennt, zum Beispiel RDNS_IPS="203.0.113.10" (leer = die erkannten Adressen);
SOGO_DELAY und SOGO_MIN_GAP — die Wartezeit vor einem SOGo-Neustart für eine neue Domain und die Mindestdauer zwischen zwei Neustarts, in Sekunden (standardmäßig 180 und 600).

Deine Änderungen an dieser Datei bleiben erhalten, wenn du erneut installierst oder das Toolkit aus dem Abschnitt License aktualisierst; es ändert sich nur BACKUP_DIR, und nur, wenn du --backup-dir angibst. Die Einstellungen für DNS & Cloudflare werden von der Seite aus gespeichert, nicht in dieser Datei, und bleiben ebenfalls erhalten.

Das Toolkit entfernen

sudo ./uninstall.sh --mailcow-dir /opt/mailcow-dockerized

Er stoppt und entfernt die systemd-Units (einschließlich der Timer), die Einstellungen, den Agent, die aufbewahrte Kopie des Toolkits und die Web-Dateien und bereinigt mailcows Git-Ausschlussliste. Der gemeinsame Ordner wird ebenfalls entfernt, mit den verschlüsselten Cloudflare-Zugangsdaten und den Cloudflare-Zone-Backups: Lade die Backups, die du behalten willst, vorher herunter. Deine DNS-Einträge in Cloudflare bleiben, wie sie sind. Die mailcow-Backups bleiben erhalten. Die Tabellen von Sign-up und Cashier bleiben in mailcows Datenbank, und die von ihnen angelegten Postfächer, Domains und Domain-Administratoren bleiben in mailcow. Füge --name hinzu, wenn du mit einem Namen installiert hast. Drücke zuerst Remove from this server im Abschnitt License, wenn du die Lizenz auf einem anderen Server nutzen willst.

Häufige Probleme

Die SOGo-Schaltfläche wechselt immer noch meine Admin-Sitzung. Bei der Installation wurde keine Webmail-Adresse angegeben, die Webmail-Adresse hat denselben Hostnamen wie die Oberfläche, oder die SOGo-Anmeldung als Postfach ist nicht erlaubt (ALLOW_ADMIN_EMAIL_LOGIN=y und die Berechtigung Login as mailbox user). Führe install.sh erneut mit --webmail-url aus und prüfe die beiden Einstellungen.

Die Updates-Seite sagt, der Host-Agent sei nicht installiert oder läuft nicht. Führe install.sh erneut aus; prüfe systemctl status mlw-mailcow-agent-default.path.

Die Seite zeigt nur den Abschnitt License. Die Lizenz ist nicht gültig: Die Meldung oben sagt, warum (noch kein Schlüssel, abgelaufen, entfernt oder übertragen, oder seit mehr als 7 Tagen nicht geprüft). Prüfe im letzten Fall, ob der Server https://medialab.works erreicht, und drücke dann Check now.

Das Update ist fehlgeschlagen. Die Seite zeigt, an welchem Schritt (Backup, update.sh oder der Container-Prüfung), und behält das Protokoll. Nach einem fehlgeschlagenen Backup wurde nichts geändert. Nach einem fehlgeschlagenen update.sh oder einer fehlgeschlagenen Container-Prüfung lies das Protokoll und behebe die Ursache, wie du es nach einem von Hand ausgeführten update.sh tun würdest.

Es gibt ein rotes ! neben dem Menü System. Die Reverse-DNS-Prüfung ist fehlgeschlagen: Öffne System > DNS & Cloudflare, Abschnitt Reverse DNS (PTR) of the server, um zu sehen, welche IP und warum. Setze den PTR bei deinem Hosting- / VPS-Anbieter oder ISP und drücke dann Check now.

Cloudflare hat die Zugangsdaten abgelehnt. Prüfe die Berechtigungen des Tokens (Zone > DNS > Edit und Zone > Zone > Read auf allen Zonen) oder beim Global API Key die Konto-E-Mail. Die Meldung von Cloudflare wird auf der Seite angezeigt.

Eine Domain zeigt „zone missing“. Die Domain ist keine Zone in dem Cloudflare-Konto, das die Zugangsdaten sehen. Füge sie in Cloudflare hinzu oder schalte Create the zone in Cloudflare if it does not exist ein; das Toolkit versucht es jede Stunde erneut, oder drücke Provision now.

Der SPF- oder DMARC-Eintrag wurde „left as it is (existing policy)“. Die automatische Einrichtung ersetzt niemals eine Richtlinie, die du bereits hast. Wähle die Domain, hak den Eintrag an und verwende Preview changes for Cloudflare, wenn du den Wert des Toolkits willst.

Die Postfächer einer neuen Domain bekommen „Unauthorized“ in SOGo. SOGo kennt die Domain noch nicht: Die DNS-Seite zeigt eine Warnung; warte ein paar Minuten auf den automatischen Neustart oder drücke Restart SOGo.

Ich habe keine E-Mail erhalten. Prüfe, ob unter Notifications eine Adresse gespeichert ist; es wird eine E-Mail pro neuer Version geschickt, nicht täglich.