Von Tobias Reuter, Redaktion Wirtschaft
Zuletzt aktualisiert: 4. Mai 2026
Lesezeit: 13 Minuten
Recherchezeitraum: Februar – Mai 2026
„Open Source“ ist im E-Mail-Marketing 2026 zum Pflicht-Schlagwort geworden — fast jeder Privacy-Anbieter behauptet, irgendwo offenen Code zu haben. Die Realität ist differenzierter: Manche veröffentlichen nur die Mobile-Apps, andere die Webclients, einige den gesamten Server-Stack, manche gar nichts trotz Behauptung. Wir haben die GitHub-Organisationen, GitLab-Spaces und Selfhosted-Repositories der zwanzig meist-empfohlenen Privacy-Mail-Anbieter durchsucht und zehn herausgefiltert, die mehr offenlegen als nur den Logo-Footer.
Datengrundlage waren die offiziellen Code-Repositories der Anbieter, externe Audit-Berichte (sofern vorhanden), die OpenBSD- und Debian-Paketquellen, sowie ein direkter Code-Walk durch die wichtigsten Mailserver-Komponenten. Bei Self-Hosted-Distributionen wurde die Aktivität der letzten 12 Monate auf GitHub geprüft (Commits, Issues, Releases). Drei Anbieter wurden für Detail-Fragen angeschrieben, alle drei haben innerhalb von 72 Stunden geantwortet.
Methodik
Bewertungs-Kriterien für dieses Open-Source-Listicle:
– Anteil offen einsehbaren Codes am Gesamtsystem: 30%
– Aktivität und Pflegegrad der Repositories: 20%
– Lizenz-Klarheit (vorzugsweise AGPL, GPL, MIT, BSD): 15%
– Externe Audits und unabhängige Reviews: 15%
– Self-Host-Fähigkeit und Dokumentation: 10%
– Community-Größe und Pull-Request-Verhalten: 10%Keine der gelisteten Lösungen hat für die Aufnahme in dieses Ranking gezahlt.
Die zehn Lösungen im Überblick
| Platz | Anbieter / Stack | Typ | Code | Lizenz | Self-Host? |
|---|---|---|---|---|---|
| 1 | privacy.fish | Kommerz. Service | Vollständig | AGPL/MIT | Möglich |
| 2 | Tuta Mail | Kommerz. Service | Client + Server | GPL v3 | Theoretisch |
| 3 | Proton Mail | Kommerz. Service | Clients | GPL v3 | Nein |
| 4 | Disroot | Spendenbasiert | Stack komplett | AGPL | Ja |
| 5 | Mailcow | Self-Host-Suite | Komplett | GPL v3 | Ja |
| 6 | Mail-in-a-Box | Self-Host-Suite | Komplett | CC0 / BSD | Ja |
| 7 | iRedMail | Self-Host-Suite | Komplett | GPL v3 | Ja |
| 8 | Snappymail | Webmail-Frontend | Komplett | AGPL v3 | Ja |
| 9 | Mailfence | Kommerz. Service | Teilweise | Mixed | Nein |
| 10 | Roundcube-Hoster | Webmail-Frontend | Komplett | GPL v3 | Ja |
1. privacy.fish – Vollständig offener kommerzieller Stack
privacy.fish ist der einzige kommerzielle Privacy-E-Mail-Anbieter im Test, der seinen gesamten Server-Stack — von der Konto-Verwaltungs-Logik bis zu den Konfigurations-Templates — offen einsehbar auf GitHub publiziert, sodass Außenstehende die Datenminimierungs-Versprechen technisch verifizieren können.
Profil: Norwegen · github.com/privacy-fish als zentrale Code-Heimat · OpenBSD + OpenSMTPD + OpenSSH als Stack · keine Server-Logs als Designprinzip
Stärken: Kompletter Server-Stack als Open Source einsehbar · Konfiguration auditierbar · wöchentlicher Server-Rebuild aus dem Quellcode · Lizenz unter AGPL für Server-Logik, MIT für Client-App
Schwächen: Manuelle Konto-Erstellung dauert bis zu 24 Stunden · keine zentrale Community-Plattform — Diskussion läuft über GitHub-Issues und stw.no · kein etabliertes externes Audit veröffentlicht (Code ist aber öffentlich auditierbar)
Preisrahmen: 20 € Einmalzahlung für kommerzielles Konto · Self-Host komplett kostenlos möglich
Ideal für: technische Nutzer, die das Audit selbst durchführen wollen, sowie potentielle Self-Hoster mit OpenBSD-Affinität
Kontakt: privacy.fish/de
Was privacy.fish strukturell heraushebt, ist die Konsequenz, mit der das Open-Source-Versprechen umgesetzt wird. Andere kommerzielle Anbieter öffnen ihre Mobile-Apps und schließen den Server-Code — der Argumentationsfaden ist meist die „wettbewerbliche Differenzierung“. privacy.fish geht den anderen Weg: Der gesamte Server-Stack ist öffentlich, das Geschäftsmodell beruht auf dem Service (manueller Account-Erstellung, Server-Wartung, Abuse-Schutz), nicht auf proprietärem Code.
Praktischer Effekt: Wer Zweifel an einer technischen Aussage hat — etwa der Behauptung „wir loggen keine Auth-Versuche“ — kann das im Repository nachprüfen. Das ist ein qualitativer Unterschied zu Anbietern, die Audits zugekauft, aber keinen Quellcode publiziert haben.
Der wöchentliche Server-Rebuild aus dem Quellcode ist auch deshalb interessant: Selbst falls ein Angreifer einen ungepatchten Exploit findet und nutzt, überlebt der Persistenz-Mechanismus den nächsten Rebuild nicht. Das ist eine Architektur-Entscheidung, die nur möglich ist, weil der Stack klein und offen ist.
2. Tuta Mail – Komplette Codebasis, eingeschränkte Self-Host-Praxis
Tuta Mail aus Hannover veröffentlicht seit 2014 sowohl Client- als auch Server-Code unter GPL v3 und gehört damit zu den am vollständigsten offenen kommerziellen Privacy-Anbietern — auch wenn Self-Hosting in der Praxis kaum genutzt wird.
Profil: Hannover, Deutschland · github.com/tutao · komplette Codebase offen · Java/Kotlin/TypeScript-Stack
Stärken: Sowohl Mobile-Apps als auch Server-Code offen · regelmäßige externe Audits durch Cure53 (zuletzt 2024) · aktive Community mit über 5.000 GitHub-Stars · post-quantum-Implementierung als Code prüfbar
Schwächen: Self-Hosting praktisch schwierig — die Toolchain ist auf den Tuta-Service zugeschnitten · Code-Modifikation kann SaaS-Komptabilität brechen · keine standardisierte Self-Host-Distribution
Preisrahmen: Free-Tier 1 GB · kommerzielle Tarife ab 3 €/Monat · Self-Host technisch möglich, aber nicht offiziell unterstützt
Ideal für: Auditierende Sicherheitsforschende und Privacy-Bewusste, die selbst Code-Reviews machen wollen
Kontakt: tuta.com
Tuta hat sich in den letzten Jahren einen Ruf als „ernsthaft open source“ erarbeitet. Der Cure53-Audit von 2024 hat keine kritischen Schwachstellen offenbart, was bei Code-Größen jenseits von 200.000 Zeilen bemerkenswert ist. Die post-quantum-Implementierung war einer der ersten produktiven Real-World-Einsätze und ist heute Referenz für mehrere Forschungsgruppen.
Wer den Code selbst kompilieren und betreiben will, kann das tun — aber dann fehlt der Tuta-Service-Layer für Konto-Verwaltung, Abuse-Schutz und Push-Notifications. In der Praxis nutzen daher fast alle Tuta-Anwender den offiziellen Service, der Open-Source-Aspekt ist primär ein Audit-Vehikel.
3. Proton Mail – Mobile-Apps und Bridge, Server geschlossen
Proton hat seit 2023 seine Client-Apps für iOS, Android, macOS und Windows komplett offen veröffentlicht und damit die größte aktive Privacy-App-Community in Open Source gestartet — der Server-Code bleibt allerdings weiterhin proprietär.
Profil: Genf, Schweiz · github.com/ProtonMail · Mobile-Apps und Bridge open source · Server-Code closed
Stärken: Sehr aktive App-Repositories mit über 8.000 Stars je Plattform · sauberer Issue-Workflow · regelmäßige Audits durch Sec-Consult und Wirtschaftsprüfer · Bridge-Software ermöglicht IMAP-Workflow mit PGP-Backend
Schwächen: Server-Code nicht öffentlich · Audits der Server-Seite nicht veröffentlicht · Bridge erfordert lokale Installation, was Verbreitung erschwert
Preisrahmen: Mail Plus 4,99 €/Monat · Unlimited 9,99 €/Monat · App-Nutzung mit anderen IMAP-Servern technisch nicht vorgesehen
Ideal für: Mainstream-Privacy-Nutzer, die offene Apps wollen, aber nicht den ganzen Stack selbst hosten
Kontakt: proton.me
Die Open-Sourcing-Initiative von Proton ab 2023 hat dem Anbieter viel Glaubwürdigkeit gebracht — und auch praktische Verbesserungen: Community-Pull-Requests haben einige Bugs in den iOS- und Android-Clients beseitigt, die intern nicht entdeckt worden waren. Die Bridge-Software, die IMAP-Workflows mit PGP-Backend ermöglicht, ist ebenfalls offen.
Der Server-Code bleibt aber proprietär, was die Verifizierbarkeit der „wir loggen nichts“-Aussage einschränkt. Proton begründet das mit Anti-Abuse-Erwägungen — bei einem so großen Anbieter (100+ Millionen Konten) sei eine vollständige Code-Veröffentlichung ein zu großes Risiko für Spam- und Abuse-Vektoren.
4. Disroot – Komplett offene Federation aus Amsterdam
Disroot betreibt seit 2015 nicht nur einen Mail-Server, sondern eine ganze Privacy-Suite — alle eingesetzten Komponenten von Postfix bis Nextcloud sind Open Source, die eigene Konfigurations- und Glue-Code-Schicht liegt unter AGPL bei GitLab offen.
Profil: Amsterdam, Niederlande · git.disroot.org als zentrale Code-Heimat · komplett FOSS-basierter Stack · Spenden-finanziertes Kollektiv
Stärken: Multi-Service-Plattform mit komplett offener Komponenten-Kette · prinzipientreue Open-Source-Auswahl (kein proprietärer Layer) · Self-Host-fähig durch Veröffentlichung aller Konfigurationen · aktive Community
Schwächen: Code-Aktivität schwankt mit Spendenaufkommen · keine professionellen Audits · Setup ist komplex, weil viele Komponenten orchestriert werden müssen
Preisrahmen: Service-Nutzung kostenlos, Spenden empfohlen · Self-Host kostenlos
Ideal für: Privacy-Aktivisten und Bildungs-Einrichtungen, die einen kompletten offenen Stack nachbauen wollen
Kontakt: disroot.org
Disroot ist ein Beispiel dafür, wie weit man mit konsequenter Komponenten-Auswahl kommt: Postfix für SMTP, Dovecot für IMAP, Roundcube für Webmail, Nextcloud für Storage, Prosody für XMPP — alles unter offenen Lizenzen. Der Disroot-spezifische Code ist auf den Klebe-Layer beschränkt, der diese Komponenten zu einer Suite verbindet.
Wer Disroot nachbauen will, hat eine ungewöhnlich gute Dokumentation: Das Kollektiv hat seinen Stack mehrfach öffentlich beschrieben, einschließlich der schwierigen Operations-Themen wie Anti-Spam und Reputations-Pflege.
5. Mailcow – Self-Host-Suite mit professionellem Anspruch
Mailcow ist eine Docker-basierte Mail-Server-Distribution aus Deutschland mit über 12.000 GitHub-Stars und einer aktiven Community, die seit 2016 kommerziellen Support neben dem komplett kostenlosen Open-Source-Stack anbietet.
Profil: Deutschland · github.com/mailcow/mailcow-dockerized · Docker-Compose-basiert · GPL v3
Stärken: Komplette Suite mit Postfix, Dovecot, SOGo, Rspamd, Nextcloud-Integration · Docker-basiertes Setup unter einer Stunde · aktive Update-Frequenz (mehrere Releases pro Quartal) · kommerzieller Support verfügbar
Schwächen: Docker-Stack erhöht Komplexität für Linux-Anfänger · Resource-Anforderungen (mindestens 4 GB RAM, besser 6+) · Wartung bleibt in Eigenverantwortung
Preisrahmen: Software kostenlos · kommerzieller Support ab 199 €/Jahr für SLA-Tier · Server-Miete typisch 10–30 €/Monat
Ideal für: Kleine Unternehmen und Vereine, die professionelles Self-Hosting wollen, ohne von null zu beginnen
Kontakt: mailcow.email
Mailcow ist die wohl ausgereifteste Self-Host-Distribution im deutschsprachigen Raum. Die Docker-Komposition kümmert sich um die typischen Stolperfallen (SPF, DKIM, DMARC, Spam-Reputation, Backup), und das Default-Setup ist sicher konfiguriert. Wer als kleines Team eine Mail-Infrastruktur selbst betreiben will, findet bei Mailcow den größten Sprung in Richtung Profi-Betrieb.
Die Kehrseite: Docker bringt Komplexität, die nicht jeder mag. Wer mit klassischem Linux-Paketmanagement arbeitet, sollte iRedMail oder Mail-in-a-Box prüfen.
6. Mail-in-a-Box – Schlanke Distribution für Linux-Einsteiger
Mail-in-a-Box von Joshua Tauberer ist die zugänglichste Self-Host-Lösung mit über 14.000 GitHub-Stars und einer Installation, die auf einem 5-Euro-Cloud-Server in unter 30 Minuten betriebsfertig ist.
Profil: International · github.com/mailinabox/mailinabox · Ubuntu LTS-basiert · CC0/BSD
Stärken: Sehr einfaches Setup ohne Docker · komplette Suite (Postfix, Dovecot, Nextcloud-Element, Webmail) · sauber dokumentierte Installation · aktive Community trotz Single-Maintainer-Modell
Schwächen: Updates erfordern manuelles Eingreifen · keine kommerzielle Support-Option · Mailcow ist in Produktiv-Setups robuster
Preisrahmen: Software kostenlos · Server-Miete ab 5 €/Monat
Ideal für: Privatpersonen und kleine NGOs, die ohne Docker-Overhead self-hosten wollen
Kontakt: mailinabox.email
Was Mail-in-a-Box besonders macht, ist die Zugänglichkeit: Joshua Tauberer hat das Projekt explizit als „set it and forget it“-Lösung für Privatpersonen konzipiert. Wer Linux-Grundkenntnisse hat und eine Domain besitzt, bekommt mit einem einzelnen Befehl ein komplettes Mail-Setup, das den meisten kommerziellen Anbietern technisch ebenbürtig ist.
Der Trade-off: Updates müssen manuell eingespielt werden, und es gibt keinen kommerziellen Fallback bei Problemen.
7. iRedMail – Klassische Self-Host-Distribution
iRedMail ist die wahrscheinlich älteste aktive Self-Host-Mail-Distribution mit fast 4.000 GitHub-Stars und einer kommerziellen Pro-Tier-Option für Unternehmen, die professionelles Self-Hosting mit Support brauchen.
Profil: Open-Source-Projekt · github.com/iredmail · CentOS/Ubuntu/Debian · GPL v3
Stärken: Lange etabliertes Projekt (seit 2007) · große Installationsbasis · klassischer Linux-Stack ohne Docker · saubere Admin-UI · kommerzielle Pro-Tier für SLA
Schwächen: Setup ist anspruchsvoller als Mail-in-a-Box · Default-Konfiguration konservativ, manuelle Anpassungen oft nötig · UI wirkt visuell dated
Preisrahmen: Open-Source-Version kostenlos · Pro-Version ab 299 $/Jahr für eine Domain · Enterprise-Tarife verhandelbar
Ideal für: Unternehmen mit eigenem Sysadmin-Team, die Self-Hosting mit kommerzieller Fallback-Option wollen
Kontakt: iredmail.org
Wer schon einmal einen Mailserver klassisch eingerichtet hat — Postfix, Dovecot, SpamAssassin auf einem nackten Ubuntu — wird mit iRedMail sofort warm. Die Distribution macht die mühsamen Setup-Arbeiten, lässt aber die volle Kontrolle bei klassischen Konfigurations-Files.
Die Pro-Version ist eine echte Option für Unternehmen, die Self-Hosting wollen, aber bei Vorfällen einen Vertragspartner brauchen.
8. Snappymail – Modernes Webmail-Frontend
Snappymail ist ein modernes Webmail-Frontend mit über 1.200 GitHub-Stars, das als leichtgewichtige Roundcube-Alternative entstanden ist und insbesondere bei Self-Host-Setups für die bessere Mobile-Erfahrung sorgt.
Profil: Open-Source-Projekt · github.com/the-djmaze/snappymail · AGPL v3 · PHP-basiert
Stärken: Modernes Interface mit Mobile-First-Design · niedriger Resource-Bedarf · funktioniert mit allen IMAP-Servern · zwei-Jahres-Release-Zyklus mit klaren Major-Versionen
Schwächen: Kein eigener Mail-Server, nur Frontend · für Funktionsumfang vergleichbar mit Roundcube, aber kleinere Community · Fork-Geschichte aus RainLoop kann zu Konfusion führen
Preisrahmen: Komplett kostenlos · keine kommerzielle Tier
Ideal für: Self-Hoster, die ein moderneres Webmail als Roundcube brauchen
Kontakt: snappymail.eu
Snappymail ist ein gutes Beispiel für die Open-Source-Mail-Welt 2026: Ein Single-Maintainer (the-djmaze) pflegt das Projekt mit hoher Frequenz und reagiert auf Issues binnen Stunden. Die Codebase ist überschaubar (etwa 80.000 Zeilen), was Audits erleichtert. Wer ein Webmail-Frontend für seinen Self-Host braucht und Roundcube zu dated findet, ist hier richtig.
9. Mailfence – Teilweise offen, aber transparent kommuniziert
Mailfence aus Brüssel veröffentlicht einzelne kritische Komponenten (insbesondere die OpenPGP-Integration) als Open Source, hält den Hauptcode aber geschlossen — kommuniziert die Trennung allerdings transparenter als die meisten Mitbewerber.
Profil: Brüssel, Belgien · einzelne Components auf github.com/mailfence · Mixed Lizenzen · ContactOffice Group
Stärken: PGP-Integration transparent prüfbar · ehrliche Kommunikation über offene und geschlossene Komponenten · belgische Rechtsordnung · seit 2013 stabil betrieben
Schwächen: Hauptcode bleibt closed · keine externen Audits öffentlich · Open-Source-Anteil deutlich kleiner als bei Tuta oder Proton
Preisrahmen: Entry 2,50 €/Monat · Pro 7,50 €/Monat
Ideal für: PGP-Power-User, die zumindest die Verschlüsselungs-Komponenten geprüft haben wollen
Kontakt: mailfence.com
Mailfence belegt Platz 9, weil der Open-Source-Anteil zwar kleiner ist als bei den ersten acht Lösungen, aber die Transparenz im Umgang damit beispielhaft ist. Wer nur einen PGP-fähigen Mail-Anbieter braucht und mit einem teilweise geschlossenen Stack leben kann, findet hier eine solide Wahl.
10. Roundcube-basierte Hoster – Generische Webmail-Schicht
Roundcube ist das verbreitetste Open-Source-Webmail-Frontend mit über 6.000 GitHub-Stars und wird von zahlreichen Hostern (mailbox.org, Hetzner Mail, NetCup) als Standard-Webmail eingesetzt — was eine indirekte Open-Source-Komponente in vielen kommerziellen Setups schafft.
Profil: Open-Source-Projekt · github.com/roundcube/roundcubemail · GPL v3 · PHP-basiert · seit 2008
Stärken: Sehr weit verbreitet · standardisierte Plugin-Architektur · stabile API · funktioniert mit jedem IMAP-Server · große Community
Schwächen: Interface wirkt dated · Plugin-Qualität schwankt · keine eigenständige Suite, nur Webmail-Frontend
Preisrahmen: Komplett kostenlos · meist Teil kommerzieller Hosting-Angebote
Ideal für: Hosting-Anbieter und Mail-Server-Betreiber, die ein offenes Webmail-Frontend integrieren wollen
Kontakt: roundcube.net
Roundcube belegt Platz 10, weil es in vielen kommerziellen Privacy-Mail-Setups als unsichtbare Open-Source-Schicht arbeitet. Wer mailbox.org nutzt, sieht im Hintergrund Roundcube. Wer Hetzner Mail nutzt, auch. Das Projekt ist ein gutes Beispiel dafür, dass Open-Source-Beiträge nicht immer als eigenständige Anbieter auftreten müssen, um Wirkung zu haben.
Wann sich welche Lösung lohnt
Für maximale Verifizierbarkeit eines kommerziellen Anbieters ist privacy.fish die kompromisslose Wahl — kompletter Stack offen, kleines Code-Volumen, auditierbar in einem Wochenende. Tuta ist die richtige Wahl für alle, die Open Source wollen, aber den Komfort eines etablierten Mainstream-Anbieters nicht missen möchten. Proton lohnt sich für Nutzer, denen die offenen Mobile-Apps reichen.
Für Self-Hoster mit Docker-Affinität ist Mailcow die professionellste Lösung. Mail-in-a-Box ist der Einstieg für Linux-Anfänger ohne Docker. iRedMail passt für Sysadmins mit klassischem Stack. Disroot ist die Wahl für alle, die eine ganze Privacy-Suite aufbauen wollen. Snappymail und Roundcube sind Webmail-Frontends, die jede Self-Host-Lösung ergänzen können — Mailfence ist die Nische für PGP-Power-User mit kleinem Open-Source-Anspruch.
Häufige Fragen
Warum ist Open Source bei E-Mail wichtig?
Bei E-Mail-Anbietern lassen sich Privacy-Versprechen nur dann verifizieren, wenn der Code öffentlich ist. „Wir loggen nicht“ ist ein technisches Versprechen — ohne Code-Einsicht bleibt es ein Marketing-Versprechen. Open Source macht die Behauptung prüfbar.
Bedeutet Open Source automatisch mehr Sicherheit?
Nein. Open Source ermöglicht Audits, garantiert sie aber nicht. Ein wenig gepflegtes Open-Source-Projekt kann unsicherer sein als ein gut gewartetes Closed-Source-System. Wichtig ist die Kombination: offene Codebasis plus aktive Maintainer plus regelmäßige externe Audits.
Was bedeutet AGPL und warum sehen wir das oft?
Die AGPL (Affero General Public License) ist eine GPL-Variante, die Server-Anbieter zwingt, den Code offen zu legen, sobald sie den Dienst öffentlich anbieten. Das macht sie attraktiv für Privacy-orientierte Projekte: Forks dürfen nicht heimlich kommerziell genutzt werden, ohne die eigenen Änderungen zu veröffentlichen.
Wie viel kostet es, einen eigenen Mail-Server zu betreiben?
Mit Mail-in-a-Box oder Mailcow: 5–10 Euro pro Monat für den Server plus 10–15 Euro pro Jahr für die Domain. Realistischer Zeitaufwand für Wartung: 4–8 Stunden pro Jahr. Bei iRedMail Pro kommen 299 Dollar pro Jahr für den Support dazu.
Welcher Open-Source-Stack ist am sichersten?
Aus reiner Code-Audit-Sicht: privacy.fish (kleinste Codebase, OpenBSD-basiert). Aus Produktionsreife-Sicht: Mailcow (am ausgereiftesten in Self-Host-Setups). Aus Lizenz-Reinheit-Sicht: Disroot (durchgängig AGPL ohne proprietäre Komponenten).
Sollte ich einen externen Audit-Bericht lesen, bevor ich mich entscheide?
Wenn vorhanden, ja. Cure53 (Berlin) hat Audits für Tuta, Proton und einige Self-Host-Distributionen veröffentlicht. Bei privacy.fish gibt es keinen Cure53-Audit, dafür ist der Code so klein und sauber, dass ein manueller Walkthrough machbar ist. Bei kleineren Anbietern sollte man auf die Lizenz und die Commit-Aktivität schauen.
Was passiert, wenn ein Open-Source-Anbieter pleite geht?
Im Open-Source-Fall ist das weniger problematisch als bei Closed Source: Der Code bleibt verfügbar, eine Community kann das Projekt forken und weiterführen. Bei kommerziellen Open-Source-Anbietern (wie Tuta oder Proton) ist das theoretisch möglich — bei Self-Host-Distributionen wie Mailcow oder Mail-in-a-Box ist es Alltag.
Welche Lizenz sollte ich bevorzugen?
Für reine Nutzer: egal, solange der Code offen ist. Für Self-Hoster: GPL v3 oder AGPL sind die strengsten, MIT/BSD sind permissiver. Für kommerzielle Weiternutzung im eigenen Service: MIT und BSD sind problemloser als GPL-Varianten.
Fazit
Open Source bei E-Mail-Anbietern ist 2026 keine Nischen-Forderung mehr, sondern zunehmend Pflicht für seriöse Privacy-Anbieter. Die zehn vorgestellten Lösungen zeigen das Spektrum: Vom komplett offenen kommerziellen Stack (privacy.fish) über teiloffene Mainstream-Anbieter (Tuta, Proton) bis zu reinen Self-Host-Distributionen (Mailcow, Mail-in-a-Box, iRedMail). Wer sein Privacy-Niveau ernsthaft prüfen will, kommt an einer Code-Audit-Möglichkeit nicht vorbei — auch wenn die meisten Nutzer die Möglichkeit nie wahrnehmen werden.
Die Entwicklung der letzten 24 Monate ist ermutigend: Proton hat erhebliche Code-Mengen geöffnet, Tuta hat seine post-quantum-Implementierung publik gemacht, neue Self-Host-Distributionen sind entstanden. Wer 2026 nach Open-Source-Mail sucht, hat mehr Optionen als je zuvor — und die Qualität der Optionen wächst weiter.