mailcow: SOGo als beliebiges Postfach öffnen, per UI updaten und DNS-Einträge setzen

Das Problem: drei Routineaufgaben, die deine Woche fressen

Wenn du mailcow-dockerized für dich selbst oder eine Handvoll Kunden betreibst, kennst du den Ablauf. Jemand bittet dich, ein Postfach zu prüfen, du klickst in der Admin-Oberfläche auf SOGo daneben, und deine Admin-Sitzung ist weg: mailcow hält eine Sitzung pro Hostname, also wechselt dieselbe Sitzung in das Postfach. Und solange die Admin-Sitzung offen ist, schickt SOGo dich ohnehin zurück zum Dashboard.

Dann ist da das Update. mailcow erscheint oft, und Aktualisieren heißt: SSH-Sitzung, update.sh und die Hoffnung, dass du an eine Sicherung gedacht hast. Und jede neue Mail-Domain braucht ihre MX-, SPF-, DKIM- und DMARC-Einträge von Hand beim DNS-Anbieter, plus eine Reverse-DNS-Prüfung, an die sich niemand erinnert, bis Gmail anfängt, Mail abzulehnen.

mailcow Toolkit ist ein Plugin, das alle drei Aufgaben von deiner eigenen mailcow aus löst, und es funktioniert auch nach mailcow-Updates weiter, weil es keine versionierte mailcow-Datei verändert. Dieses Tutorial führt einmal durch die Einrichtung, damit aus den täglichen Aufgaben Klicks werden.

Voraussetzungen

mailcow-dockerized auf Linux (das Toolkit ist mit 2026-09 und 2026-09a getestet), installiert zum Beispiel in /opt/mailcow-dockerized, mit docker compose und systemd.
Root-Zugriff auf dem Host, mit installierten git, jq, flock, curl, tar und sha256sum.
Ausgehendes HTTPS zum medialab.works vom Server (Lizenzprüfung, Testphase, Toolkit-Updates).
Ein Lizenzschlüssel aus deinem medialab.works-Konto oder eine E-Mail-Adresse für die kostenlose 30-Tage-Testphase.
Ein zweiter Hostname für Webmail (zum Beispiel webmail.example.com) im DNS, ausgeliefert über denselben Reverse Proxy wie die mailcow-Oberfläche.
Ein Sicherungsordner, zum Beispiel /srv/backup/mailcow.
Für SOGo als Postfach: ALLOW_ADMIN_EMAIL_LOGIN=y in mailcow.conf und die Berechtigung Login as mailbox user.
Optional, zum Schreiben von DNS-Einträgen: ein Cloudflare-Konto und ein API-Token mit Zone > Zone > Read und Zone > DNS > Edit.

Schritt 1 — Toolkit installieren

Lade mailcow-toolkit-<version>.tar.gz aus deinem Konto herunter, entpacke es auf dem mailcow-Host 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 ist der Ort, an dem mailcow liegt (Standard /opt/mailcow-dockerized).
--webmail-url ist die Webmail-Adresse, https:// plus Hostname (ein optionaler Port ist erlaubt). Lässt du sie weg, behält der SOGo-Button das Standardverhalten von mailcow.
--backup-dir ist der Ort, an den Sicherungen vor Updates gehen. Lässt du ihn weg, läuft Update now ohne vorherige Sicherung, und der Installer warnt dich.
--name brauchst du nur, wenn du mehrere mailcow-Installationen auf einem Host betreibst.

Der Installer aktiviert fünf systemd-Units, darunter einen täglichen Timer für Versionsprüfung und Lizenz, einen, der alle 6 Stunden das Reverse DNS prüft, und einen, der alle 2 Minuten nach neuen mailcow-Domains sucht. Am Ende lädt er php-fpm neu und bittet dich, den Lizenzbereich zu öffnen.

Schritt 2 — Lizenz aktivieren

Öffne System > Updates (Toolkit) als Admin. Der Bereich License oben funktioniert auch ohne Lizenz: Gib deinen Schlüssel ein und drücke Activate, oder starte die kostenlose 30-Tage-Testphase mit deiner E-Mail-Adresse und öffne den angezeigten Stripe-Checkout-Link (die Karte wird dort abgefragt und während der Testphase nicht belastet). Die Seite aktiviert das Toolkit von selbst, sobald die Testphase beginnt. Ohne gültige Lizenz stoppen die Toolkit-Funktionen, und nichts wird gelöscht.

Schritt 3 — Ein separater Webmail-Hostname

Das ist der ganze Trick, um deine Admin-Sitzung zu behalten. Dein Browser hält ein Sitzungs-Cookie pro Hostname, also braucht SOGo einen eigenen Namen.

Richte webmail.example.com im DNS auf deinen Server.
Liefere ihn in deinem Reverse Proxy genau wie die mailcow-Oberfläche aus: gleiches Backend, gleiche Header. Es ist dieselbe mailcow, nur unter einem anderen Namen.
Gib ihm ein TLS-Zertifikat, wie der Oberfläche.

Wenn du bereits mit --webmail-url installiert hast, ist das erledigt. Wenn nicht, führe install.sh erneut aus der neuen Version aus; deine bisherige Webmail-Adresse und dein Sicherungsordner bleiben erhalten, wenn du sie weglässt.

Schritt 4 — SOGo als Postfach aktivieren

Setze in mailcow.conf ALLOW_ADMIN_EMAIL_LOGIN=y und wende es dann aus der mailcow-Oberfläche an.
Stelle sicher, dass der Admin die Berechtigung Login as mailbox user hat.

Von da an öffnet der SOGo-Button in der Postfachliste (für den Plattform-Admin; Domain-Admins behalten den mailcow-eigenen Button) SOGo als dieses Postfach, in einem neuen Tab, während dein Admin-Tab angemeldet bleibt. Die Übergabe nutzt ein einmaliges Token, 60 Sekunden gültig und nur einmal nutzbar; auf dem Webmail-Host startet eine frische Postfach-Sitzung und erbt nie die Admin-Rolle. Inaktive Postfächer werden abgelehnt, nach den mailcow-eigenen Regeln.

Jede Nutzung wird zweimal protokolliert: im Login-Log dieses Postfachs in mailcow als SSO-Login und im Audit-Log des Toolkits, mit der Angabe, wer es geöffnet hat und von welcher Adresse. Das ist der Teil, den Prüfer und Kunden mögen.

Schritt 5 — Updates aus der Oberfläche, Sicherung zuerst

Öffne System > Updates (Toolkit). Die Seite zeigt die installierte mailcow-Version, die letzte Prüfung und die neuen Änderungen. Der Server prüft täglich auf eine neue mailcow-Version und sendet eine E-Mail pro neuer Version an die Adresse, die du auf der Seite eingerichtet hast.

Wenn du bereit bist, drücke Update now. Das Toolkit erstellt zuerst eine Sicherung (crypt, redis, rspamd, postfix und mysql, 14 Tage aufbewahrt), führt dann das mailcow-eigene update.sh aus und wartet schließlich, bis jeder Container läuft und die Oberfläche antwortet. Das Log wird live auf der Seite angezeigt.

Zwei Garantien zählen: Schlägt die Sicherung fehl, wird das Update gestoppt und nichts verändert; schlägt update.sh fehl oder startet ein Container nicht, sagt die Seite das und behält das Log. Die Seite folgt der Sprache der mailcow-Oberfläche, Englisch oder Rumänisch.

Schritt 6 — DNS-Einträge für jede Domain

Öffne System > DNS & Cloudflare (nur Admins). Für jede mailcow-Domain und Alias-Domain listet es die Einträge, die mailcow braucht, nach der mailcow-eigenen DNS-Prüfung:

Required: der A-Eintrag von MAILCOW_HOSTNAME (DNS-only in Cloudflare), MX 10 auf MAILCOW_HOSTNAME, SPF, DKIM (Selector und Schlüssel von mailcow) und DMARC.
Recommended: die CNAMEs für autodiscover und autoconfig (DNS-only), SRV-Einträge für autodiscover, IMAPS, submission, SMTPS, POP3S (wenn POP3 erlaubt ist), CalDAV und CardDAV mit ihrem TXT path=/SOGo/dav/ (mit SOGo) sowie MTA-STS und TLS-RPT, wenn MTA-STS für die Domain aktiv ist.
Alias-Domains bekommen MX, SPF, DKIM, DMARC und, mit MTA-STS, dessen TXT-Einträge.

Jeder Eintrag wird mit dem öffentlichen DNS verglichen, mit einer Zonendatei, die du hochlädst (ein Cloudflare-Export oder eine beliebige BIND-Datei), und mit Cloudflare-Zugangsdaten mit der Live-Zone in Cloudflare. Status sind OK, missing, different, proxied (muss DNS-only sein), fix by hand oder unknown.

Zwei Voreinstellungen bewahren dich vor Ärger. IPv4 only by default: kein AAAA-Eintrag und ein SPF von v=spf1 ip4:<IPv4> -all; die Einstellung Use IPv6 ergänzt AAAA, ip6: und die IPv6-Reverse-DNS-Prüfung, weil ein Server, der AAAA veröffentlicht, ohne passenden IPv6-PTR seine Mail über IPv6 von Gmail und anderen abgelehnt bekommt. Und DMARC: eine bestehende gültige Richtlinie bleibt erhalten; andernfalls bekommst du v=DMARC1; p=quarantine;, mit Berichten an dmarc@ oder postmaster@ nur, wenn diese Adresse existiert. Die SRV-Ports folgen mailcow.conf und lassen sich für Server hinter einem Proxy oder NAT von Hand setzen.

Download BIND zone file liefert dir eine Datei, die Cloudflare unter DNS > Records > Import and Export importiert, mit cf_tags=cf-proxied:false bei Einträgen, die DNS-only bleiben müssen.

Schritt 7 — Sicher in Cloudflare übernehmen

Mit einem eingeschränkten API-Token (empfohlen) oder dem Global API Key hakst du Einträge an, siehst dir die Änderungen in der Vorschau an und wendest sie an. Zuerst wird eine JSON-Sicherung der Zone gespeichert, und die Änderung lässt sich rückgängig machen; nur die ausgewählten Einträge werden angelegt oder aktualisiert, nichts wird gelöscht, und jede Änderung geht ins Audit-Log. Die Zugangsdaten werden mit Cloudflare geprüft, verschlüsselt auf deinem Server gespeichert und nie wieder angezeigt. Die Cloudflare-Aktionen einer Domain erscheinen nur, wenn die gespeicherten Zugangsdaten DNS in dieser Zone bearbeiten dürfen; andernfalls sagt die Seite, warum.

Schritt 8 — Neue Domains richten sich selbst ein

Zwei Funktionen sind aus, bis du sie konfigurierst:

Automatic Cloudflare setup: Innerhalb von etwa 2 Minuten, nachdem eine Domain oder Alias-Domain in mailcow hinzugefügt wurde (Oberfläche oder API), werden ihre Einträge in der bestehenden Cloudflare-Zone angelegt. Falsche Einträge werden aktualisiert, fremde Einträge nie gelöscht, und eine bestehende abweichende SPF-, DMARC- oder TLS-RPT-Richtlinie bleibt, wie sie ist. Eine fehlende Zone wird gemeldet oder angelegt, wenn du es erlaubst; Fehler können dir per E-Mail geschickt werden.
New domain wizard: Die Rollenadressen (postmaster, abuse, hostmaster, webmaster, contact, info, office, dmarc, tls-rpt, noreply, security, jeweils optional, plus deine eigenen) werden als Aliasse auf eine Adresse deiner Wahl angelegt, zählen also nicht gegen das Postfach-Limit. noreply@ verwirft Mail stillschweigend. Ein bestehendes Postfach oder ein bestehender Alias wird nie angefasst.

Domains, die bereits existieren, wenn du eine Funktion einschaltest, bleiben unberührt; Provision now und Run wizard erledigen sie einzeln.

Schritt 9 — PTR und Domain-Status im Blick behalten

Das Toolkit prüft alle 6 Stunden das Reverse DNS und zeigt ein rotes „!“ im Admin-Menü, wenn es fehlschlägt. Die DNS-Seite öffnet mit einer Zusammenfassung und einer Auswahl aller Domains und Alias-Domains, die schlimmste zuerst: critical (Mail kann nicht zugestellt oder gesendet werden oder landet im Spam), warning (optionale Einträge fehlen) oder all good, mit einer Erklärung, was für jede Domain falsch ist und wie du es behebst. Die Status werden alle 10 Minuten im Hintergrund aktualisiert; Re-check now prüft eine Domain sofort. Die zuletzt ausgewählte Domain wird gemerkt.

Tipps und Fehlerbehebung

SOGo meldet „Unauthorized“ für eine neue Domain. SOGo liest die Domains von mailcow beim Start, eine später hinzugefügte Domain ist ihm also unbekannt. Ab 0.4.0 findet das Toolkit solche Domains alle 2 Minuten und startet nur den SOGo-Container neu (und leert memcached), innerhalb von etwa 3 bis 10 Minuten nach dem Hinzufügen der Domain: einmal für mehrere neue Domains, höchstens alle 10 Minuten, nur mit gültiger Lizenz. Jeder Neustart geht ins Audit-Log.
Der SOGo-Button verhält sich wie die Standard-mailcow. Prüfe, ob --webmail-url übergeben wurde, ob ALLOW_ADMIN_EMAIL_LOGIN=y angewendet ist und ob der Admin die Berechtigung Login as mailbox user hat.
Update now ist ausgegraut oder läuft ohne Sicherung. Der Sicherungsordner kommt aus --backup-dir; führe install.sh erneut aus, um ihn zu setzen.
Ein Eintrag zeigt proxied. Dieser Eintrag muss in Cloudflare DNS-only sein; der Zonendatei-Export markiert diese mit cf_tags=cf-proxied:false.
Server hinter einem Proxy oder NAT. Setze die SRV-Ports auf der DNS-Seite von Hand; ansonsten folgen sie mailcow.conf.
Keine Verbindung zu medialab.works. Nach der letzten erfolgreichen Prüfung funktioniert das Toolkit noch 7 Tage weiter.
Das Toolkit selbst aktualisieren. Nutze den Lizenzbereich: Er lädt das signierte Archiv herunter, prüft Größe und SHA-256 und behält die vorherige Version, sodass eine fehlgeschlagene Installation zurückgerollt wird. install.sh aus einer neueren Version funktioniert ebenfalls.

Fazit

Keine dieser drei Aufgaben ist schwer; man vergisst sie nur leicht. Ein separater Webmail-Hostname macht SOGo zu einer sicheren, protokollierten Ein-Klick-Ansicht jedes Postfachs, während deine Admin-Sitzung offen bleibt. Ein Update-Button mit Sicherung zuerst ersetzt den SSH-Schritt und das Raten. Und eine DNS-Seite, die jede Domain mit dem öffentlichen DNS und Cloudflare vergleicht, plus eine PTR-Prüfung alle 6 Stunden, findet die Probleme, bevor ein Empfänger es tut. Weil das Toolkit keine versionierte mailcow-Datei verändert, übersteht es mailcow-Updates – du richtest es also nur einmal ein.

Die user guide beschreibt jede Einstellung im Detail, das changelog listet, was jede Version hinzugefügt hat, und unsere knowledge base hat mehr für Self-Hoster. Fragen? Get in touch.

Dieser Beitrag wurde mit KI-Unterstützung auf Grundlage unserer Produktdokumentation oder der aufgeführten Quellen verfasst und vor der Veröffentlichung automatisch geprüft.