„Können wir unsere E-Mails nicht einfach selbst hosten? Dann gehören die Daten uns.“ Diese Frage höre ich oft, und sie ist berechtigt.
Aktualisiert am 19. Oktober 2026: Beitrag grundlegend überarbeitet mit Logdaten, zwei Vorfällen und Kosten aus dem eigenen Betrieb. Alle Messwerte stammen aus der Zeit bis Anfang September 2026 auf dem damaligen Server; seit September 2026 läuft der Mailserver auf einer anderen Maschine, über die dieser Beitrag nichts aussagt.
Seit März 2025 betreibe ich einen eigenen Mailserver: mailcow auf einem VPS. Statt die üblichen Argumente gegeneinanderzustellen, lege ich offen, was zehn Tage Logfile, zwei echte Vorfälle und zwei Preislisten hergeben. Alle Messwerte stammen aus diesem Betrieb. Über den Betrieb von Microsoft 365 sage ich hier bewusst nichts. Dazu habe ich keine eigenen Zahlen, und dann ist Schweigen die ehrlichere Hälfte des Vergleichs.
Zehn Tage Logfile, in Zahlen
Der Bestand: eine Domain, fünf Postfächer, acht Aliase, insgesamt 213 Nachrichten mit 62 MiB. Dafür liefen 18 Container.
Das Postfix-Log reichte zurück bis zum 24. August 2026; alle folgenden Zahlen sind der Stand vom 3. September, 00:56 Uhr. In diesen zehn Tagen liefen auf den drei SMTP-Ports zusammen 24.748 Verbindungen auf. Zugestellt wurden daraus 14 Mails, nach außen ging genau eine. Das sind 1,4 Mails pro Tag gegen einen kompletten Serverbetrieb.
Der Rest ist Abwehr. Auf Port 25 kamen 8.494 Verbindungen von 276 verschiedenen IPs an. Zum eigentlichen SMTP-Dienst durchgelassen hat postscreen davon 2.154 (2.146 nach bestandener Prüfung, 8 über die Allowlist). Die übrigen 6.340, also 74,6 Prozent, kamen dort nie an. Häufigster Grund: 3.051 Gegenstellen fingen an zu reden, bevor der Server seinen Begrüßungsbanner geschickt hatte; 3.075 Verbindungen standen zusätzlich auf mindestens einer der abgefragten Blocklisten.
Von den 2.154, die durchkamen, legten 2.124 wieder auf, ohne je einen Empfänger zu nennen. 16 nannten einen, der abgewiesen wurde. 14 wurden zugestellt. Diese drei Zahlen ergeben zusammen exakt die 2.154. Der ganze Port 25 dieses Servers passt in eine Zeile.
Parallel dazu liefen 4.289 fehlgeschlagene Anmeldeversuche von 41 IPs, 4.247 davon auf Port 465 und 42 auf 587. Erfolgreich angemeldet haben sich in diesen zehn Tagen genau drei Sitzungen: zwei von außen, eine aus dem Docker-Netz des Servers selbst. Aus einer davon stammt die eine Mail, die den Server nach außen verlassen hat.
Das ist der Teil, den man bei einem gehosteten Anbieter mitkauft, ohne ihn je zu sehen.
Der Fehler, den kein Mail-Logfile zeigt
Symptom. Externe Absender bekamen Zustellfehler. Auf dem Server war nichts zu sehen: Postfix protokollierte für diese Verbindungen gar nichts. Jeder Test von der Maschine selbst und aus den Container-Netzen war grün.
Diagnose. Das SYN-Paket erreichte den Container nie. Sichtbar wurde das
ausschließlich im Kernel-Journal: journalctl _TRANSPORT=kernel gefiltert auf
[UFW DOCKER BLOCK] liefert 23.369 verworfene Pakete, und zwar ausnahmslos
auf Mailports: 11.875 auf Port 25, 6.099 auf 993, 3.109 auf 587, 1.529 auf 465,
757 auf 4190. Die Drops auf Port 25 verteilen sich auf 976 verschiedene
Absender-IPs. Alle 23.369 Zeilen tragen dieselbe Signatur:
IN=eth0 OUT=br-mailcow. Der Verkehr läuft durch die FORWARD-Kette, nicht
durch INPUT.
Ursache. Die Firewall lief mit der ufw-docker-Integration. Container-Verkehr
wird von INPUT-Regeln nicht erfasst, ein ufw allow 25 bleibt daher
wirkungslos. Route-Regeln für Port 25 gab es zwar, aber in der falschen
Richtung: -i br-mailcow -o eth0 erlaubt, dass der Container hinaus darf,
nicht dass jemand hinein darf. Zusätzlich lässt die Regelkette private
Quellbereiche vorher per RETURN durch. Genau deshalb war jeder Test vom
Server und aus den Container-Netzen erfolgreich, während fremde Absender
stillschweigend gedroppt wurden.
Fix. Acht ACCEPT-Regeln in der FORWARD-Kette auf die festen Container-IPs
des mailcow-Standardnetzes: 172.22.1.253 für 25/465/587 (Postfix),
172.22.1.250 für 143/993/110/995/4190 (Dovecot). Das sind exakt die acht
Ports, die mailcow als eingehend offen verlangt. Zwischen dem letzten
protokollierten Drop und dem Zeitstempel der korrigierten Regeldatei liegen vier
Minuten und 43 Sekunden. Seit dem 24. Juni 2026: null Drops.
Zwei Einschränkungen, die dazugehören. Das Drop-Logging ist auf drei Zeilen pro Minute begrenzt: Die 11.875 sind eine ratenbegrenzte Stichprobe, die tatsächliche Zahl liegt höher. Und der erste protokollierte Drop fällt auf den 8. Mai, den Tag, an dem das Journal beginnt; das Problem war also mindestens 46 Tage alt, vermutlich älter.
Aufgefallen ist es mir erst am 23. Juni, weil eine Mail an eine meiner Adressen beim Absender zurücklief. Sechseinhalb Wochen lang hat dieser Server eingehende Verbindungen verworfen, ohne dass irgendetwas davon in einem Mail-Logfile stand. Das ist der eigentliche Befund, nicht die Firewall-Regel.
Warum der Versionsabstand gefährlicher ist als das Update
Symptom. Nach dem Update im Juni 2026 kam der Stack nicht hoch. Alle Container hingen in einer Schleife („Waiting for database to come up…“), keine Listener, Mail vollständig tot.
Was das Update nachweislich tut. update.sh vergleicht die
Konfigurationsdatei mit einer Liste bekannter Optionen und hängt jede an, die
noch nicht darin steht. Die Bedingung im Skript prüft ausschließlich auf
Anwesenheit. Ergänzt wird also nur, was fehlt. Für zwei dieser Optionen
erzeugt das Skript den Wert dabei frisch aus /dev/urandom: das Redis-Passwort
und den SOGo-Verschlüsselungsschlüssel. Beide Dienste halten ihre Daten aber in
persistenten Volumes, mit den alten Werten.
Und eine Option fehlt genau dann, wenn man die Version übersprungen hat, die sie eingeführt hat. Zwischen Installation und erstem Update lagen bei mir fünfzehn Monate. Je größer der Sprung, desto mehr Optionen fehlen, desto mehr Werte werden neu gewürfelt.
Was ich nicht mehr belegen kann. Welcher Wert im Juni tatsächlich auseinanderlief, lässt sich heute nicht mehr rekonstruieren: Die Container-Logs von damals existieren nicht mehr. Die Datenbank-Passwörter stehen in der Optionsliste des Skripts nicht drin, ausgerechnet die naheliegendste Erklärung für eine Datenbank-Schleife lässt sich also nicht bestätigen. Ich lasse das so stehen, statt eine Kausalkette zu bauen, die ich nicht prüfen kann.
Eine Nebenwirkung führte zusätzlich in die Irre: Bei aktivem IPv6 (und das war
auf diesem Server der richtige Zustand) erreichen die Container die Datenbank
über IPv6, und die Fehlermeldung nennt dann eine IPv6-Adresse
(Access denied for mailcow@'fd4d:…'). Das sieht nach einer fehlenden
IPv6-Berechtigung aus. Sie ist es nicht. IPv6 abzuschalten war der falsche
Reflex und hat nur Zeit gekostet.
Fix. Rückgriff auf ein Konfigurations-Backup vom März. Ohne dieses Backup wäre die Anmeldung an die eigene Datenbank nicht wiederherstellbar gewesen.
Gegenprobe. Das zweite Update am 20. August 2026, knapp zwei Monate nach dem ersten, verlief ohne Zwischenfall. Die Mailunterbrechung ist im Monitoring sauber eingegrenzt: Die letzte erfolgreiche Prüfung auf Port 587 lief um 11:53 UTC, die nächste um 12:00 UTC, dazwischen schlugen zwei fehl. Höchstens sieben Minuten.
Die Lehre ist unbequem, weil sie den Einzelbetreiber trifft: Nicht das Update ist das Risiko, sondern der Abstand zum letzten. Und Updates aufzuschieben ist genau das, was passiert, wenn niemand dafür zuständig ist.
Was der Server kostet
mailcow nennt als Minimum 6 GiB RAM plus 1 GiB Swap, 20 GiB Platte und 1 GHz CPU. Gemessen bei mir, nach dreizehn Tagen Laufzeit ohne Neustart: Die 18 Container belegten zusammen rund 810 MiB, gut ein Achtel dessen, was die Dokumentation verlangt. Der größte Einzelposten ist mit 242 MiB der Job-Scheduler, danach der Spamfilter rspamd mit 132 MiB und die Datenbank mit 100 MiB; der Virenscanner ClamAV liegt bei 60 MiB.
Die 6 GiB sind also keine Verbrauchsangabe, sondern Reserve für Last, die dieser Server nie sah. Sie sind trotzdem die Zahl, nach der man den Tarif kauft.
Auf der Platte lagen 664 MB Volumes; die 15 Images summierten sich in
docker images auf 3,1 GB, wobei gemeinsame Layer darin mehrfach gezählt sind.
Der tatsächliche Platzbedarf lag darunter. Die Mails selbst waren mit 62 MiB
der kleinste Posten.
Der kleinste Tarif in netcups aktueller VPS-Liste, der das genannte Minimum erfüllt (4 vCore, 8 GB RAM, 256 GB NVMe), steht bei 10,36 € im Monat inklusive Mehrwertsteuer (VPS 1000 G12, abgerufen am 3. September 2026).
Dem gegenüber die Microsoft-Listenpreise, die seit dem 1. Juli 2026 gelten, pro Nutzer und Monat: Business Basic 7,00 USD (vorher 6,00), Business Standard 14,00 USD (vorher 12,50), Business Premium unverändert 22,00 USD. Warum die Erhöhung viele Betriebe erst 2027 erreicht, steht im Beitrag zum Microsoft 365 Lizenz-Audit 2026.
Bei fünf Postfächern sind das 35 bis 70 USD im Monat gegen gut 10 € Serverkosten. Das klingt eindeutig, ist es aber nicht. Erstens vergleicht man hier Dollar-Listenpreise mit einem Euro-Listentarif. Ihr tatsächlicher Preis steht in Ihrem Partner- oder CSP-Vertrag. Zweitens, und das ist der Punkt: Der Server ist der billige Teil.
Was der Betrieb an Zeit kostet
Gemessen, nicht geschätzt:
- 2 Updates in gut 17 Monaten (24.06. und 20.08.2026)
- 14 Reboots seit dem 1. Juni 2026 (Kernel 6.8.0-124 bis -138). Die vier davon, die ins 30-Tage-Monitoring fallen, kosteten je genau eine fehlgeschlagene IMAPS-Prüfung. Die SMTP-Prüfung auf Port 587 lief bei allen vieren durch
- 14 von 14 nächtlichen Backups fehlerfrei, je 72 bis 73 MB, sieben verschlüsselte Generationen ausgelagert. Belegt ist damit, dass sie erzeugt werden. Dass sich eine davon zurückspielen lässt, habe ich nicht getestet. Wie das in ein Gesamtkonzept gehört, steht in der 3-2-1-Backup-Strategie
- 1 Zertifikatserneuerung, dokumentiert durch eine einzige Logzeile
- 4 Container-Neustarts, die sich selbst repariert haben
- Verfügbarkeit über 30 Tage: 99,986 % auf SMTP 587 und 99,958 % auf IMAPS 993, gemessen an je rund 14.400 Prüfungen im 180-Sekunden-Takt
Die ehrliche Pointe steckt in der letzten Zeile: Jede einzelne Unterbrechung der vergangenen 30 Tage war ein Kernel-Reboot oder das Update. Kein einziger echter Ausfall. Nicht der Mailserver fällt aus, sondern der eigene Wartungsplan.
Der Ruhebetrieb kostet damit fast nichts. Geschätzt ein bis zwei Stunden im Monat, im Wesentlichen Lesezeit für den täglichen Statusbericht. Das ist ausdrücklich eine Schätzung, denn wie lange ich auf diesen Bericht schaue, protokolliert niemand. Teuer sind die Tage, an denen etwas Unerwartetes passiert: zwei in siebzehn Monaten, beide im Juni. Wie teuer, kann ich nicht beziffern: Die Logs dieser beiden Vorfälle existieren nicht mehr.
Dazu kommt ein Posten, den keine Anleitung erwähnt: Manches funktioniert nicht,
weil der Hoster im Weg steht. Die Reputationsliste Spamhaus ließ sich von
diesem Server nicht abfragen: Der offizielle Testpunkt lieferte
127.255.255.254 statt 127.0.0.2. Dieser Code steht bei Spamhaus für „Anfrage
kam über einen öffentlichen Resolver“, und genau darüber liefen die Anfragen
hier: Der Server benutzte die Resolver seines Hosters. bl.spamcop.net dagegen,
eine der Listen, die mailcow hier tatsächlich abfragte, antwortete am selben
Testpunkt korrekt mit 127.0.0.2. Solche Dinge merkt man erst, wenn man sie
braucht.
Wann ich wozu rate
Microsoft 365 oder eine andere gehostete Lösung, wenn E-Mail einfach laufen soll und niemand im Haus sie verantworten will. Für die meisten kleinen Betriebe ist das der pragmatische und der richtige Weg; der Vergleich mit Google Workspace lohnt vorher. Wer noch einen eigenen Exchange betreibt, hat die Entscheidung ohnehin auf dem Tisch (siehe Exchange 2016/2019 am Support-Ende).
Einen eigenen Mailserver, wenn Datenhoheit ein echtes Geschäftskriterium ist, viele Postfächer anfallen und es jemanden gibt, der den Betrieb verantwortet. „Verantwortet“ heißt konkret: Er liest den Statusbericht, kennt den Unterschied zwischen INPUT und FORWARD, und schiebt Updates nicht fünfzehn Monate auf.
Fünf Postfächer rechtfertigen 18 Container betriebswirtschaftlich nicht. Was sie rechtfertigen, ist die Erfahrung daraus, und die fließt in jede Empfehlung ein, die ich zu diesem Thema abgebe.
Ein Mittelweg
Sie müssen sich nicht zwischen „alles selbst“ und „alles Microsoft“ entscheiden. Ein professionell betriebener Mailserver auf eigener Infrastruktur verbindet Datenhoheit mit klaren Zuständigkeiten, ohne dass Sie selbst DKIM-Records debuggen oder Kernel-Reboots einplanen. Entscheidend ist nicht die Software, sondern die Frage: Wer betreibt das verlässlich, auch in zwei Jahren?
Sie überlegen, Ihre E-Mail neu aufzustellen? In einem kostenlosen Erstgespräch schauen wir, was zu Ihrer Größe und Ihrem Anspruch passt, nüchtern und ohne Verkaufsdruck. Mehr dazu, wie ich Betrieb und Wartung übernehme, steht unter IT-Support und Wartung.
Hinweis: Die Beiträge dieses Blogs werden unter Einsatz von KI erstellt und vor der Veröffentlichung redaktionell geprüft. Die redaktionelle Verantwortung trägt Emre Yurtbay (siehe Impressum).