Rechtliches
Die eigene Mail.
Was wir damit tun.
OpenEmail ist ein Postfach, deshalb geht es in diesem Dokument vor allem um das eine, worauf es ankommt: Nachrichten gehören denen, die sie schreiben und empfangen, und wir halten nur das vor, was ihre Zustellung erfordert. Zuletzt aktualisiert am September 16, 2026.
Unser Versprechen zur Privatsphäre
Bei OpenEmail halten wir Privatsphäre für ein Grundrecht. Unsere E-Mail-Lösung ist von Grund auf darauf gebaut, und wir legen offen, wie wir mit den anvertrauten Daten umgehen.
Wichtig: OpenEmail ist ein Mail-Host und kein Client, der die Mail anderswo liegen lässt. Mail an eine verbundene Domain wird an uns zugestellt, und wir speichern sie (die vollständige Nachricht und ihre Anhänge), weil es keine andere Kopie gibt, in der sie liegen könnte.
Was das in der Praxis bedeutet:
- Speicherung: Nachrichten und Anhänge werden in einen Objektspeicher geschrieben und je Postfach in einer eigenen Datenbank indexiert. Sie bleiben dort, bis sie gelöscht werden.
- Verarbeitung: Mail wird auf dem Server geparst, zu Threads verknüpft, auf Spam bewertet, zusammengefasst und für die Suche indexiert, bevor ein Browser beteiligt ist. Der Browser stellt dar, was bereits gespeichert ist.
- Kontrolle: Thread löschen, Workspace löschen und unseren Zugriff auf die Google-Anmeldung jederzeit widerrufen.
Google-Konto-Anbindung
Bei der Anmeldung bei OpenEmail mit einem Google-Konto:
- Wir fragen bei Google Name, E-Mail-Adresse und Profilbild ab und sonst nichts. Ein Mail-Scope wird nicht angefordert, diese Anmeldung gibt OpenEmail also keinerlei Möglichkeit, in einem Google-Postfach zu lesen, zu senden oder etwas zu speichern.
- Wir nutzen die sichere OAuth-2.0-Authentifizierung von Google
- Unser Zugriff auf das Google-Konto lässt sich jederzeit in den Einstellungen des Google-Kontos widerrufen
Datenerhebung und Verwendung
Umgang mit Daten aus Google-Diensten
- Das Profil, das Google bei der Anmeldung zurückgibt, wird gemäß der Google API Services User Data Policy behandelt
- Daten während der Übertragung sind auf jedem Abschnitt, den wir kontrollieren, mit TLS verschlüsselt. Der SMTP-Abschnitt zu oder von einem fremden Server ist opportunistisch und ungemessen, wie der Abschnitt zur Verschlüsselung weiter unten ausführt. Ruhende Daten verschlüsselt der Speicheranbieter; eine zweite eigene Schicht fügen wir nicht hinzu, und die Schlüssel liegen bei uns, wir sind also technisch in der Lage, das Gespeicherte zu lesen, und genau das tun die Funktionen, die Mail zusammenfassen und durchsuchen. Die Ausnahme ist eine Nachricht, die Ende-zu-Ende-verschlüsselt eingetroffen ist: Was wir davon speichern, ist Chiffrat, versiegelt für einen Schlüssel, den wir nicht haben, also liest keine unserer Funktionen sie, und wir können es ebenso wenig.
- Betriebsprotokolle können kurzzeitig Anfragedaten enthalten, wie bei jeder Anfrage an jeden Server, und sie laufen nach dem Zeitplan der Plattform aus, nicht nach einer von uns gesetzten Frist.
Orte der Datenverarbeitung
- Die App läuft auf einem einzelnen virtuellen Server in Ashburn, Virginia, und die Datenbank, aus der sie liest, steht daneben. Anhänge liegen getrennt davon in Cloudflare R2. Mail- und Kontodaten werden daher in den Vereinigten Staaten verarbeitet.
- Die Mail selbst läuft über Amazon Web Services, in der Region us-east-1 (Northern Virginia). Eine Nachricht an eine Adresse hier wird von Amazon SES empfangen, vollständig in einen Amazon-S3-Bucket in dieser Region geschrieben und von dort von unserem Server zurückgelesen, der sie parst und das Ergebnis in dem oben beschriebenen Speicher ablegt. Ausgehende Mail verlässt uns über Amazon SES in derselben Region. Jede Nachricht passiert also in beide Richtungen die Vereinigten Staaten, welchen Weg sie auch zu uns genommen hat.
- Diese S3-Kopie ist die Nachricht genau so, wie sie eintraf: Header, Body und Anhänge, von Amazon im Ruhezustand verschlüsselt und für uns genauso lesbar wie die geparste Kopie. Sie wird 30 Tage nach Eingang automatisch gelöscht, und nichts im Produkt liest sie, sobald die Nachricht eingelesen ist. Eine Ende-zu-Ende-verschlüsselt eingetroffene Nachricht liegt dort als Chiffrat vor, wie überall sonst.
KI und E-Mail-Daten
Was wann an ein Modell gesendet wird
- Bei einer Anfrage. Den Assistenten öffnen, eine Zusammenfassung anfordern, eine Antwort erzeugen oder eine Suche ausführen sendet das Material, das die jeweilige Anfrage braucht: den Text der angezeigten Nachrichten oder des Threads und die eingegebene Anweisung. Anhänge werden nur gesendet, wenn sich die gewählte Aktion auf den Anhang bezieht.
- Wenn Mail eintrifft. Neue Threads werden automatisch zusammengefasst und mit Labels versehen, und Betreffzeilen werden stichprobenartig ausgewertet, um zu ermitteln, worum es in der eingehenden Mail geht. Das ist ein Modellaufruf, der nicht einzeln angefordert wurde, und wir sagen das lieber offen, als es der eigenen Entdeckung zu überlassen: Er sorgt dafür, dass Zusammenfassungen und Labels beim Öffnen des Posteingangs da sind und nicht erst nach einer Wartezeit. Er läuft auf dem Thread, sobald dieser eintrifft.
- Beim Senden. Der Text einer gesendeten Nachricht wird an ein Modell übergeben, um das Schreibstilprofil zu pflegen, mit dem das Produkt in der eigenen Stimme formuliert. Das passiert bei jedem Senden, auch bei vollständig selbst geschriebener Mail, und lässt sich derzeit über keine Einstellung abschalten.
- Jeder ausgelöste Prompt ist im Produkt les- und bearbeitbar, sodass vor dem Absenden ersichtlich ist, was eine Anfrage senden würde.
Was gespeichert bleibt
- Wir verwenden Mail, Prompts und Completions nicht, um Modelle zu trainieren, und wir verkaufen sie nicht und geben sie niemandem zur eigenen Verwendung weiter.
- Ein Teil der KI-Ausgaben wird gespeichert, denn eine Zusammenfassung, die sich nicht behalten lässt, lohnt die Erzeugung nicht: Thread- und Nachrichtenzusammenfassungen werden zum jeweiligen Postfach gespeichert, und die Unterhaltung mit dem Assistenten bleibt erhalten, damit sie bei der Rückkehr noch da ist. Wird die Assistenten-Unterhaltung geleert, ist sie gelöscht. Wird ein Thread gelöscht, verschwinden die Nachricht, ihre Anhänge und die für die Suche geschriebene Zusammenfassung. Diese Zusammenfassung ist ein Absatz, der den Thread beschreibt; bliebe sie zurück, bliebe eine lesbare Beschreibung von etwas Gelöschtem zurück.
- Darüber hinaus werden Prompts und Completions nicht als gesondertes Transkript aufbewahrt. Betriebsprotokolle können kurzzeitig Anfragetext enthalten, wie bei jeder Anfrage an einen Server, und sie laufen mit der Zeit aus.
Wo Inferenz stattfindet
- Assistent, Verfassen, Websuche, die für das Postfach gebauten Suchanfragen, das Schreibstilprofil und die Themenauswertung der Betreffzeilen laufen über OpenRouter mit einer Routing-Vorgabe ohne Speicherung:
data_collection: 'deny', angewendet inapps/api/src/lib/ai-key.tsals PLATFORM_ROUTING. Der Router schließt bei diesen Anfragen jeden Upstream-Anbieter aus, dessen Richtlinie das Aufbewahren von Prompts zum Training erlaubt; bleibt für das gewählte Modell kein zulässiger Anbieter übrig, schlägt die Anfrage fehl, statt auf einen auszuweichen, der es erlaubt. - Diese Vorgabe ist eine Routing-Anweisung an unseren Anbieter. Sie ist der Mechanismus und das, was wir ehrlich behaupten können, und keine Garantie, die wir stellvertretend für einen Upstream-Anbieter geben könnten.
- Die Hintergrundverarbeitung eingehender Mail (eine Zusammenfassung je Nachricht und Thread sowie die zugehörigen Label-Vorschläge) läuft über OpenRouter, denselben Weg wie alles Übrige oben, sodass die Routing-Vorgabe auch dafür gilt.
Datenschutz und Sicherheit
Sicherheitsmaßnahmen
- Ende-zu-Ende-Verschlüsselung funktioniert in beide Richtungen, wobei das Senden weniger Menschen erreicht als das Lesen. Im Browser lässt sich ein OpenPGP-Schlüssel erzeugen und dessen öffentliche Hälfte in einem Verzeichnis veröffentlichen, das andere angemeldete OpenEmail-Sendende nachschlagen können. Die private Hälfte entsteht in diesem Browser, wird nie an uns gesendet und existiert in keinem Backup, keinem Log und keinem Support-Werkzeug von uns. Es gibt bewusst keine Hinterlegung und keine Wiederherstellung: Die Passphrase ist der einzige Weg hinein, und geht sie verloren, kann niemand, wir eingeschlossen, die versiegelt zugestellte Mail noch öffnen. Diese Mail ist dann dauerhaft weg, und keine Anfrage an uns holt sie zurück.
- Eine PGP-Nachricht, die versiegelt für einen Schlüssel im eigenen Browser eintrifft, wird inzwischen in diesem Browser entschlüsselt und dort angezeigt. Wir halten diese Nachricht als Chiffrat und sehen den geöffneten Text nie: Die Entschlüsselung geschieht auf dem eigenen Gerät, der Klartext wird nie an uns zurückgesendet, und nichts von uns schreibt ihn mit. Deshalb steht eine versiegelte Nachricht auch außerhalb von allem, was der Server durch Lesen der Mail tut. Es gibt keinen lesbaren Body, an dem irgendetwas davon arbeiten könnte, also ist sie über ihren Body nicht durchsuchbar, sie wird weder zusammengefasst noch übersetzt, die KI-Funktionen finden an ihr nichts zu lesen, und Regeln können nicht auf ihren Inhalt greifen.
- Das Senden ist inzwischen verdrahtet, und es erreicht weniger Menschen als das Lesen. Wird an einen Empfänger verfasst, dessen öffentlicher Schlüssel veröffentlicht ist, versiegelt der Browser den Body, bevor die Anfrage ihn verlässt, und ein Versand, der verschlüsselt sein müsste, schlägt fehl, statt hinauszugehen. Auf unverschlüsseltes Senden wird nie zurückgefallen. Nachgeschlagen wird der Schlüssel eines Empfängers aber einzig in unserem eigenen Verzeichnis, das Schlüssel enthält, die aus dieser App von Personen veröffentlicht wurden, deren Adresse auf einer hier gehosteten Domain liegt: Es gibt kein Web Key Directory, keinen Keyserver, kein Autocrypt und keine Möglichkeit, die eigene öffentliche Hälfte zu exportieren. In der Praxis funktioniert das Versiegeln also von OpenEmail zu OpenEmail, während das LESEN keine solche Grenze kennt: Jede PGP-Nachricht, die für einen Schlüssel in diesem Browser versiegelt ist, lässt sich öffnen, gleich welcher Client sie gesendet hat. Verschlüsselte Antworten werden abgelehnt, weil das zitierte Original außerhalb der Versiegelung läge.
- Jede andere Nachricht hier läuft auf den von uns betriebenen Abschnitten über TLS und wird vom Speicheranbieter im Ruhezustand verschlüsselt; der Server kann sie alle lesen, und genau das erlaubt ihm, sie zu Threads zu verknüpfen, zu durchsuchen und zusammenzufassen. Der Abschnitt zwischen uns und einem fremden Server ist opportunistisches STARTTLS (angeboten, nie verlangt), und nichts, was mit einer zugestellten Nachricht übergeben wird, sagt, was der Absender genutzt hat, deshalb behaupten wir für keine einzelne Nachricht TLS. Selbst bei einer versiegelten Nachricht deckt PGP den Body ab und sonst nichts: Betreffzeile, Empfänger und Zeitpunkt reisen unverschlüsselt, Entwürfe werden beim Schreiben unversiegelt im Postfach gespeichert, und das sagen wir lieber, als ein Schlosssymbol etwas anderes andeuten zu lassen. S/MIME wird erkannt und gekennzeichnet, lässt sich hier aber nicht öffnen, was nicht dasselbe ist wie geöffnet zu werden.
- OAuth 2.0 für verbundene Google-Konten, mit den engsten Scopes, die die Funktionen brauchen
- Abhängigkeits- und Sicherheitsupdates laufen automatisiert
Sicherheit der Infrastruktur
- Der gehostete Dienst läuft auf Cloudflare (Workers, R2, Durable Objects, KV und Queues) über einer verwalteten Postgres-Datenbank, und Amazon Web Services (SES und S3, us-east-1) befördert die Mail hinein und hinaus. Er erbt die physische und die Netzwerksicherheit dieser Anbieter.
- Gespeicherte Daten werden von diesen Anbietern im Ruhezustand verschlüsselt. Wir betreiben kein eigenes Rechenzentrum und erheben keinen eigenen Zertifizierungsanspruch.
Reaktion auf Sicherheitsmeldungen
- Schwachstellen werden vertraulich an [email protected] gemeldet und von den Menschen bearbeitet, die den Code geschrieben haben.
- Es gibt kein Bug-Bounty-Programm und keine besetzte 24/7-Rufbereitschaft. Beides zu behaupten würde eine Erwartung wecken, die wir nicht erfüllen können.
Umgang mit Google-Nutzerdaten
Datenzugriff und Verwendung
- Die einzigen Google-Nutzerdaten, die wir erhalten, sind die des Anmeldeprofils: Name, E-Mail-Adresse und Profilbild. Wir fordern keinen Gmail-Scope an, es erreichen uns also weder Nachrichteninhalte noch Nachrichten-Metadaten noch Labels aus einem Google-Postfach.
- Dieses Profil dient dazu, das OpenEmail-Konto anzulegen und zu identifizieren. Adresse und Name daraus kommen außerdem auf die unten beschriebene Produkt-Mailingliste, genau wie bei einem Konto, das mit E-Mail und Passwort angelegt wurde. Das ist die einzige Verwendung über das Konto selbst hinaus, und sie trägt einen Abmeldelink.
- Keine Google-Nutzerdaten werden für Profiling oder Werbung verwendet, und nichts davon geht an Werbetreibende oder Datenhändler
- Zugriff auf gespeicherte Nutzerdaten haben nur die Maintainer, die den Dienst betreiben. Ein Audit-Log je Zugriff gibt es nicht: Das Produkt führt keines, und das sagen wir lieber, als einen Nachweis anzudeuten, den wir nicht vorlegen könnten.
Weitergabe und Übermittlung von Daten
- Google-Nutzerdaten werden niemals an Dritte weitergegeben, außer soweit es für die Kernfunktionen des Dienstes erforderlich ist
- Sofern nötig, arbeiten wir nur mit Dienstleistern zusammen, die die Google API Services User Data Policy einhalten
- Bei der Registrierung kommt die Adresse auf eine Mailingliste, damit wir zum Produkt erreichbar bleiben. Sie liegt bei Resend, wo auch die transaktionale Mail läuft, und enthält die Adresse und den Namen auf dem Konto: nichts über die Mail und nichts darüber, mit wem korrespondiert wird. Jede Nachricht von dieser Liste trägt einen Abmeldelink, und das Abmelden wirkt sich nicht auf das Konto aus.
- Die Anbieter, auf die der gehostete Dienst angewiesen ist, sind ein virtueller Server in Ashburn, Virginia für die Anwendung selbst, Cloudflare für die Ablage der Anhänge und die Auslieferung der Webseiten, Amazon Web Services für das Senden und Empfangen von Mail und für die oben beschriebene Rohkopie eingehender Nachrichten, ein verwalteter Postgres-Host für die Datenbank, Polar für Zahlungen, Resend für transaktionale Mail und die oben genannte Mailingliste sowie die im vorigen Abschnitt genannten KI-Anbieter. Vier weitere werden aus dem Browser oder in unserem Auftrag erreicht und stehen hier der Vollständigkeit halber, nicht weil sie viel erhielten: Gravatar, das unser Server mit einem Hash der Adresse und nie mit der Adresse selbst nach dem Bild eines Korrespondenzpartners fragt; ein öffentlicher DNS-Resolver, der gefragt wird, ob die Domain eines Absenders ein Markenlogo veröffentlicht, und der damit diese Domain sieht, aber nie eine Adresse oder eine Nachricht; Google und GitHub, die das Profilbild aller bei OpenEmail ausliefern, die es aus einer Google- oder GitHub-Anmeldung mitgebracht haben, direkt an den Browser, sobald diese Person im Postfach auftaucht; und der Host des Absenders selbst. Dieser Host wird auf zwei Wegen erreicht. Unser Server fragt ihn, oder wohin er zeigt, nach dem Logo der Marke oder dem Site-Icon, wenn es zu einem Korrespondenzpartner kein anderes Bild gibt, was für ihn wie eine Anfrage von uns aussieht. Der Browser holt die Bilder innerhalb einer Nachricht direkt von dort. Beides lässt sich unter Konto → Datenschutz abschalten, das erste über die Bildsuche, das zweite über externe Bilder. Die Bildsuche ist wie Gravatar oben standardmäßig AN. Externe Bilder ebenso, ein Zählpixel in einer Nachricht sieht also die Adresse und den Moment des Öffnens, bis beides abgeschaltet wird. Drei weitere werden nur von den öffentlichen Seiten dieser Website erreicht und nie aus dem Postfach: Google Analytics, Hotjar und Microsoft Clarity, die Besuche zählen und zeigen, wie eine Seite genutzt wird. Keines davon lädt im angemeldeten Zustand, also sieht keines davon je ein Postfach. Hotjar und Clarity wird schon vor dem Laden aufgetragen, jeden Text und jede Eingabe zu maskieren, sodass eine Sitzung Layout und Klicks zeigt und nichts vom Geschriebenen, und keinem der drei wird ein Name, eine Adresse oder ein Konto übergeben. Was sie hinterlassen, sagt, welche Seiten besucht wurden, nicht wer sie besucht hat. Schriften stehen nicht auf dieser Liste, weil sie von niemandem geholt werden: Jede Schrift ist mitgeliefert und wird aus derselben Origin wie die App ausgeliefert. Fehlerberichte ebenfalls nicht, sofern sie nicht konfiguriert sind. Nichts wird verkauft oder jemandem zur eigenen Verwendung überlassen.
- Über wesentliche Änderungen an unserer Weitergabepraxis wird informiert
Aufbewahrung und Löschung von Daten
- Gespeicherte Mail hat kein Ablaufdatum. Sie bleibt, bis etwas sie löscht, und nichts löscht sie nach einem Zeitplan.
- Die einzige Ausnahme ist die Kopie jeder eingehenden Nachricht, die in Amazon S3 so liegt, wie sie eintraf: Sie wird 30 Tage nach der Zustellung automatisch gelöscht.
- Beim Löschen eines Threads verschwinden die gespeicherte Nachricht und ihr Indexeintrag.
- Wird ein Konto getrennt, wird das dahinterliegende Postfach gelöscht. Dasselbe gilt, wenn die letzte Domain eines Workspace entfernt wird, womit jede dafür gespeicherte Nachricht verschwindet. Die App warnt vorher.
- Auf Anfrage löschen wir, was übrig ist.
Nutzerrechte und Kontrollmöglichkeiten
- Recht auf Auskunft: eine Kopie der Daten anfordern
- Recht auf Berichtigung: unrichtige Daten korrigieren
- Recht auf Löschung: die Löschung der Daten verlangen
- Recht auf Einschränkung der Verarbeitung: begrenzen, wie wir die Daten verwenden
- Recht auf Datenübertragbarkeit: die Daten in übertragbarer Form anfordern. Wird wie der Rest dieser Liste auf Anfrage bearbeitet. Einen Selbstbedienungsexport gibt es im Produkt noch nicht, und diese Seite suggeriert keine Schaltfläche, die es nicht gibt.
- Recht auf Widerspruch: bestimmter Datenverarbeitung widersprechen
Limited-Use-Hinweis
Unsere Verwendung von Informationen aus Google-APIs und deren Weitergabe an andere Apps erfolgt gemäß der Google API Services User Data Policy, einschließlich der Limited-Use-Anforderungen.
Rechte und Einstellungsmöglichkeiten
- Recht, unseren Zugriff über die Google-Anmeldung jederzeit zu widerrufen
- Recht, die Löschung der Mail und der bei uns liegenden Daten zu verlangen
- Recht, eine Kopie der eigenen Daten anzufordern
- Recht, sich über den Umgang mit Daten zu beschweren
Preise und Erstattungsregelung
Kostenloser Tarif und kostenpflichtige Tarife
- OpenEmail bietet einen kostenlosen Tarif (1 domain und 10 addresses), für den keine Zahlungsdaten nötig sind
- Kostenpflichtige Tarife heben diese Grenzen an und bringen Teammitglieder dazu: Starter umfasst 5 domains, Business 10 domains und Enterprise Unlimited domains, jeweils mit unbegrenzt vielen Adressen
- Die REST-API, der MCP-Server und das TypeScript-SDK sind in jedem Tarif enthalten, auch im kostenlosen. Programmatisches Senden zählt auf dasselbe monatliche Sendekontingent wie alles andere, nicht auf eine gesonderte Berechtigung
- Empfangen ist in jedem Tarif unbegrenzt. Der kostenlose Tarif enthält 10,000 sends a month und 50 AI actions a day, die kostenpflichtigen Tarife heben beides an. Nutzungsgebühren gibt es keinerlei. Berechnet wird immer nur der Preis des Tarifs
- Für keinen kostenpflichtigen Tarif gibt es eine kostenlose Testphase. Der kostenlose Tarif ist ebenfalls keine Testphase: 1 domain und 10 addresses, ohne Karte und ohne Zeitlimit
- Ein kostenpflichtiger Tarif wird beim Kauf berechnet und danach bei jeder Verlängerung
- Kündigung ist jederzeit möglich; der Tarif läuft bis zum Ende des bezahlten Zeitraums
Zahlung und Abrechnung
- Abogebühren werden im Voraus abgerechnet, monatlich oder jährlich
- Aktuelle Preisangaben stehen auf unserer Preisseite
- Alle Zahlungen werden sicher über unsere vertrauenswürdigen Zahlungspartner abgewickelt
- Abobuchungen erscheinen auf der Abrechnung als „OpenEmail“
- Wir akzeptieren gängige Kreditkarten und weitere Zahlungsmethoden, soweit sie in der jeweiligen Region verfügbar sind
Keine Erstattung
- Wichtig: Abogebühren sind nicht erstattungsfähig, sobald ein Abrechnungszeitraum begonnen hat
- Diese Regelung gilt für Starter, Business und Enterprise gleichermaßen, in beiden Abrechnungszeiträumen.
- Für angebrochene Abozeiträume werden keine Erstattungen gewährt
- Für nicht genutzte Teile des Abos gibt es keine Erstattung
- In Ausnahmefällen können Erstattungen im Einzelfall nach unserem alleinigen Ermessen geprüft werden
Abo-Verwaltung
- Das Abo lässt sich jederzeit in den Kontoeinstellungen kündigen
- Die Kündigung wird zum Ende des laufenden Abrechnungszeitraums wirksam
- Der Zugang zu den Premium-Funktionen bleibt bis zum Ende des bezahlten Zeitraums bestehen
- Bei vorzeitiger Kündigung gibt es keine anteilige Erstattung
- Für die Reaktivierung gekündigter Abos können die aktuellen Preise gelten
Preisänderungen
- Wir behalten uns vor, die Abopreise jederzeit zu ändern
- Bestehende Abos werden mindestens 30 Tage im Voraus über Preisänderungen informiert
- Preisänderungen werden mit dem nächsten Abrechnungszeitraum wirksam
- Das Abo kann gekündigt werden, bevor die Preisänderung wirksam wird
Kontakt
Bei Fragen oder Anliegen zum Datenschutz:
Änderungen dieser Erklärung
Wir können diese Datenschutzerklärung von Zeit zu Zeit aktualisieren. Über wesentliche Änderungen informieren wir in unserer Anwendung oder auf unserer Website.
