Kurze Information, auf die mich ein Blog-Leser gegen 12:06 Uhr hingewiesen hat. Der nutzt den turboSMTP Mail-Server als SMTP-Anbieter. Laut Leser waren die Website als auch deren Dienste(API/Login) sind seit mehr als 3 Stunden nicht erreichbar. Ich habe dann mal nachgeschaut, es scheint in den letzten Tagen schon gerumpelt zu haben – aber jetzt ist eine größere Störung aufgelaufen. Derzeit sehe ich auf deren Statusseite den Hinweis, dass die Dienste gestört seien. Grund ist ein Feuer in einem IBM-Rechenzentrum in Almere (Niederlande).
Wer ist TurboSMTP?
turboSMTP ist ein weltweit führender SMTP-Server Anbieter, der laut Eigenangaben über 50.000 Kunden betreut. Deren professioneller Postausgangs-Server sei ideal, um darüber Newsletter zu verschicken, heißt es. Denn der Server bietet zuverlässige SMTP-Relays.
Ein Leserhinweis auf Probleme
Blog-Leser Jens P. hat gegen 12:06 Uhr eine E-Mail mit dem Betreff "serversmtp.com seit 3h offline" geschickt und schrieb:
Herr Born,
vielleicht als Info für die community, falls noch mehr ggf. Dienste von serversmtp.com bzw. turbosmtp nutzen.
Die Website als auch deren Dienste(API/Login) sind seit mehr als 3 Stunden nicht erreichbar.
Wir routen inzwischen über Alternative.
Laut Leser wurden ihm bisher keine Gründe/Ursache bekannt geben. Ich habe dann mal selbst geschaut, die URL *https://serversmtp.com/de/ ist derzeit faktisch tot und liefert "Die Webseite ist nicht erreichbar".
Feuer in IBM-Rechenzentrum in Amsterdam schuld
Ich habe mal die nachfolgende Webseite aufgerufen – dort wird die Störung bestätigt und eine Ursache genannt. Derzeit sind alle Dienste nicht verfügbar, heißt es auf der Webseite.
Es liegt ein vollständiger Ausfall vor, von dem alle Nutzer und Dienste betroffen sind. Die Störung ist auf einen Brand im IBM-Rechenzentrum in Amsterdam zurückzuführen, in dem die Kerninfrastruktur des Anbieters gehostet wird. Dieser beobachtet die Situation aktiv und arbeitet eng mit IBM zusammen, um den Betrieb so schnell wie möglich wiederherzustellen.
Details zum Brand
Ergänzung: Zeitgleich mit der Veröffentlichung des Beitrags hier hat ein Blog-Leser im Diskussionsbereich auf den Großbrand hingewiesen und auf den Beitrag Zeer grote brand bij datacenter Rondebeltweg verlinkt. In einem Rechenzentrum am Rondebeltweg in Almere ist am Donnerstagmorgen gegen 08:30 Uhr ein Brand ausgebrochen. Dabei kommt es zu starker Rauchentwicklung. Die Feuerwehr hat den Einsatz auf einen Großbrand hochgestuft. Außerdem handelt es sich um eine GRIP1-Situation, was bedeutet, dass mehrere Rettungsdienste aufgrund des Ausmaßes des Vorfalls eng zusammenarbeiten.
Ergänzung: Der Brand im Rechenzentrum betrifft auch Kunden, die Cisco-Dienste (Cloud Email Security) verwenden und auf diesem Sekundär-Rechenzentrum gehostet waren (siehe Rechenzentrums-Brand in Almere (NL): Cisco auch betroffen (7.5.2026)).
MVP: 2013 – 2016
CISCO Cloud Email Security wird dort wohl auch gehostet:
https://status.ces.cisco.com
Our mitigation steps are currently in progress to address the outage at the Amsterdam (AER) secondary data center. The primary data center remains fully operational and continues processing emails as expected.
We are currently investigating a critical issue affecting connectivity for customers served by the AER (secondary) DC. Appliances, affecting ESA, in this data center are currently down, Emails in primary DC is working fine and processing emails. Preliminary information from one ISP suggests there may have been an incident at the location.
Danke – mir ist auf Facebook von Lesern auch mitgeteilt worden. O-Ton eines Kommentars: "NorthC on almere. Cisco Europa liegt auch dort. Deren Internet Anbindung der Offices läuft darüber. In Wien ist das Office zumindest offline deswegen". Single Point of failure?
Weiter sind auch die Universität von Utrecht und Infomedics (versendet Rechnung im Namen von medizinischen Anbietern) und weitere Firmen (vor allem in Holland) betroffen.
https://www.uu.nl/liveblog/problemen-met-het-netwerk-applicaties-en-websites-uu
https://www.infomedics.nl/zorgconsument/storingen-en-onderhoud
Man versucht nun, die Systeme im Backup Datencenter hochzufahren.