TobyMaxham
Follow on X

Outlook-Ausfall & Mailcow original

by Toby Maxham – 16 minute read

mail outlook server

Gestern gegen 19 Uhr unserer Zeit ist bei Microsoft weltweit die Mail ausgefallen, und bei Redaktionsschluss ist sie es teilweise immer noch. Genau dafür betreibe ich meinen Mailserver seit Jahren selbst. Dieser Post ordnet den Ausfall ein und zeigt, warum Verfügbarkeit nur die halbe Geschichte ist. Außerdem erkläre ich, warum EU-Entwickler und EU-Organisationen auf europäische Alternativen setzen sollten und wie ich das mit Mailcow löse.

Kurzfassung

  • Seit Donnerstag, 12.11.2026, sind Outlook/Exchange Online, Teams und Copilot weltweit gestört. Downdetector zählte rund 130.000 Outlook-Meldungen, nach über zwölf Stunden war die Störung noch nicht behoben (ORF, CNN).
  • Microsoft sieht keinen Cyberangriff, sondern Überlast. Das ist technisch beruhigend und strategisch bedenklich: Ein Fehler in der Infrastruktur eines Anbieters reicht, um Unternehmen, Behörden und Gerichte auf mehreren Kontinenten lahmzulegen.
  • Es ist nicht der erste Ausfall dieses Jahres. Im Januar, März, Mai und Ende August 2026 gab es bereits Störungen bei Exchange Online und Microsoft 365 (Details unten).
  • Wichtiger als jeder Ausfall ist die Rechtslage: Microsoft France konnte 2025 unter Eid nicht garantieren, dass EU-Daten vor dem Zugriff US-amerikanischer Behörden sicher sind (heise).
  • Eigenbetrieb ist machbar. Mailcow bündelt Postfix, Dovecot, Rspamd und SOGo in einem Docker-Stack und wird regelmäßig aktualisiert.

Was passiert ist

Microsoft meldete am Donnerstag kurz vor 13 Uhr Ostküstenzeit (19 Uhr MEZ), dass Nutzer Probleme beim Zugriff auf Exchange-Online-Postfächer haben (ABC News). Kurz darauf warnte der Konzern, dass die Störung weltweit die Verbindung zu Microsoft-365-Diensten beeinträchtigen könne (ORF).

  • Betroffene Dienste: Outlook/Exchange Online, Teams (Terminplanung, Kalender), Copilot, Admin-Portal, Schnittstellen zu Drittanbietern wie OpenAI und Anthropic (Quelle: ORF)
  • Umfang: Spitze bei rund 130.000 Downdetector-Meldungen, laut TechRadar mindestens 74 Länder (Quelle: NPR, TechRadar)
  • Dauer: Auch nach rund zehn Stunden nicht behoben, Wiederherstellung laut Microsoft „nicht wie erwartet“ (Quelle: Tagesspiegel/dpa)
  • Betroffene Organisationen: Unternehmen, Banken, Behörden und Gerichte in mehreren Ländern, darunter laut ORF in Australien Geheimdienst und Bundespolizei sowie das US-Repräsentantenhaus (Quelle: CNN, ORF)
  • Incident-IDs: EX1550543, MO1550821 (Microsoft 365 Admin Center) (Quelle: TechRadar)

Die Ursache, soweit bekannt. Microsoft spricht von einer „elevated load“. Ein Teil der Infrastruktur sei überlastet gewesen, und Server seien unerwartet ausgefallen. Die verbliebenen Systeme mussten ihre Last mit übernehmen (NPR, TechRadar). Zwischenzeitlich wurden Server wieder in Betrieb genommen, die bei neuem Datenverkehr erneut unresponsiv wurden (ABC News). Einen Cyberangriff schließt Microsoft aus (CNBC).

Bei Details gehen die Berichte auseinander. ORF nennt eine überlastete Komponente für den Aufbau sicherer Verbindungen und eine zurückgerollte Konfigurationsänderung, die zeitlich mit dem Start zusammenfiel. TechRadar schreibt dagegen, ein Zusammenhang mit einer kürzlichen Änderung sei nicht festgestellt worden. Ich lege mich hier nicht fest: Eine belastbare Ursachenanalyse (Post-Incident-Report) steht noch aus.

Stand dieses Abschnitts: 13.11.2026 vormittags.

Kein Einzelfall

Der aktuelle Ausfall ist der größte, aber bei Weitem nicht der einzige der letzten Monate. Die folgende Liste ist nicht vollständig, sie zeigt nur, was sich schnell belegen lässt:

  • 12./13.11.2026: Weltweite Exchange-Online-Störung, über 12 Stunden (Quelle: CNN)
  • Ende August 2026: Stundenlanger Ausfall, Login und Mailversand gestört. Microsoft nannte eine zentrale Authentifizierungskonfiguration (Quelle: ORF, UptimeRobot)
  • Mitte Mai 2026: Outlook- und Exchange-Online-Probleme, auch in Europa (Quelle: Born’s Tech)
  • 16.03.2026: Kein Zugriff auf Exchange-Online-Postfächer (EX1253275) (Quelle: Neowin)
  • 22./23.01.2026: Mailversand/-empfang und Admin-Portale gestört (MO1221364). Ursache laut Microsoft: Last nach reduzierter Kapazität bei Wartungsarbeiten (Quelle: Queen’s University)
  • 9./10.07.2025: Über 11 Stunden kein Postfachzugriff weltweit (Quelle: The Register)
  • 25./26.11.2024: Globale Outlook- und Teams-Störung nach einer fehlerhaften Änderung, die zurückgenommen wurde (Quelle: Boston University)

Das Muster ist technisch unspektakulär: Lastverteilung, Konfigurationsänderungen, Wartungsfenster. Das sind keine Anfängerfehler, sondern die normale Fehlerklasse großer, stark vernetzter Systeme. Wer sein gesamtes Mail-, Kalender- und Meeting-Setup auf eine solche Plattform legt, erbt dieses Risiko und hat selbst keinen Hebel, ihn zu beheben. Man kann nur warten und auf den Status-Post auf X schauen.

Mehr als Verfügbarkeit: wem gehört eigentlich deine Mail?

Ein Ausfall ist ärgerlich, aber er geht vorbei. Das tiefere Problem ist die Kontrolle: Wer den Mailserver betreibt, bestimmt, wer wann Zugriff hat, und welches Recht dabei gilt.

CLOUD Act. Der US-amerikanische CLOUD Act erlaubt US-Behörden, von US-Unternehmen Daten herauszuverlangen, die diese kontrollieren, unabhängig vom Speicherort (it-daily). Im Sommer 2025 wurde der Rechtschef von Microsoft France im französischen Senat gefragt, ob er garantieren könne, dass Daten französischer Bürger nie ohne Zustimmung der französischen Behörden an US-Stellen gehen. Seine Antwort unter Eid: Das könne er nicht (heise). Gleichzeitig betont Microsoft technische Zusagen, etwa dass Daten europäischer Kunden die EU seit Januar 2025 nicht verlassen (it-daily). Ein Rechenzentrum in Frankfurt ändert aber nichts an der Rechtsordnung, der der Betreiber unterliegt.

Der ICC-Fall. Nach US-Sanktionen gegen den Internationalen Strafgerichtshof berichtete AP, Microsoft habe das E-Mail-Konto des Chefanklägers Karim Khan gesperrt; er sei auf den Schweizer Dienst Proton ausgewichen (heise, Computer Weekly). Microsoft-Präsident Brad Smith bestreitet, das Konto gesperrt zu haben (JusticeInfo). Im Februar 2026 bat Microsoft das britische Parlament, die Aussage eines Mitarbeiters zu dem Fall zu korrigieren (The Register). Wie genau es ablief, ist also umstritten. Für meine Argumentation muss ich das nicht entscheiden: Entscheidend ist, dass eine Behörde im Ausland eine Institution in Den Haag über ihren Mail-Anbieter treffen kann, und dass die Betroffenen das nicht verhindern können.

Warum das für Entwickler und Teams relevant ist. Wer Kundendaten, Verträge oder Quellcode-Kommunikation über einen Dienst führt, den ein Drittstaat per Gesetz oder Sanktion erreichen kann, hat ein DSGVO-Risiko und ein Geschäftsrisiko. Das ist keine Verschwörungstheorie, sondern gehört in die Risikoanalyse, genau wie ein Backup-Konzept.

Das machen andere in der EU bereits

Die Idee, sich von einem einzelnen US-Anbieter zu lösen, ist längst praktische Politik.

  • Schleswig-Holstein. Die Landesverwaltung hat ihr Mailsystem im Oktober 2025 vollständig von Exchange und Outlook auf Open-Xchange und Thunderbird umgestellt (Landesregierung). Es ging um mehr als 40.000 Postfächer mit über 100 Millionen Mails und Kalendereinträgen (Cybernews). Seit September 2026 arbeitet laut ingenieur.de auch die Staatskanzlei mit Linux (ingenieur.de). Winfuture nennt für 2026 einmalige Kosten von rund 9 Millionen Euro und erwartete Lizenzeinsparungen von jährlich etwa 15 Millionen Euro (Winfuture).
  • Internationaler Strafgerichtshof. Der ICC hat sich laut Berichten von Microsoft abgewandt und setzt auf openDesk, eine Open-Source-Arbeitsumgebung des deutschen Zentrums für Digitale Souveränität (heise, The Register).

Und es gab auch Reibung: Beim Umstieg in Schleswig-Holstein kam es zu Ausfällen und Verzögerungen im Mailverkehr (It’s FOSS), und die Opposition bemängelt weiterhin technische Mängel im Arbeitsalltag (Winfuture). Das gehört zur ehrlichen Einordnung: Der Weg ist machbar, aber nicht kostenlos. Was ein ganzes Bundesland mit Dataport und Dienstleistern schafft, schafft ein Entwickler mit ein paar Postfächern deutlich leichter.

Keine Angst vor Eigenbetrieb

Selbst hosten heißt nicht, alles allein zu können, sondern zu wissen, was man betreibt, und es im Notfall selbst anfassen zu dürfen. Das ist ein anderes Risikoprofil: Wenn mein Server ausfällt, weiß ich, wo ich suchen muss. Wenn Microsoft ausfällt, bleibt mir das Warten.

Ich will das nicht schönreden. Mailserver sind anspruchsvoller als ein Webserver, aus vier Gründen:

  1. Zustellbarkeit. SPF, DKIM, DMARC, Reverse-DNS und eine saubere IP-Reputation sind Pflicht. Mailcow nimmt dir davon viel ab (DKIM-Signierung ist eingebaut), die DNS-Einträge musst du trotzdem selbst setzen.
  2. Sicherheit. Ein öffentlicher Mailserver wird dauernd angegriffen. Updates sind keine Option, sondern Betriebsroutine.
  3. Backups. Ein Mailserver ohne getestetes Restore ist keine Alternative, sondern ein Risiko.
  4. Ressourcen. Mailcow braucht laut Vergleichen mehrere GB RAM, weil neben Postfix und Dovecot auch SOGo, Rspamd und optional ClamAV laufen (selfhosting.sh).

Dagegen steht: Du musst nicht alles selbst machen. Du kannst Mail für deine Domain selbst hosten, aber bei einem europäischen Anbieter, oder du mietest einen verwalteten Server in der EU und betreibst darauf nur die Software. Entscheidend ist, dass die Daten und die Kontrolle in einer Rechtsordnung bleiben, die du einschätzen kannst, und dass du den Anbieter wechseln kannst, ohne deine Mails zu verlieren. Bei einem Standardprotokoll wie IMAP geht das.

Darum nutze ich Mailcow

Ich betreibe meine Mail seit etwa drei Jahren mit Mailcow. Mailcow ist eine quelloffene (GPL-3.0) Mailserver-Suite von Servercow aus Deutschland, die bewährte Bausteine in einem Docker-Compose-Stack zusammenfasst (AlternativeTo, selfhosting.sh).

  • Postfix: SMTP, Ein- und Ausgang (Quelle: DATAZONE)
  • Dovecot: IMAP/POP3, Speicherung, Sieve-Filter (Quelle: DATAZONE)
  • SOGo: Webmail, CalDAV, CardDAV, ActiveSync (Quelle: DATAZONE)
  • Rspamd: Spam-Erkennung, DKIM-Signierung (Quelle: DATAZONE)
  • Unbound, Watchdog: Eigener DNS-Resolver (z. B. für DNSSEC-Prüfungen), Container-Monitoring (Quelle: mailcow-Doku)
  • ClamAV, MariaDB, Redis: Virenscan, Datenhaltung, Cache (Quelle: mailcow-Doku)

Was mir daran gefällt

  • Ein Update für alles. Eine Compose-Datei beschreibt den ganzen Stack, Updates ziehen alle Container gemeinsam, es gibt keine Versionsdrift zwischen Postfix und Dovecot (DATAZONE).
  • Eine Web-Oberfläche mit API. Domains, Postfächer, Aliase, Quotas und Rate-Limits verwaltest du in einer Admin-Oberfläche, die auch eine REST-API hat (selfhosting.sh).
  • Kalender, Kontakte und Mobilgeräte. SOGo liefert Webmail, CalDAV/CardDAV und ActiveSync, auch für iOS, Android und Outlook Mobile (DATAZONE).
  • DKIM ist eingebaut. Als Autor von tobymaxham/laravel-dkim weiß ich, wie oft das bei anderen Providern fehlt. In Mailcow ist es von Haus aus dabei.
  • Offene Standards. IMAP, SMTP, CalDAV: Ich kann jederzeit mit meinen Daten umziehen.

Wie aktiv das Projekt ist. Mailcow veröffentlicht Updates im Jahr 2026 bisher ungefähr alle ein bis zwei Monate, mit Nachlieferungen bei Bedarf: 2026-01, 2026-03 (mit 03a und 03b), 2026-05 (mit a bis c) und 2026-07 (mit 07a) (Release-Übersicht). Die März-Version brachte erzwungene Zwei-Faktor-Anmeldung und DNS-01-Challenges für Zertifikate (Release 2026-03, selfhosting.sh). Im Januar kamen eingeschränkter EAS/DAV-Zugriff und Beschränkungen beim Alias-Versand hinzu (Release 2026-01).

Dazu gehört eine Beobachtung, die ich für ein Qualitätsmerkmal halte: Revision 2026-03b schloss mehrere Sicherheitslücken, darunter Stored XSS im Admin-Bereich (vuln.today). Das Projekt empfahl das Update ausdrücklich (Release 2026-03b). Offen gehandhabte Patches sind besser als ein Dienst, dessen Fehler du nie siehst. Es bedeutet aber auch: Du musst sie einspielen.

Meine Erfahrung. Bei mir laufen rund 20 Domains und etwa 30 Postfächer auf Mailcow. Updates spiele ich ein, sobald sie in Mailcow verfügbar sind. Fehler und Probleme kommen sehr selten vor und lassen sich gut beheben. Bei der Zustellbarkeit hatte ich bisher keine Probleme: Über DKIM, SPF und DMARC habe ich die volle Kontrolle und setze alles selbst.

Mailcow im Zhylon-Ecosystem. Mailcow betreibt nicht nur meine eigene Post, es ist auch die Basis für das Zhylon-Ecosystem. Darauf laufen mehrere Dienste, und einige sind erst dadurch entstanden, zum Beispiel Mail via API und das Mail Labor.

Die Grenzen. Mailcow liefert IMAP, kein Exchange. Serverseitige Suche, serverseitige Regeln und öffentliche Ordner sind eingeschränkt, und Desktop-Outlook funktioniert, fühlt sich aber nicht so nahtlos an wie mit Exchange (DATAZONE). Wer tief in Exchange-spezifische Workflows eingebunden ist, muss das vor dem Umstieg prüfen.

Praxis: so fängst du an

Du musst nicht morgen alles umziehen. Diese Reihenfolge hat sich für mich bewährt:

  1. Abhängigkeiten auflisten. Was hängt an Microsoft 365: Mail, Kalender, Teams, Single Sign-on, API-Zugriffe? Der aktuelle Ausfall hat sogar Schnittstellen zu KI-Diensten gestört (ORF), also prüfe auch Integrationen.
  2. Eigene Domain, eigener MX. Wer Adressen auf der eigenen Domain nutzt, kann den Anbieter wechseln, ohne dass sich Adressen ändern. Das ist die wichtigste Freiheit, und sie kostet nichts.
  3. Notfallkanal festlegen. Ein zweiter Weg, der nicht am selben Anbieter hängt (Matrix, Signal, Telefon), samt Liste, wer wen wie erreicht.
  4. Mit einem Postfach starten. Zum Beispiel ein Projekt oder die eigene Domain, nicht gleich die ganze Firma.
  5. Backup und Restore testen, bevor das erste echte Postfach darauf liegt.

Die Installation selbst ist überschaubar. Das Grundgerüst laut der Anleitung von selfhosting.sh (Docker und ein Hostname wie mail.example.com vorausgesetzt):

cd /opt
git clone https://github.com/mailcow/mailcow-dockerized.git
cd mailcow-dockerized
./generate_config.sh   # fragt FQDN und Zeitzone ab
docker compose pull
docker compose up -d

# später: Update
./update.sh

# Backup (Zielpfad anpassen)
BACKUP_LOCATION=/var/backups/mailcow ./helper-scripts/backup_and_restore.sh backup all

Danach folgen die DNS-Einträge (MX, SPF, DKIM, DMARC, Reverse-DNS), die du dir von der Mailcow-Oberfläche anzeigen lässt. Prüfe die Zustellbarkeit mit einem Testtool, bevor du echte Mails schickst. Die offizielle Anleitung findest du in der mailcow-Dokumentation.

Für Laravel-Projekte. Deine Anwendung spricht SMTP mit dem eigenen Server, mehr braucht es nicht:

MAIL_MAILER=smtp
MAIL_HOST=mail.example.com
MAIL_PORT=587
MAIL_ENCRYPTION=tls
MAIL_USERNAME[email protected]
MAIL_PASSWORD=...

Versende Mails über die Queue (Mail::to($user)->queue(new OrderShipped($order))). Dann blockiert ein Mailausfall, egal bei wem, nicht deine Requests, und fehlgeschlagene Jobs lassen sich wiederholen. Ein eigener Server ist dabei kein Freibrief: Gehen Mails an Empfänger bei Outlook.com oder Microsoft 365, kommen sie während einer Störung dort trotzdem verzögert an. Postfix hält sie in der Warteschlange und stellt später zu. Der Unterschied: Du siehst die Queue und kannst eingreifen.

Fazit

Der Ausfall vom 12./13. November ist kein Beweis, dass Microsoft schlecht arbeitet. Er zeigt, dass jede zentrale Plattform irgendwann ausfällt, und dass du dann nichts tun kannst. Dazu kommt die Rechtsfrage, die kein Rechenzentrum in der EU löst. Beides spricht dafür, kritische Kommunikation nicht allein bei einem außereuropäischen Anbieter zu halten.

Mein Weg ist Mailcow auf eigener Infrastruktur. Er ist nicht der einzige: Es gibt europäische Anbieter, verwaltete Open-Source-Lösungen wie Open-Xchange oder openDesk, und ganze Verwaltungen zeigen, dass der Umstieg klappt, wenn man ihn plant. Wichtig ist nur, dass du die Entscheidung bewusst triffst und einen Plan B hast, bevor der nächste Ausfall kommt.

Zhylon zeigt für mich, dass Eigenbetrieb mehr kann, als einen Dienst zu ersetzen: Auf einem eigenen Mailserver sind eigene Produkte entstanden, die ich selbst betreibe und kontrolliere. Wenn du sehen willst, was daraus geworden ist, schau dir das Zhylon-Ecosystem an.

Quellen

Zum Ausfall (12./13.11.2026)

Frühere Ausfälle

Souveränität und Recht

EU-Beispiele

Mailcow

Share Post LinkedIn | Follow @TobyMaxham

Join the newsletter

Occasional thoughts on Laravel, PHP, and building real-world applications — straight from what I’m working on.

The newsletter is on a little break right now — see you soon!

Found something interesting to share? Submit a link to the community section.