Verwaltetes Single-Tenant-Hosting für den Open-Source-MTA.

Was ist KumoMTA?

KumoMTA ist der erste Open-Source-Mail-Transfer-Agent (MTA), der von Grund auf für den ausgehenden Versand in großem Volumen entworfen wurde, auf dem Niveau kommerzieller MTAs wie PowerMTA oder Momentum. Geschaffen hat ihn eine Gruppe von Veteranen der E-Mail-Infrastruktur — aus demselben Umfeld, aus dem PowerMTA stammt — und er erscheint unter der Apache-2.0-Lizenz. Der Kern ist in Rust geschrieben, für Leistung und Speichersicherheit, und die Policy schreibt man in Lua, sodass die Traffic-Modellierung und die Regeln Code sind, den Sie steuern, keine Optionen einer Konsole.

Der praktische Unterschied zu einem normalen Mailserver sind die Warteschlange und die Steuerung. Ein empfangender MTA routet an wenige interne Ziele; einer für den Massenversand verteilt an Zehntausende externe Ziele zugleich, jedes mit eigenem Throttling, eigener Reputation und eigener Akzeptanzrate. KumoMTA ist dafür gemacht: es respektiert das Throttling pro Empfänger — antwortet Gmail mit einem 421 „langsamer“, drosselt es und versucht es erneut — denn ohne das kann eine neue IP binnen Stunden geblockt werden. Es ist nicht für jeden, und wir sagen gleich, für wen nicht.

Es lohnt, ihn zwischen seinen Geschwistern einzuordnen. Ein Allzweck-MTA wie Postfix empfängt und routet E-Mail innerhalb einer Organisation und deckt die überwältigende Mehrheit der Fälle bei Weitem ab; ein Massenversand-MTA wie KumoMTA oder PowerMTA ist gemacht, um in großem Maßstab mit feiner Reputationssteuerung zu verteilen. Die beiden Kategorien zu verwechseln wird in beide Richtungen teuer: ein Postfix über seine Grenze zu treiben, oder für eine kleine Liste eine Massenversand-Plattform zu zahlen. KumoMTA verdient seinen Platz erst, wenn Volumen und Steuerung, die Sie brauchen, den Betrieb einer ernsten Infrastruktur rechtfertigen.

Im deutschsprachigen Raum sehen wir vor allem zwei Profile, für die sich das rechnet. Das erste ist der Mittelständler mit hohem Transaktionsvolumen — ein Online-Shop, ein SaaS-Anbieter, ein Versanddienstleister — der Bestellbestätigungen, Rechnungen und Benachrichtigungen zuverlässig zustellen muss und beim Wechsel von einem Pro-Nachricht-ESP spürbar spart. Das zweite ist die Plattform, die selbst zum E-Mail-Anbieter wird: eine Agentur oder ein SaaS, das im Namen vieler eigener Kunden sendet und Mandantentrennung braucht — eigene Pools, eigene IPs, eigene Policy pro Kunde. Genau für diese Mehrmandanten-Steuerung ist KumoMTA gebaut, mit Traffic-Shaping und IP-Pool-Verwaltung als Kernfunktion statt als Aufsatz, weshalb mehrere Self-Serve-ESPs ihre Plattform darauf aufsetzen.

Dass es Open Source ist, ändert zudem das Verhältnis zu dem, der es baut. Unter Apache 2.0 gibt es keine Jahresgebühr, die einen Anbieter finanziert, der morgen mit Ihnen konkurrieren könnte, und keine Angst vor Preiserhöhung oder Abkündigung; das Projekt trägt eine Community, zu der einige der größten Versender der Welt gehören. Für ein Unternehmen, dessen Geschäft von E-Mail abhängt, ist die Unabhängigkeit von der Lizenz eines Dritten eine Form von Betriebssicherheit, nicht nur eine Ersparnis — gerade im deutschsprachigen Raum, wo Datensouveränität und Kontrolle über den eigenen Stack zunehmend Teil jeder Beschaffungsentscheidung sind.

KumoMTA oder PowerMTA?

PowerMTA ist seit Jahren der Branchenstandard für ESPs, mit einer einsatzfertigen Zustellbarkeits-Verwaltung und reifer Dokumentation, und für viele Teams bleibt es die richtige Wahl. Aber es ist lizenzierte Software: sie kostet einige Tausend Dollar im Jahr — in der Größenordnung von achttausend mit der enthaltenen Analytik — und hängt an einer Lizenzdatei, die regelmäßig geprüft wird; schlägt die Validierung fehl, nimmt der MTA keine Nachrichten mehr an. KumoMTA hat keine Lizenzdatei, kein „Phone-Home“ und keine Jahresgebühr: es gehört Ihnen.

Der eigentliche Gegensatz liegt im Modell. PowerMTA entstand für On-Premise-Umgebungen, und seine Konfiguration ist dicht, aber bekannt; KumoMTA wurde mit Blick auf die Cloud entworfen — „Kumo“ ist japanisch für „Wolke“ — skaliert horizontal unter Containern und bietet eine HTTP-API. Das ist kein kostenloser Zauber: KumoMTA ist technischer und verlangt Vertrautheit mit Lua und DevOps-Praktiken, während PowerMTA mit seinen Standard-Dateien leichter zu starten ist. Das Signal, dass sich die Branche bewegt, ist konkret: Plattformen wie Postmark haben ihre gesamte Infrastruktur von PowerMTA auf KumoMTA migriert, wegen der Echtzeit-Steuerung des Traffics. Wir hosten und betreiben beide, also passt die Empfehlung zu Ihnen, nicht zu dem, was uns am meisten zu verkaufen nützt.

Es gibt eine Risiko-Nuance, die man ohne Dramatik benennen sollte. Weil PowerMTA seine Lizenz gegen einen externen Server prüft, kann eine fehlgeschlagene Validierung — eine abgelaufene Lizenz, ein Konnektivitätsproblem — den MTA dazu bringen, keine neuen Nachrichten anzunehmen, gerade wenn Sie es am wenigsten erwarten. Bei einem Open-Source-MTA gibt es diese Abhängigkeit nicht: die Software gehört Ihnen, ohne Lizenzdatei, die abläuft, und ohne Anbieter, der Ihre Plattform aus der Ferne abschalten kann. Für ein so kritisches Stück wie den Versand wiegt dieser Governance-Unterschied so schwer wie der Preis — und im deutschen Markt, wo die Kontrolle über die eigene Lieferkette zählt, oft schwerer.

Diese Governance-Frage greift weiter, als sie auf den ersten Blick wirkt. Wenn eine Aufsichtsbehörde oder ein Auditor wissen will, wo Ihre E-Mail verarbeitet wird und wer den Stack kontrolliert, ist ein Open-Source-MTA auf einem Single-Tenant-Host in einer EU-Region eine kurze, überprüfbare Antwort: der Code ist offen einsehbar, es gibt keinen verborgenen Dienst, der nach Hause telefoniert, und der Betrieb liegt nachweisbar in europäischer Hand. Unter Regimen wie der DSGVO und, für regulierte Branchen, NIS2 oder DORA ist diese Nachweisbarkeit kein Beiwerk, sondern Teil der Pflicht. Eine proprietäre Plattform, deren Lizenzserver und Telemetrie außerhalb Ihrer Kontrolle liegen, macht dieselbe Auskunft länger und unsicherer. Wir sehen genau deshalb im deutschsprachigen Markt eine wachsende Zahl von Teams, die einen offenen, selbst kontrollierten Versand-Stack einer lizenzgebundenen Lösung vorziehen — nicht aus Ideologie, sondern weil es die Compliance-Kette verkürzt.

Migration ohne Versandstopp

E-Mail zu migrieren macht Angst, weil ein Versandstopp Geld kostet, also stoppen wir nicht. Wir betreiben die alte und die neue Plattform parallel: wir übernehmen Ihre Domains, Ihre Signaturschlüssel und Ihre Sperrlisten, wärmen die neuen IPs auf einer Rampe auf, während die alten noch Produktion tragen, und schalten den Traffic erst um, wenn die neue Reputation trägt. Kommen Sie von PowerMTA oder Momentum, hat der größte Teil Ihrer Konfiguration ein klares Gegenstück in der KumoMTA-Policy, und wir übernehmen die Übersetzung.

Dasselbe gilt in die andere Richtung: Entscheiden Sie sich später zu gehen, machen wir es Ihnen nicht schwer. KumoMTA läuft mit Standard-Software auf Ihrem Host, ohne proprietäre Formate oder APIs, die Sie binden, also ist es eine Sache von Stunden, Ihre Konfiguration und Ihre Daten zu einem anderen Anbieter mitzunehmen, kein technisches Geiselverhältnis. Wir bauen die Beziehung darauf, dass sich das Bleiben lohnt, nicht darauf, wie teuer das Gehen ist.