Der Friedhof der E-Mail-Startups: Warum die meisten E-Mail-Startups scheitern

 (forwardemail.net)
2 Punkte von GN⁺ 2025-08-25 | 6 Kommentare | Auf WhatsApp teilen

Matrix des Scheiterns von E-Mail-Startups

  • Viele E-Mail-Startups setzten lediglich eine einfache UI auf bestehende Infrastruktur wie Amazon SES oder Postfix auf.
  • Skiff, Sparrow, Email Copilot, ReplySend, Nveloped, Jumble und InboxFever sind alle gescheitert oder wurden nach einer Übernahme eingestellt.
  • Die meisten von YC und Techstars hervorgebrachten E-Mail-Startups pivotierten oder wurden frühzeitig eingestellt.
  • Dienste, die keine eigene Infrastruktur aufbauen konnten, überlebten nur kurzfristig.

Realitätscheck der Infrastruktur

  • Die meisten E-Mail-Startups entwickelten keine tatsächlichen Server, sondern nur Apps oder Clients.
  • Erfolgreiche Unternehmen boten SMTP-APIs und Zustellinfrastruktur wie SendGrid, Mailgun, Postmark an.
  • Erfolgreich war meist nicht der Versuch, Protokolle zu verändern, sondern bestehende Workflows zu verbessern.

Warum die meisten E-Mail-Startups scheitern

  • 1. Das Protokoll funktioniert gut, aber die Implementierung ist schwierig

    • SMTP, IMAP und POP3 sind seit Jahrzehnten erprobt.
    • Das Problem ist nicht ein neues Protokoll, sondern die Qualität der Implementierung.

  • 2. Netzwerkeffekte sind absolut

    • E-Mail wird von mehr als 4 Milliarden Menschen genutzt und ist mit allen Plattformen kompatibel.
    • Die Wechselkosten sind hoch, weshalb ein Umstieg auf andere Dienste schwierig ist.

  • 3. Es wird das falsche Problem adressiert

    • „E-Mail ist komplex“, „AI wird gebraucht“, „Sicherheit ist schwach“ – das sind falsche Annahmen.
    • Die tatsächlich wichtigen Probleme sind Zustellstabilität, Spam-Filterung und Entwickler-Tools.

  • 4. Die technische Schuld ist groß

    • Der Betrieb von SMTP-Servern, der Umgang mit Spam, Massenspeicher sowie Authentifizierungs- und Zustellinfrastruktur sind alle schwer aufzubauen.

  • 5. Die Infrastruktur existiert bereits

    • Mit Amazon SES, Postfix, Dovecot, SpamAssassin und anderen gibt es reichlich Open-Source- und kommerzielle Infrastruktur.

Fallstudien zum Scheitern von E-Mail-Startups

  • Fall Skiff

    • Als „Privacy-first E-Mail- und Produktivitätsplattform“ positioniert, konnte das Unternehmen beträchtliches Venture-Capital einwerben.
    • Im Februar 2024 übernahm Notion Skiff und versprach Integration sowie kontinuierliche Weiterentwicklung.
    • Tatsächlich wurde der Dienst nur wenige Monate nach der Übernahme sofort eingestellt, und die Gründer verließen Notion, um zu Cursor zu wechseln.
    • Tausende Nutzer wurden zu einer erzwungenen Migration gezwungen.

  • Analyse nach Accelerator

    • Y Combinator: E-Mail-App-Fabrik

      • Emailio (2014): mobiler E-Mail-Client → Pivot in Richtung Wellness
      • MailTime (2016): chatartiges E-Mail-System → Pivot zu einem Analysedienst
      • reMail (2009): E-Mail-Suche fürs iPhone → von Google übernommen und danach eingestellt
      • Rapportive (2012): soziale Gmail-Profile → von LinkedIn übernommen und danach eingestellt
      • Erfolgsquote: Es gab einige erfolgreiche Übernahmen (reMail, Rapportive), doch viele endeten mit einem Pivot oder als Acqui-hire.

    • Techstars: E-Mail-Friedhof

      • Email Copilot (2012): nach Übernahme eingestellt
      • ReplySend (2012): kompletter Fehlschlag
      • Nveloped (2012): „Easy. Secure. Email“ → gescheitert
      • Jumble (2015): E-Mail-Verschlüsselungsdienst → gescheitert
      • InboxFever (2011): E-Mail-API → gescheitert
      • Muster: vages Nutzenversprechen, fehlende echte technische Innovation, schnelles Scheitern

  • Die Falle des Venture Capital

    • VC Funding Paradox: E-Mail-Startups wirken einfach, sind in Wirklichkeit aber nahezu unmöglich.
    • Schon die Prämisse, mit der Investoren angelockt werden, ist so aufgebaut, dass sie Scheitern begünstigt.
    • Realität: E-Mail-Infrastruktur und -Protokolle sind bereits robust; es ist für neue Startups unmöglich, sie zu ersetzen.

Die technische Realität des modernen E-Mail-Stacks

  • Die meisten E-Mail-Startups bauen keine eigene Infrastruktur neu auf, sondern setzen Client-Anwendungen auf bestehende E-Mail-Server und -Protokolle auf.

  • Dadurch treten grundlegende Einschränkungen und Leistungsprobleme immer wieder auf und bilden eine wichtige Ursache für das Scheitern dieser Startups.

  • Überhöhter Speicherverbrauch (Memory Bloat)

    • Moderne E-Mail-Clients werden meist als Electron-basierte Web-Apps gebaut und verbrauchen übermäßig viel RAM.
    • Mailspring: bereits für grundlegende E-Mail-Funktionen 500MB+ Speicherverbrauch
    • Nylas Mail: vor der Einstellung 1GB+ Speicherverbrauch
    • Postbox: selbst im Leerlauf 300MB+ belegt
    • Canary Mail: häufige Abstürze aufgrund von Speicherproblemen
    • Thunderbird: Berichte über Nutzung von bis zu 90 % des Systemspeichers
    • Electron-Leistungskrise:
      • Cross-Platform-Frameworks wie Electron und React Native sind für Entwickler praktisch, nutzen Ressourcen aber ineffizient.
      • Das führt dazu, dass selbst einfache E-Mail-Funktionen Hunderte MB bis mehrere GB an Speicher verschlingen.

  • Akkuverbrauch (Battery Drain)

    • Durch ineffizienten Code und ineffiziente Arbeitsweisen ist der Akkuverbrauch auf Mobilgeräten und Laptops erheblich.
    • Hintergrundprozesse bleiben dauerhaft aktiv.
    • Unnötige API-Aufrufe erfolgen alle paar Sekunden.
    • Das Verbindungsmanagement ist ineffizient.
    • Selbst ohne unnötige Drittanbieter-Abhängigkeiten jenseits der Kernfunktionen ist die Ressourcenverschwendung erheblich.

Übernahmemuster: Erfolg vs. Misserfolg

  • Zwei Muster

    • Client-App-Muster (meist erfolglos)
      • E-Mail-Client-Anwendungen werden nach einer Übernahme in der Regel schnell eingestellt.
      • Sie werben zwar mit einer neuen User Experience, können aber weder die Infrastrukturabhängigkeit noch die Hürden der Netzwerkeffekte überwinden und sind daher nicht nachhaltig.
    • Infrastrukturmuster (oft erfolgreich)
      • Unternehmen, die zentrale E-Mail-Infrastruktur wie SMTP oder APIs bereitstellen, wachsen nach einer Übernahme oft weiter oder werden erfolgreich in Plattformen integriert.

  • Jüngste Beispiele

    • Scheitern von Client-Apps

      • Mailbox → Dropbox → Shutdown (2013–2015)
      • Sparrow → Google → Shutdown (2012–2013)
      • reMail → Google → Shutdown (2010–2011)
      • Skiff → Notion → Shutdown (2024)

    • Ausnahmehafter Erfolg

      • Superhuman → Grammarly (2025)
        • Ein erfolgreicher Übernahmefall durch strategische Integration; im Bereich der E-Mail-Clients ein seltener erfolgreicher Exit.

    • Erfolg bei Infrastruktur

      • SendGrid → Twilio (2019): Übernahme im Volumen von 3 Milliarden Dollar, danach weiter gewachsen
      • Mailgun → Sinch (2021): durch strategische Übernahme integriert
      • Postmark → ActiveCampaign (2022): trug zur Erweiterung der Plattformfunktionen bei
  • Während Client-Apps nach Übernahmen oft im Shutdown enden, zeigt sich deutlich die Tendenz, dass Infrastruktur-Anbieter auch nach Übernahmen überleben und zu Kernelementen von Plattformen werden.

Entwicklung und Konsolidierung der Branche

  • Natürliche Branchenentwicklung

    • Die E-Mail-Branche hat sich im Lauf der Zeit in einer Form entwickelt, bei der große Unternehmen kleinere Firmen übernehmen, um Funktionen zu integrieren oder Wettbewerb auszuschalten.
    • Das ist nicht nur ein negatives Phänomen, sondern ein natürlicher Entwicklungsprozess, wie er in den meisten reifen Branchen zu beobachten ist.

  • Veränderungen nach Übernahmen

    Wenn E-Mail-Unternehmen übernommen werden, erleben Nutzer typischerweise folgende Veränderungen:
    • Service-Migration: Konten und Daten müssen auf eine neue Plattform übertragen werden.
    • Funktionsänderungen: Spezialisierte Funktionen verschwinden oder werden in anderer Form ersetzt.
    • Preisanpassungen: Abomodelle und Tarife können sich ändern.
    • Unannehmlichkeiten während der Integration: Während der Service-Integration kann es zu vorübergehenden Störungen oder Unterbrechungen kommen.

  • Was Nutzer in der Übergangsphase beachten sollten

    Reaktionsmöglichkeiten für Nutzer in einer Phase der Branchenkonsolidierung:
    • Alternative Dienste prüfen: andere Anbieter mit ähnlichen Funktionen erkunden
    • Migrationspfade verstehen: Die meisten Dienste bieten Export-Tools an, die genutzt werden sollten.
    • Langfristige Stabilität berücksichtigen: Es ist vorteilhaft, Anbieter zu wählen, die seit Langem am Markt sind und als zuverlässig gelten.

Realitätscheck auf Hacker News

Alle E-Mail-Startups erhalten auf Hacker News immer wieder dasselbe Feedback:

Der aktuelle Boom der AI-E-Mail-Startups

  • Die jüngste Welle

    2024 entstand eine neue Welle von Startups rund um "AI-basierte E-Mail", und bereits die erste größere erfolgreiche Übernahme hat stattgefunden:
    • Superhuman: insgesamt 33 Millionen US-Dollar Finanzierung, 2025 von Grammarly übernommen — eine Client-App-Übernahme, die als seltener Erfolg gilt
    • Shortwave: ein Wrapper auf Basis von Gmail mit AI-Zusammenfassungen
    • SaneBox: AI-basierte E-Mail-Filterung, die tatsächlich funktioniert, aber nicht revolutionär ist

  • Die weiterhin bestehenden Probleme

    Auch mit dem Label "AI" werden die grundlegenden Probleme von E-Mail nicht gelöst:
    • AI-Zusammenfassungen: Die meisten E-Mails sind bereits kurz und knapp
    • Intelligente Antworten: Gmail bietet das bereits seit Jahren an
    • Geplantes Senden von E-Mails: Outlook unterstützt das standardmäßig
    • Prioritätserkennung: In bestehenden E-Mail-Clients gibt es bereits effektive Filtersysteme
      Die harte Realität: AI-Funktionen sind keine grundlegende Lösung, weil sie in der Praxis gewaltige Infrastrukturinvestitionen erfordern, obwohl sie nur vergleichsweise kleine Unannehmlichkeiten lösen

Tatsächlich erfolgreiche Beispiele im E-Mail-Bereich

  • Infrastrukturunternehmen (erfolgreiche Fälle)

  • E-Mail-Dienstanbieter (die Überlebenden)

    • FastMail: seit über 25 Jahren in Betrieb, profitables unabhängiges Unternehmen
      • Kontroverse um die JMAP-Investitionen: Fastmail investierte Ressourcen in das JMAP-Protokoll, das auch nach mehr als zehn Jahren nur wenig Verbreitung gefunden hat, und lehnte zugleich die von vielen Nutzern gewünschte PGP-Verschlüsselung ab. Das wird als strategische Entscheidung bewertet, Protokollinnovation höher zu priorisieren als Nutzeranforderungen. Die meisten E-Mail-Clients sind weiterhin auf IMAP/SMTP angewiesen
    • ProtonMail: auf Datenschutz fokussiert, mit nachhaltigem Wachstum
    • Zoho Mail: als Teil einer großen Business-Produkt-Suite stabil betrieben
    • Forward Email(We): seit über 7 Jahren in Betrieb und zugleich profitabel und wachsend
    • Erfolgsfall im Unternehmensbereich: Forward Email unterstützt eine E-Mail-Lösung für 30.000 Alumni der Universität Cambridge und ermöglicht so Einsparungen von 87.000 US-Dollar pro Jahr
    • Muster: Diese Anbieter ersetzen E-Mail nicht, sondern stärken sie.

  • Außergewöhnlicher Erfolgsfall: Xobni

    Xobni war ein selten erfolgreiches Startup, weil es die bestehende E-Mail-Umgebung verbessert hat.
    • Die richtige Strategie:
      • Auf bestehender E-Mail aufgebaut: Integration mit Outlook
      • Reale Probleme gelöst: Kontaktmanagement und E-Mail-Suche verbessert
      • Integrationsorientiert: Funktionierte innerhalb bestehender Workflows
      • Enterprise-Fokus: Zielmarkt waren Unternehmen, die für Produktivitätssteigerung bezahlen
    • Ergebnis: 2013 von Yahoo für 60 Millionen US-Dollar übernommen und bot Investoren eine nennenswerte Rendite.
    • Spätere Erfolge der Gründer:
      • Matt Brezina: aktiver Angel-Investor, investierte in Dropbox, Mailbox und andere
      • Adam Smith: gründete weiterhin erfolgreich Unternehmen im Produktivitätsbereich
      • Beide Gründer bewiesen, dass "Erfolg bei E-Mail nicht durch Ersatz, sondern durch Verbesserung entsteht"

  • Erfolgsmuster

    Die Gemeinsamkeiten erfolgreicher Unternehmen im E-Mail-Bereich:
    • 1. Infrastruktur aufbauen → SendGrid, Mailgun
    • 2. Bestehende Workflows stärken → Xobni, FastMail
    • 3. Auf Zuverlässigkeit fokussieren → Amazon SES, Postmark
    • 4. Entwickler unterstützen → APIs und Tools bereitstellen, keine Endnutzer-Apps

Gibt es Beispiele dafür, dass E-Mail erfolgreich neu erfunden wurde?

Diese Frage ist wichtig, weil sie das Wesen von Innovation bei E-Mail auslotet.
Die kurze Antwort lautet: Niemandem ist es gelungen, E-Mail zu ersetzen, aber es gibt erfolgreiche Fälle, in denen E-Mail ‚gestärkt‘ wurde.

  • Innovationen, die sich tatsächlich durchgesetzt haben

    Die Innovationen, die sich in den vergangenen 20 Jahren bei E-Mail etabliert haben, haben allesamt die bestehenden Protokolle nicht ersetzt, sondern gestärkt:

  • Tools, die E-Mail ergänzen statt ersetzen

    • Slack: ein Team-Chat-Tool, verschickt aber weiterhin E-Mail-Benachrichtigungen
    • Discord: eine Community-zentrierte Plattform, deren Kontoverwaltung aber auf E-Mail basiert
    • WhatsApp: für Messaging optimiert, doch Unternehmen nutzen weiterhin E-Mail
    • Zoom: ein unverzichtbares Tool für Videokonferenzen, aber Meeting-Einladungen werden per E-Mail verschickt

  • Das HEY-Experiment

    HEY von Basecamp war zuletzt der ernsthafteste Versuch, E-Mail „neu zu erfinden“.
    • Launch: 2020, begleitet von massiver PR
    • Ansatz: ein neues E-Mail-Paradigma mit Screening, Bundling und Workflows
    • Reaktion: Einige waren begeistert, die Mehrheit blieb jedoch bei der bestehenden E-Mail-Nutzung
    • Realität: Letztlich war es weiterhin nur eine neue Oberfläche für SMTP/IMAP-basierte E-Mail
    • Empirisches Beispiel: Gründer DHH nutzt seit Jahren Forward Email auf seiner persönlichen Domain dhh.dk. Das zeigt, dass selbst E-Mail-Innovatoren auf bewährte Infrastruktur angewiesen sind.

  • Was tatsächlich funktioniert

    Die erfolgreichsten E-Mail-Innovationen sind:
    • 1. Bessere Infrastruktur: schnellere Server, verbesserte Spam-Filterung, höhere Zustellraten
    • 2. Verbesserte Interfaces: Gmails Konversationsansicht, Outlooks Kalender-Integration
    • 3. Entwickler-Tools: APIs zum E-Mail-Versand, Webhooks für Tracking
    • 4. Spezialisierte Workflows: CRM-Integrationen, Marketing-Automatisierung, transaktionale E-Mails

Fazit: Bis heute hat keine Innovation E-Mail ersetzt; erfolgreich waren sie alle in der Richtung, E-Mail besser zu machen

Aufbau moderner Infrastruktur für bestehende E-Mail-Protokolle: unser Ansatz bei Forward Email

Bevor wir auf gescheiterte Beispiele eingehen, ist es wichtig zu verstehen, was bei E-Mail tatsächlich funktioniert
Nicht E-Mail selbst ist kaputt, sondern viele Unternehmen verursachen Probleme, indem sie versuchen, ein bereits gut funktionierendes System zu „reparieren“

  • Das Spektrum der E-Mail-Innovation

    E-Mail-Innovation lässt sich grob in drei Kategorien einteilen:
    • 1. Protokoll-Verbesserung: Standards wie SMTP, IMAP und POP3 stabiler und schneller implementieren
    • 2. Workflow-Optimierung: Tools und Funktionen, die bestehende E-Mail-Abläufe effizienter machen
    • 3. UI/UX-Innovation: bessere Zugänglichkeit und Nutzbarkeit durch neue Interfaces

  • Warum wir uns auf Infrastruktur konzentrieren

    Statt eine neue App zu bauen, haben wir uns entschieden, moderne E-Mail-Infrastruktur aufzubauen. Die Gründe dafür sind:
    • Bewährte E-Mail-Protokolle: SMTP funktioniert seit 1982 zuverlässig
    • Das Problem ist die Qualität der Implementierung: Viele E-Mail-Dienste nutzen noch immer veraltete Software-Stacks
    • Was Nutzer wollen = Zuverlässigkeit: keine neuen Features, sondern stabile Workflows, die nicht kaputtgehen
    • Bedarf bei Entwicklern: bessere APIs und Verwaltungsoberflächen werden benötigt

  • Was bei E-Mail tatsächlich funktioniert

    Das erfolgreiche Muster ist einfach: bestehende E-Mail-Workflows nicht ersetzen, sondern stärken
    • Aufbau schnellerer und zuverlässigerer SMTP-Server
    • bessere Spam-Filterung, ohne legitime E-Mails zu stören
    • Bereitstellung entwicklerfreundlicher APIs, die bestehende Protokolle nutzen können
    • Verbesserung der Zustellrate durch die richtige Infrastruktur
      Fazit: Innovation bei E-Mail bedeutet nicht „Ersatz“, sondern, das bestehende System durch Infrastruktur besser zu machen

Unser Ansatz: Warum Forward Email anders ist

  • Was wir tun (What We Do)

    • Reale Infrastruktur aufbauen: SMTP/IMAP-Server von Grund auf selbst entwickeln
    • Fokus auf Zuverlässigkeit: 99,99 % Uptime und korrektes Error-Handling
    • Bestehende Workflows stärken: kompatibel mit allen E-Mail-Clients und zuverlässig im Betrieb
    • Unterstützung für Entwickler: APIs und Tools bereitstellen, die tatsächlich nutzbar sind
    • Vollständige Kompatibilität wahren: vollständige Einhaltung der Standards SMTP / IMAP / POP3

  • Was wir nicht tun (What We Don’t Do)

    • Entwicklung eines neuen E-Mail-Clients im Namen der „Innovation“
    • Versuch, bestehende E-Mail-Protokolle zu ersetzen
    • Hinzufügen unnötiger AI-Funktionen
    • unrealistische Versprechen, E-Mail „reparieren“ zu wollen
      Im Kern geht es darum, Zuverlässigkeit und Kompatibilität auf bewährten Protokollen zu erhöhen, und sich statt auf Show-Innovation auf Infrastruktur zu konzentrieren, die tatsächlich funktioniert.

Wie wir eine tatsächlich funktionierende E-Mail-Infrastruktur aufgebaut haben

  • Unser Anti-Startup-Ansatz (Our Anti-Startup Approach)

    Während andere Unternehmen Millionen von Dollar verbrannten, um E-Mail neu zu erfinden, haben wir uns einfach auf den Aufbau zuverlässiger Infrastruktur konzentriert:
    • Kein Pivot: Seit über 7 Jahren ausschließlich auf E-Mail-Infrastruktur fokussiert
    • Keine Exit-Strategie durch Übernahme: Langfristiger Betrieb statt kurzfristigem Verkauf
    • Kein Innovations-Hype: E-Mail nicht „reparieren“, sondern dafür sorgen, dass sie besser funktioniert

  • Was uns unterscheidet (What Makes Us Different)

    • Erfüllung staatlicher Standards: Section 889 konform, mit institutionellen Kunden wie der United States Naval Academy
    • OpenPGP + OpenWKD-Unterstützung: Unterstützung für PGP-Verschlüsselung, die Fastmail abgelehnt hat, und damit echte Verschlüsselungsfunktionen, die Nutzer wollen
    • Differenzierter Technologie-Stack:
      • Der gesamte Stack ist in JavaScript entwickelt (im Gegensatz zu Postfix auf Basis von C-Code aus den 1980ern)
      • Kein Glue Code nötig dank einer einzigen Sprache
      • Web-native Architektur mit hoher Wartbarkeit
      • Keine Legacy-Schulden, moderne Codebasis
    • Privacy by Design:
      • E-Mails werden nicht auf Festplatten oder in Datenbanken gespeichert
      • Keine Speicherung von Metadaten, Logs oder IP-Adressen
      • Verarbeitung beim Weiterleiten ausschließlich im Arbeitsspeicher
    • Über das Technical Whitepaper und die Dokumentation werden Sicherheits- und Architekturdetails offengelegt

  • Warum wir Erfolg haben, wo andere scheitern (Why We Succeed Where Others Fail)

    • 1. Wir bauen Infrastruktur, keine App: Fokus auf Server und Protokolle
    • 2. Verbessern statt ersetzen: Kompatibilität mit bestehenden E-Mail-Clients bleibt erhalten
    • 3. Aus eigener Kraft profitabel: Nachhaltiger Betrieb ohne VC-Druck
    • 4. Tiefes technisches Verständnis: Mehr als 7 Jahre spezialisierte Erfahrung mit E-Mail
    • 5. Entwicklerzentriert: APIs und Tools, die bei der Lösung realer Probleme helfen

Die Sicherheitsherausforderungen der E-Mail-Infrastruktur

E-Mail-Sicherheit ist eine komplexe Herausforderung, mit der jeder Dienstanbieter konfrontiert ist.
Wichtiger als einzelne Vorfälle ist es, die gemeinsamen Sicherheitsaspekte zu verstehen, die überall gelöst werden müssen.

  • Gemeinsame Sicherheitsaspekte (Common Security Considerations)

    • Datenschutz: Schutz von Nutzerdaten und Kommunikation
    • Zugriffskontrolle: Authentifizierung und Rechteverwaltung
    • Infrastruktursicherheit: Absicherung von Servern und Datenbanken
    • Compliance: Einhaltung von Vorschriften wie GDPR und CCPA
    • Einsatz fortschrittlicher Verschlüsselung: Sicherheitsrichtlinie von Forward Email:
      • Mailbox-Verschlüsselung auf Basis von ChaCha20-Poly1305
      • Vollständige Festplattenverschlüsselung auf Basis von LUKS v2
      • Verschlüsselung im Speicher, bei der Übertragung und im Ruhezustand

  • Der Wert von Transparenz (The Value of Transparency)

    Im Fall eines Sicherheitsvorfalls sind Transparenz und schnelles Handeln die wichtigste Reaktion. Zu den Best Practices gehören:
    • Sofortige Offenlegung: Damit Nutzer die Situation verstehen und reagieren können
    • Detaillierte Zeitleiste: Zeigt Umfang des Problems und Stand des Verständnisses
    • Schnelle Gegenmaßnahmen: Belegt technische Handlungsfähigkeit
    • Geteilte Erkenntnisse: Trägt zur Verbesserung der Sicherheit in der gesamten Branche bei

  • Fortlaufende Sicherheitsherausforderungen (Ongoing Security Challenges)

    E-Mail-Sicherheit entwickelt sich ständig weiter, und in den folgenden Bereichen sind kontinuierliche Verbesserungen nötig:
    • Verschlüsselungsstandards: Einsatz moderner Verfahren wie TLS 1.3
    • Authentifizierungsprotokolle: Stärkung von DKIM, SPF und DMARC
    • Bedrohungserkennung: Bessere Spam- und Phishing-Filterung
    • Härtung der Infrastruktur: Mehr Sicherheit für Server und Datenbanken
    • Verwaltung der Domain-Reputation: Einführung von Blockierungsregeln zur Abwehr neuer Bedrohungen wie dem starken Anstieg von Spam über Microsoft-onmicrosoft.com-Adressen

Fazit: Konzentriere dich auf Infrastruktur, nicht auf Apps

  • Die Belege sind eindeutig (The Evidence Is Clear)

    Die Analyse von Hunderten E-Mail-Startups zeigt:
    • Ausfallquote von über 80 %: Die meisten E-Mail-Startups scheitern vollständig (die tatsächliche Zahl dürfte noch höher liegen)
    • Client-Apps scheitern meist: Übernahmen führen oft direkt zur Einstellung des Dienstes
    • Infrastruktur hat Erfolgschancen: Unternehmen, die SMTP/API-Dienste aufbauen, florieren häufig
    • Druck durch VC-Finanzierung: Venture-Kapital erzeugt unrealistischen Wachstumsdruck
    • Anhäufung technischer Schulden: Der Aufbau von E-Mail-Infrastruktur ist viel schwieriger als erwartet

  • Der historische Kontext (The Historical Context)

    In den vergangenen 20 Jahren haben Startups immer wieder das Ende der E-Mail vorhergesagt:
    • 2004: „Soziale Netzwerke werden E-Mail ersetzen“
    • 2008: „Mobiles Messaging wird E-Mail töten“
    • 2012: „Slack wird E-Mail ersetzen“
    • 2016: „AI wird E-Mail revolutionieren“
    • 2020: „Im Zeitalter der Remote-Arbeit braucht es neue Kommunikationstools“
    • 2024: „AI wird E-Mail endlich reparieren“
      Doch E-Mail existiert weiterhin, wächst und bleibt unverzichtbar.

  • Die eigentliche Lehre (The Real Lesson)

    Die Lehre ist nicht, dass E-Mail nicht verbessert werden kann, sondern dass der richtige Ansatz gewählt werden muss:
    • 1. E-Mail-Protokolle sind tragfähig: SMTP, IMAP und POP3 sind bewährte Standards
    • 2. Infrastruktur ist entscheidend: Zuverlässigkeit und Leistung sind wichtiger als auffällige Funktionen
    • 3. Verbessern statt ersetzen: Keine Konfrontation mit E-Mail, sondern Lösungen, die mit ihr zusammenarbeiten
    • 4. Nachhaltigkeit vor Wachstum: Profitabele Unternehmen überleben länger als das VC-getriebene Modell „schnell wachsen und kaputtmachen“
    • 5. Unterstützung für Entwickler: Tools und APIs für Entwickler schaffen mehr Wert als Endnutzer-Apps
    • Die zentrale Chance: Bereits bewährte Protokolle besser umzusetzen, statt neue Protokolle zu entwickeln
    • Vertiefende Analyse: 79 Best Email Services (2025)
  • Wenn du ein E-Mail-Startup gründen willst, solltest du erwägen, Infrastruktur statt Apps zu bauen.
    • Was die Welt braucht, sind nicht mehr E-Mail-Apps, sondern bessere E-Mail-Server.

Der erweiterte E-Mail-Friedhof: noch mehr Fehlschläge und Diensteinstellungen

  • Googles gescheiterte E-Mail-Experimente (Google's Email Experiments Gone Wrong)

    Obwohl Google Gmail besitzt, hat das Unternehmen mehrere E-Mail-Projekte eingestellt:
    • Google Wave (2009–2012): Wurde als „E-Mail-Killer“ bezeichnet, aber niemand verstand es
    • Google Buzz (2010–2011): Versuch einer sozialen E-Mail-Integration, gescheitert
    • Inbox by Gmail (2014–2019): Als „smarter“ Nachfolger von Gmail gestartet, am Ende jedoch eingestellt
    • Google+ (2011–2019): Versuch, E-Mail-Funktionen zu integrieren, gescheitert
    • Muster: Selbst Google mit Gmail konnte E-Mail nicht erfolgreich neu erfinden

  • Newton Mail und sein dreifacher Tod (The Serial Failure: Newton Mail's Three Deaths)

    Newton Mail starb ganze dreimal:
    • 1. CloudMagic (2013–2016): Früher E-Mail-Client, später von Newton übernommen
    • 2. Newton Mail (2016–2018): Marken-Relaunch, wegen gescheitertem Abo-Modell eingestellt
    • 3. Newton Mail Revival (2019–2020): Wiederbelebungsversuch, erneut gescheitert
    • Lehre: E-Mail-Clients können ein Abo-Modell nicht dauerhaft tragen

  • Apps, die nie gestartet sind (The Apps That Never Launched)

    Viele E-Mail-Startups verschwinden noch vor dem Launch:
    • Tempo (2014): Versuch einer Kalender-E-Mail-Integration, vor dem Start eingestellt
    • Mailstrom (2011): E-Mail-Management-Tool, vor dem Start übernommen
    • Fluent (2013): E-Mail-Client, Entwicklung eingestellt

  • Das Muster Übernahme und dann Abschaltung (The Acquisition-to-Shutdown Pattern)

    Mehrere E-Mail-Apps wurden kurz nach einer Übernahme eingestellt:

  • Konsolidierung der E-Mail-Infrastruktur (Email Infrastructure Consolidation)

    Auch im Infrastruktur-Bereich sind Konsolidierung und Abschaltungen häufig:

Der Open-Source-E-Mail-Friedhof: wenn „kostenlos“ nicht tragfähig ist

  • Nylas Mail → Mailspring: ein gescheiterter Fork

  • Eudora: ein 18 Jahre langer Todesmarsch

    • 1988–2006: Dominierender E-Mail-Client auf Mac und Windows
    • 2006: Qualcomm kündigt das Ende der Entwicklung an
    • 2007: Als „Eudora OSE“ Open Source gemacht
    • 2010: Projekt vollständig eingestellt
    • Lehre: Selbst erfolgreiche E-Mail-Clients verschwinden irgendwann

  • FairEmail: von den Google-Play-Richtlinien getötet

    • FairEmail: Datenschutzorientierter Android-E-Mail-Client
    • Google Play: Wegen „Richtlinienverstoß“ entfernt
    • Realität: Durch Plattformrichtlinien können E-Mail-Apps von einem Tag auf den anderen verschwinden

  • Das Wartungsproblem (The Maintenance Problem)

    Warum Open-Source-E-Mail-Projekte scheitern:
    • Komplexität: E-Mail-Protokolle korrekt zu implementieren ist schwierig
    • Sicherheit: Ständige Sicherheitsupdates sind nötig
    • Kompatibilität: Sie müssen mit allen E-Mail-Anbietern kompatibel sein
    • Ressourcenmangel: Ehrenamtliche Entwickler leiden unter Burnout

Der Boom der KI-E-Mail-Startups: Wiederholte Geschichte unter dem Namen „Intelligenz“

  • Der aktuelle KI-E-Mail-Goldrausch (2024)

  • Der Finanzierungsrausch

    • Allein 2024 investierten VCs über 100 Mio. US-Dollar
    • Das sich wiederholende Versprechen: „ein revolutionäres E-Mail-Erlebnis“
    • Das sich wiederholende Problem: Es wird nur auf bestehender Infrastruktur aufgebaut
    • Das sich wiederholende Ergebnis: Die meisten werden voraussichtlich innerhalb von 3 Jahren scheitern

  • Warum sie wieder scheitern werden

    • 1. KI versucht ein „Nicht-Problem“ von E-Mail zu lösen – E-Mail funktioniert bereits gut
    • 2. Gmail bietet bereits KI-Funktionen – Smart Reply, Priorisierter Posteingang, Spam-Filterung
    • 3. Datenschutzbedenken – KI muss alle E-Mails lesen
    • 4. Problematische Kostenstruktur – KI-Verarbeitung ist teuer, E-Mail ist im Kern ein Niedrigpreis-Dienst
    • 5. Netzwerkeffekte – Die dominante Stellung von Gmail/Outlook lässt sich nicht brechen

  • Das unvermeidliche Ergebnis

    • 2025: Superhuman → Übernahme durch Grammarly (seltener Erfolgsfall)
    • 2025–2026: Die meisten KI-E-Mail-Startups werden pivotieren oder schließen
    • 2027: Einige überlebende Unternehmen werden übernommen, aber mit gemischtem Erfolg
    • 2028: Es könnte ein neuer Hype wie „Blockchain-E-Mail“ auftauchen

Die Katastrophe der Konsolidierung: Wenn „Überlebende“ zur Katastrophe werden

  • Konsolidierung großer E-Mail-Dienste

    Die E-Mail-Branche hat sich stark konsolidiert

  • Outlook: Der „Überlebende“ mit nicht endenden Problemen

    Microsoft Outlook ist weiterhin Mainstream in der Branche, verursacht aber fortlaufend Probleme
    • Speicherlecks: mehrere GB RAM-Nutzung, häufige Neustarts erforderlich
    • Synchronisierungsprobleme: E-Mails verschwinden und tauchen dann wieder auf
    • Leistungsprobleme: langsamer Start, häufige Abstürze
    • Kompatibilitätsprobleme: Konflikte mit E-Mail-Anbietern von Drittanbietern

    Praxisbeispiel: Obwohl die Standard-IMAP-Implementierung eingehalten wird, geht Outlook häufig kaputt

  • Probleme mit der Postmark-Infrastruktur

    Probleme, die nach der Übernahme durch ActiveCampaign auftraten

  • Jüngste Todesfälle bei E-Mail-Clients (2024–2025)

    • Postbox → eM Client: direkt nach der Übernahme sofort eingestellt, erzwungene Migration der Nutzer
    • Canary Mail: trotz Unterstützung durch Sequoia massive Nutzerbeschwerden
    • Spark by Readdle: zunehmende Berichte über Qualitätsverlust
    • Mailbird: Lizenzprobleme und Verwirrung um Abonnements
    • Airmail: auf Sparrow-Code basierend, anhaltende Zuverlässigkeitsprobleme

  • Fälle von E-Mail-Erweiterungen/Dienstabschaltungen

  • E-Mail-Unternehmen, die tatsächlich überlebt haben

    • Mailmodo: aus YC, interaktive E-Mail-Kampagnen, 2 Mio. US-Dollar Finanzierung von Sequoia Surge
    • Mixmax: insgesamt 13,3 Mio. US-Dollar Finanzierung, weiterhin als Sales-Engagement-Plattform aktiv
    • Outreach.io: Bewertung von über 4,4 Mrd. US-Dollar, bereitet sich auf IPO vor
    • Apollo.io: 2023 mit 1,6 Mrd. US-Dollar bewertet, 100 Mio. US-Dollar Series D aufgenommen
    • GMass: auf Gmail-Erweiterung basierend, gebootstrapptes Erfolgsbeispiel mit 140.000 US-Dollar Monatsumsatz
    • Streak CRM: Gmail-basiertes CRM, seit 2012 stabil im Betrieb
    • ToutApp: 2017 erfolgreich von Marketo übernommen
    • Bananatag: 2021 von Staffbase übernommen, wird als „Staffbase Email“ weitergeführt

  • Das Kernmuster

    • Erfolgreiche Unternehmen ersetzen E-Mail nicht, sondern verbessern den Workflow
    • Sie haben Tools gebaut, die kooperativ mit der E-Mail-Infrastruktur arbeiten

Fazit

  • Mehr als 80 % der E-Mail-Startups scheitern
  • App-zentrierte Ansätze scheitern, infrastrukturzentrierte Ansätze sind erfolgreich
  • Zentrale Lehren:
    • 1. E-Mail-Protokolle funktionieren bereits gut
    • 2. Stabilität und Performance der Infrastruktur sind entscheidend
    • 3. Verstärken statt Ersetzen ist effektiver
    • 4. Ein nachhaltiges Geschäftsmodell ist notwendig
    • 5. Tools und APIs für Entwickler sind der Schlüssel zum Erfolg

Verwandte Beiträge

6 Kommentare

 
princox 2025-08-25

Ich habe nur bis zur Mitte gelesen und mich dann gefragt: Gibt es nicht auch ein Beispiel mit hey.com? Und genau das taucht sofort im Text auf, haha.
E-Mail als Produkt scheint immer unendlich viel Potenzial zu haben und zugleich ein Markt zu sein, in dem es schwer ist, den etablierten Playern ihre Position streitig zu machen..
 
bungker 2025-08-25

Sobald man so etwas aufgebaut hat, wird der Server von allen möglichen Stellen als Spam-Mailserver eingestuft, und die Freischaltung davon ist dann die eigentliche Arbeit. Wenn Kunden sich plötzlich melden und sagen, dass es nicht funktioniert, liegt es meistens daran, dass der Server als Spam-Server registriert wurde.
 
nemorize 2025-08-25

Es ist noch ein zu kleines Produkt, um schon von Erfolg oder Misserfolg zu sprechen,
aber ich nutze einen Gmail-Client namens Mimestream mit großer Freude und bin sehr zufrieden damit.

https://mimestream.com/

Von allen Mail-Clients, die ich bisher verwendet habe, bin ich mit diesem am zufriedensten ... ich habe schon in der Beta damit angefangen und nutze ihn jetzt seit fast fünf Jahren.
 
t7vonn 2025-08-25

Hm … im Abschnitt „The Hacker News Reality Check“ sind die Links alle irgendwie kaputt. Offenbar waren schon im Original seltsame Links gesetzt.
 
xguru 2025-08-25

Ach so, stimmt. Selbst wenn man nach dem Original sucht, ist es schwer zu finden, daher sollte man es wohl einfach so lassen.
 
GN⁺ 2025-08-25
Hacker-News-Kommentare
  • Ich war der 12. Ingenieur bei SendGrid und habe das Unternehmen nach dem IPO und der Übernahme durch Twilio verlassen. Ich war für die Infrastruktur zuständig und habe als Grundlage für mehrere E-Mail-Marketing-Unternehmen gearbeitet, was gute Ergebnisse brachte. Das Geschäft wuchs wie beim Verkauf von Schaufeln im Goldrausch. Auf der Produktseite war es schwieriger, in den größeren Marketingmarkt vorzudringen. Dort habe ich viel Erfahrung mit Teamführung, Skalierung und dem Ausbau einer E-Mail-Infrastruktur mit mehr als 8 Milliarden E-Mails pro Tag gesammelt
    • Ich frage mich, ob E-Mail-Marketing-Unternehmen nicht einfach Spammer bedeuten
    • Man merkt, dass da jemand auf Jobsuche ist
  • Jedes "E-Mail-Startup" legt im Grunde nur eine UI über bestehende Infrastruktur. Niemand baut echte E-Mail-Server, sondern Apps, die sich mit bereits aufgebauter Infrastruktur verbinden. Das war der Teil, der mich beim Aufbau von Mailpace wirklich schockiert hat. Ich dachte, alle würden ihre eigenen SMTP-Server betreiben, aber tatsächlich finanzieren YC und viele andere in großem Stil Firmen, die nur einen Wrapper um AWS SES bauen
    • Der Witz ist, dass YC und andere so tun, als wäre es eine weltbewegende Innovation, massiv in AWS-SES-Wrapper zu investieren, die ganze Branchen umkrempeln werde, und überspitzt gesagt sogar die Pizzalieferung verändern könne
    • Es ist extrem komplex und heikel, E-Mails in den Gmail-Posteingang zu bekommen (wegen des Spam-Problems), deshalb kann ich verstehen, warum Spammer solche Wrapper-Dienste nutzen
  • Ich bin überrascht, dass ganze 20 % der "E-Mail-Startups" erfolgreich sind. Ich finde, das ist eine ziemlich gute Erfolgsquote
  • Über moderne E-Mail-Clients, die mit Electron und React Native entwickelt werden und unter Speicherverbrauchs- und Performance-Problemen leiden, wird gesagt, dass echte Kunden sich dafür überhaupt nicht interessieren. Apps wie Discord und Slack beweisen das angeblich, obwohl sie aufgebläht sind und fast von allen genutzt werden. Ich persönlich mag React nicht, aber ich glaube nicht, dass technische Entscheidungen den langfristigen Erfolg eines Startups stark beeinflussen, solange sie die Kundenerfahrung oder die Features nicht massiv behindern. Bei der Zahl, dass mehr als 80 % der E-Mail-Startups komplett scheitern, würde ich wetten, dass die tatsächliche Ausfallquote noch viel höher ist. Außerdem verstehe ich nicht ganz, warum eine Gewinnquote von 20 % ein schlechtes Ergebnis sein soll, besonders in einem so langweiligen Bereich wie E-Mail. Auf die Aussage im Artikel, Freiwillige könnten Enterprise-Software nicht dauerhaft betreiben, erinnere ich daran, dass in der Open-Source-Welt viele Projekte wie OpenSSL oder Linux überwiegend von Freiwilligen sehr gut betrieben werden. Beim Lesen dieses Artikels denke ich eher noch mehr darüber nach, wie man E-Mail neu erfinden könnte
    • Der Behauptung, dass sich „echte“ Kunden nicht für Performance interessieren, wird widersprochen. Selbst die „normalen“ Nutzer in zwei Firmen, in denen ich gearbeitet habe, suchten wegen der schlechten Erfahrung mit Electron-basierten Apps nach anderen Tools. Das mag anekdotisch sein, aber wenn die Nutzungserfahrung so schlecht ist, dann interessiert das auch ganz gewöhnliche Menschen
    • Ich bin selbst Discord-Nutzer und suche aktiv nach Alternativen, weil es auf meinem M1 MacBook und meinem Gaming-PC viel zu langsam ist. Ich behaupte nicht, den Durchschnittskunden zu repräsentieren, aber ich möchte betonen, dass viele solche Probleme wahrnehmen
    • Die Aussage „Kunden ist das egal“ stimmt einfach nicht. Sogar meine Freundin, die sich kaum für Technik interessiert, hat sich darüber beschwert, dass schon eine Chat-App wie Teams den ganzen Computer verlangsamt. Durchschnittsnutzer hassen vielleicht nicht Electron oder React an sich, aber sie hassen definitiv die schlechte Erfahrung, die dadurch entsteht
    • Auf die Behauptung, Enterprise-Software könne nicht von Freiwilligen gepflegt werden, wird entgegnet, dass auch Postfix größtenteils von Community-Freiwilligen gut betreut wird
    • Als Beispiele für Electron-Apps, die angeblich jeder installiert hat, wurden Discord und Slack genannt, aber ich scheine der Einzige zu sein, der beide nicht installiert hat
  • Es überrascht mich, dass Hey nicht erwähnt wurde. Ich kenne kein anderes jüngeres Beispiel für den Versuch, E-Mail neu zu erfinden. Vielleicht wurde es ausgelassen, weil es kein eigenständiges Unternehmen ist, sondern Teil von Basecamp, aber wenn man die These aufstellt, dass „niemand E-Mail neu erfunden hat“, dann sollte es unbedingt behandelt werden
    • Es wurde erwähnt. Es gibt einen eigenen Abschnitt mit dem Titel „The HEY Experiment“
    • Ich frage mich, ob mit Neuerfindung nur UX gemeint ist. Fastmail interpretiert E-Mail mit hervorragenden offenen Protokollen neu
  • Wie im Fall Techstars wirken 5 Exits bei 28 E-Mail-bezogenen Unternehmen und damit fast 80 % Misserfolgsquote zunächst problematisch, aber verglichen mit der allgemeinen Startup-Ausfallquote ist das eigentlich deutlich besser. Bei 80 % Ausfallquote würde ich eher mehr in E-Mail-Firmen investieren. Die gesamte Analyse wirkt so, als sei sie passend zur gewünschten Aussage zurechtgebogen, und selbst die Erwähnung von Cyrus IMAP und SpamAssassin wirkt, als stecke sie in der Vergangenheit fest. Da der Autor bootstrapped ist, kann ich den Tonfall nachvollziehen, aber ich denke, eine objektivere Perspektive wäre nötig
  • Wenn man Fastmail in die Startup-Kategorie einordnet, müsste man dann nicht auch Unternehmen wie Posteo und Mailbox.org dazuzählen? Runbox.com wird zwar von einer Person betrieben, aber auch solche Firmen wachsen seit Jahrzehnten stetig. Posteo hat zudem kein VC-Geld aufgenommen (was der Artikel als Faktor nennt, der die Wahrscheinlichkeit des Scheiterns senkt), und auch stabile Dienste wie Migadu werden gar nicht erwähnt
    • „AI“ hat möglicherweise nicht genug Erwähnungsdaten über solche Unternehmen gelernt, deshalb fehlen sie vielleicht
    • Runbox.com ist zwar ein kleines Team, aber nicht nur eine einzige Person. Laut der Runbox-Teamseite gibt es mehrere Teammitglieder. (Ich bin selbst Kunde)
  • Ich verstehe nicht, warum Mailbox als Fehlschlag eingestuft wird, obwohl das Unternehmen 6 Millionen Dollar eingesammelt und für 100 Millionen Dollar einen Exit geschafft hat
    • Auch der Fall Rapportive mit 120.000 Dollar Finanzierung und einem Exit für 15 Millionen Dollar wäre beachtenswert