Mailjet im Totalausfall: Wenn stille Sperrungen und ignoranter Support das Geschäft gefährden

Ein Wechsel der Infrastruktur sollte eigentlich reibungslos ablaufen. Besonders dann, wenn sich an der technischen Integration in der Anwendung rein gar nichts ändert. Meine aktuelle Erfahrung mit Mailjet von Sinch beweist leider das genaue Gegenteil. Wir haben für die Plattform einer Kundin einen frischen kostenpflichtigen Mailjet Account angelegt. Der alte Account lief historisch bedingt über den ehemaligen Entwickler und konnte nicht übertragen werden. Die Symfony Anwendung selbst, das Versandvolumen von maximal 300 E Mails pro Tag und die Art der Nachrichten blieben exakt gleich.

Wir nutzen den Dienst ausschließlich für transaktionale E Mails. Dazu gehören Kernfunktionen wie das Zurücksetzen von Passwörtern, Double Opt In zur Account Bestätigung und der Rechnungsversand. Auch die Kontaktformulare laufen darüber, damit das Team meiner Kundin überhaupt Anfragen erhält. Wir haben das Starter Paket gebucht, alle Domains sauber verifiziert, das neue API Schlüsselpaar eingetragen und der Versand lief sofort an.

Am 13. April haben wir Mailjet eingerichtet und die Plattform scharf geschaltet. Nach exakt elf versendeten E Mails passierte das Unfassbare. Mailjet hat den Account stillschweigend gesperrt. Weder meine Kundin noch wir haben eine Warnung oder Benachrichtigung erhalten, und auch im Mailjet Dashboard gab es kein Ticket, auf das man hätte reagieren können. Entdeckt haben wir das Problem erst am 15. April. Jemand aus einem persönlichen Termin meiner Kundin hatte sich telefonisch gemeldet, weil auf eine Anfrage über das Kontaktformular keine Reaktion kam. Erst der Blick in die System Logs zeigte die bittere Realität. Die Mailjet API lieferte nur den Hinweis zurück, dass der Account vorübergehend deaktiviert sei und man den Support kontaktieren solle. Wer im Netz nach dem Begriff Mailjet Account gesperrt sucht, wird vermutlich genau dieses desaströse Verhalten meinen. Eine stille Sperrung auf einem geschäftskritischen Transaktionskanal ist völlig inakzeptabel.

Unsere Erfahrung mit dem Sinch Mailjet Support setzt diesem Vorfall jedoch die Krone auf. Wir haben am 15. April sofort ein Ticket eröffnet. Innerhalb weniger Minuten kam eine automatisierte Antwort. Es wurde ein detaillierter Fragenkatalog zum Versandvolumen und zur Herkunft der Adressen gefordert. Ich habe diese Fragen umgehend ausführlich beantwortet und glasklar formuliert, dass wir keinerlei Newsletter versenden. Ab diesem Moment herrschte absolute Funkstille. Trotz mehrerer Nachfragen an den folgenden Tagen und einer massiven Eskalation meinerseits am 21. April gab es bis heute keine inhaltliche Rückmeldung. Keine Aufhebung der Sperre, keine Erklärung und keine Lösung.

Wenn man nach einer ehrlichen Mailjet Bewertung sucht, muss dieses absurde Verhalten zwingend erwähnt werden. Nicht zu reagieren ist der denkbar schlechteste Zug, den ein Dienstleister machen kann. Es ist ein respektloser Umgang mit meiner investierten Arbeitszeit und es schädigt aktiv das Geschäft meiner Kundin. Jede nicht beantwortete Anfrage ist eine verlorene Interessentin. Jedes nicht gebuchte Inserat wandert an Mitbewerber ab, und der Schaden lässt sich am Ende nicht einmal sauber beziffern, weil niemand weiß, wer sich leise wieder abgewendet hat.

Als Architekt betrachte ich dieses Desaster auf zwei Ebenen. Es gibt eine klare Lösung für die Anbieterseite und eine zwingende Schutzmaßnahme für die Entwicklerseite.

Auf der Seite von Mailjet liegt ein katastrophales Systemdesign vor. Eine automatische Risikoanalyse durch Algorithmen ist völlig verständlich. Wenn jedoch ein Algorithmus einen frisch zahlenden Kunden sperrt, muss zwingend ein sofortiger Alarm an den Account Inhaber ausgelöst werden. Eine stille Sperrung, die man nur durch Zufall über API Logs bemerkt, ist schlichtweg Inkompetenz im Produktdesign. Zudem muss ein bezahlter Account bei einer Sperrung direkt in einen menschlichen Fast Track Prozess übergeben werden. Ein automatisiertes Formular zu senden und den Kunden danach eine ganze Woche lang zu ignorieren, ist ein prozessuales Totalversagen.

Für uns Entwickler lautet die architektonische Lösung Fallback Transport. Wer sich auf einen einzelnen API Anbieter verlässt, ist verlassen. Die bittere Lektion aus dieser Geschichte ist die absolute Notwendigkeit einer redundanten Infrastruktur. Moderne Frameworks wie der Symfony Mailer bieten native Failover Konfigurationen an. Wir haben die Anwendung nun auf einen firmeneigenen SMTP Server als primären Transport umgestellt und können jederzeit einen zweiten Transportweg als Fallback danebenhängen. Welchen Anbieter man als zweite Schiene wählt, ist zweitrangig. Mailjet Alternativen gibt es am Markt mehr als genug. So bleibt der geschäftskritische Fluss zum Kunden immer intakt. Vertrauen ist gut, eine saubere Failover Architektur ist besser.