E-Mail-Verschlüsselung: TLS, Ende-zu-Ende und DSGVO

Kategorien: Datenschutz und Security

E-Mails gelten oft als Postkarte: Wer unterwegs mitliest, sieht alles. Die E-Mail-Verschlüsselung entscheidet, ob das stimmt. Es wird beschrieben, was Transportverschlüsselung und Ende-zu-Ende-Verschlüsselung leisten, was Gerichte und Aufsichtsbehörden dazu gesagt haben und welche Technik in der Praxis den Unterschied macht.

Der berücksichtigt Urteile, Technik und Pflichten großer Mail-Anbieter bis Ende Oktober 2026.

Der Aufbau des Beitrags folgt dem Weg einer Mail. Zuerst kommen Maßstab und Begriffe, dann die Rechtsprechung und die Sicht der Aufsichtsbehörden. Danach geht es um die Technik: Transportverschlüsselung, Prüfung im Mail-Header, Schutz vor gefälschten Absendern und Ende-zu-Ende-Verfahren wie S/MIME und OpenPGP. Am Ende steht eine Entscheidungshilfe, welche Verschlüsselung zu welcher Art von Mail passt.

E-Mail-Verschlüsselung und DSGVO: Was der Maßstab ist

Personenbezogene Daten müssen so verarbeitet werden, dass sie vor unbefugtem Zugriff geschützt sind. Das steht in Art. 5 Abs. 1 lit. f DSGVO. Nach Absatz 2 muss der Verantwortliche das auch nachweisen können. Wie der Schutz konkret aussieht, regelt Art. 32 DSGVO: Es sind Maßnahmen nach dem Stand der Technik zu treffen, die dem Risiko angemessen sind. Ein bestimmtes Verfahren schreibt die Vorschrift nicht vor. Die Verschlüsselung wird dort lediglich als mögliche Maßnahme genannt.

Besondere Kategorien von Daten wie Gesundheitsdaten fallen unter Art. 9 DSGVO. Dort ist der Schutzbedarf von vornherein höher. Aber auch scheinbar harmlose Mails enthalten personenbezogene Daten: Schon die Absenderadresse mit Klarnamen genügt.

Die Rechtslage lässt sich 2026 so zusammenfassen: Eine pauschale Pflicht zur Ende-zu-Ende-Verschlüsselung für jede Mail gibt es nicht. Eine pauschale Freigabe für unverschlüsselte Mails ebenso wenig. Entscheidend sind das Risiko für die Betroffenen und die Frage, was nach dem Stand der Technik zumutbar ist. Wer personenbezogene Daten per Mail verschickt, braucht deshalb eine begründete Entscheidung, die sich im Zweifel vorlegen lässt.

Transportverschlüsselung, Ende-zu-Ende und Signatur sauber getrennt

Im Alltag werden drei Dinge vermischt, die Unterschiedliches leisten.

Die Transportverschlüsselung sichert die Verbindung zwischen zwei Stationen ab. Sie arbeitet mit TLS (Transport Layer Security), dem Nachfolger von SSL. Auf jeder Teilstrecke wird der Inhalt verschlüsselt übertragen. Auf dem Mailserver selbst liegt er dagegen im Klartext, denn der Server muss die Mail ja verarbeiten und speichern.

Die Ende-zu-Ende-Verschlüsselung (E2E) verschlüsselt den Inhalt schon im Mailprogramm des Absenders. Nur der Empfänger kann ihn entschlüsseln. Server dazwischen sehen nur Daten, mit denen sie nichts anfangen können. Dafür haben sich S/MIME und OpenPGP etabliert.

Die Signatur ist etwas anderes: Sie verschlüsselt nichts, sondern belegt, von wem eine Mail stammt und dass sie unterwegs nicht verändert wurde. Beim Austausch von Schlüsseln spielt sie eine wichtige Rolle, weil die öffentlichen Schlüssel meist über signierte Mails weitergegeben werden.

Eine Grenze haben beide Verfahren gemeinsam: Betreff, Absender und Empfänger bleiben in der Regel lesbar. Die Orientierungshilfe der Datenschutzkonferenz weist darauf hin, dass auch diese Umstände der Kommunikation schutzbedürftig sein können.

Rechtsprechung zur E-Mail-Verschlüsselung: Wann Transportverschlüsselung reicht

Gerichte haben die Frage in den vergangenen Jahren mehrfach entschieden, mit scheinbar widersprüchlichen Ergebnissen. Bei genauem Hinsehen folgen die Urteile einer Linie: Je größer der mögliche Schaden, desto höher die Anforderungen.

Der älteste Fall in der Reihe stammt aus dem Jahr 2020. Das Verwaltungsgericht Mainz entschied am 17.12.2020 (Az. 1 K 778/19.MZ), ob ein Rechtsanwalt E-Mails an Mandanten nur transportverschlüsselt versenden darf. Die Entscheidung wird nach Art. 32 und Art. 5 DSGVO eingeordnet. Im Leitsatz heißt es, dass bei der E-Mail-Kommunikation von Rechtsanwälten die Transportverschlüsselung ausreicht. Ende-zu-Ende ist demnach nur bei erhöhtem Risiko im Einzelfall nötig.

Ebenfalls oft zitiert, aber nur eingeschränkt einschlägig ist der Beschluss des Bundesgerichtshofs vom 22.03.2021 (AnwZ (Brfg) 2/20). Er betrifft das besondere elektronische Anwaltspostfach. Dessen Sicherheitsarchitektur beruht auf eigenen Hardware-Sicherheitsmodulen. Ein Anspruch auf Ende-zu-Ende-Verschlüsselung besteht dort nicht. Auf gewöhnliche E-Mails lässt sie sich kaum übertragen.

Der Fall des Oberlandesgerichts Karlsruhe zeigt die Linie des Geschäftsverkehrs. Ein Hacker hatte das Mailkonto eines Autohändlers übernommen und dem Käufer eine manipulierte Rechnung mit anderer Kontonummer geschickt. Der Käufer zahlte auf das falsche Konto. Das Gericht entschied am 27.07.2023 (Az. 19 U 83/22), dass sich die erforderlichen Schutzmaßnahmen nach den berechtigten Sicherheitserwartungen der Geschäftspartner richten. Die Zahlung an den Betrüger befreite den Käufer nicht, er musste ein zweites Mal zahlen. Das Landgericht Mosbach hatte als Vorinstanz noch anders entschieden.

Das Oberlandesgericht Schleswig kam im Dezember 2024 zu einem anderen Ergebnis. Auch hier ging es um eine manipulierte Rechnung, diesmal gegenüber einem Verbraucher und über rund 15.000 Euro. Nach der Pressemitteilung des Gerichts hätte die Rechnung mit einer Ende-zu-Ende-Verschlüsselung verschickt werden müssen, weil ein Hackerangriff ein vorhersehbares Risiko sei. Der Kunde konnte dem Zahlungsanspruch einen Schadensersatzanspruch entgegenhalten und musste nicht erneut zahlen. Das Gericht hatte die Revision zugelassen, nach seiner Pressemitteilung ist das Urteil dennoch rechtskräftig. Eine Einordnung dieser Entscheidungen, einschließlich eines Urteils des Verwaltungsgerichts Düsseldorf vom 02.04.2026 (29 K 7351/23), findet sich im Beitrag Sicherheitsvorkehrungen beim Versand von E-Mails.

Wie passt das zusammen? Entscheidend sind offenbar Schutzbedarf und Schadenspotenzial. Zwischen Unternehmen akzeptierten die Gerichte bisher eher Standardmaßnahmen. Wo ein Verbraucher eine hohe Summe auf ein Konto überweist, das ihm nur eine ungeschützte Mail nennt, wird mehr verlangt. Der Verfahrensname ist dabei zweitrangig. Wichtig ist, dass die Maßnahme das konkrete Risiko tatsächlich senkt. Offen bleibt etwa, ob die Einwilligung des Empfängers in eine schwächere Verschlüsselung genügt. Dazu liegt bisher keine belastbare Entscheidung vor.

DSK-Orientierungshilfe und BSI: der Maßstab der Aufsichtsbehörden

Die Konferenz der unabhängigen Datenschutzaufsichtsbehörden (DSK) hat am 27.05.2021 die Orientierungshilfe „Maßnahmen zum Schutz personenbezogener Daten bei der Übermittlung per E-Mail“ beschlossen, Stand 16.06.2021. Bayern stimmte dagegen. Das Papier ist öffentlich abrufbar und trifft eine klare Unterscheidung.

Bei normalem Risiko verlangt die Orientierungshilfe eine obligatorische Transportverschlüsselung, orientiert an der Technischen Richtlinie TR-03108-1 des BSI. Bei hohem Risiko sollen Verantwortliche regelmäßig Ende-zu-Ende-Verschlüsselung und eine qualifizierte Transportverschlüsselung einsetzen, also zum Beispiel mit DANE oder DNSSEC. Ein Berufsgeheimnis gilt dabei als Indiz für ein hohes Risiko, das im Einzelfall geprüft werden muss.

Bußgelder wegen unverschlüsselter Mails sind selten, die Aufsichtsbehörden wirken weniger über Sanktionen als über Papiere wie dieses. Als Maßstab hat die Orientierungshilfe dennoch Gewicht: In den Streitigkeiten um manipulierte Rechnungen wurde die Frage diskutiert, ob die Hinweise der Aufsichtsbehörden herangezogen werden können. Das Oberlandesgericht Karlsruhe hielt sie im dortigen Fall für nicht einschlägig. Verbindlich ist die Orientierungshilfe nicht. Wer davon abweicht, sollte es aber begründen können.

Das BSI beschreibt in der TR-03108 den sicheren E-Mail-Transport für Provider, einschließlich Zertifizierung. Für Mailserver-Betreiber ist sie die technische Messlatte. Ergänzend gibt es mit der TR-03182 eine Empfehlung zur E-Mail-Authentisierung.

Transportverschlüsselung richtig umsetzen: TLS 1.3, Port 465, MTA-STS und DANE

Mailprogramme und Server sprechen mehrere Protokolle. SMTP (Simple Mail Transfer Protocol) ist seit 1982 im Einsatz und überträgt Mails. ESMTP ist die erweiterte Variante. Die Kürzel im Mail-Header zeigen, was auf der jeweiligen Teilstrecke geschah: ESMTPS heißt, dass TLS ausgehandelt wurde. ESMTPSA bedeutet zusätzlich, dass sich der Absender mit Benutzername und Passwort angemeldet hat.

Bei der Aushandlung gibt es zwei Wege. Beim impliziten TLS beginnt die Verbindung sofort verschlüsselt. Für den Mailversand aus dem Programm heraus ist dafür nach RFC 8314 der Port 465 vorgesehen, für den Abruf IMAP über Port 993 oder POP3 über Port 995. Bei STARTTLS startet die Verbindung unverschlüsselt, und beide Seiten verhandeln erst danach den Wechsel. Dieser Schritt kann von Angreifern gestört werden. Die Studie „Why TLS is better without STARTTLS“ (USENIX Security 2021) beschreibt Downgrade- und Injection-Angriffe. Deshalb gilt implizites TLS als die bessere Wahl, auch wenn Port 587 mit STARTTLS vielerorts weiter parallel angeboten wird.

Zu den Versionen: TLS 1.0 und 1.1 sind seit RFC 8996 (März 2021) offiziell abgekündigt. TLS 1.2 ist die Untergrenze, TLS 1.3 das Ziel, so auch in der Technischen Richtlinie BSI TR-02102-2.

Ein Problem bleibt zwischen den Servern. Dort läuft die Verschlüsselung meist über STARTTLS und ist oft nur opportunistisch: Klappt es nicht, fällt die Verbindung auf unverschlüsselt zurück. Viele Mailserver bieten einen Modus, der die Zustellung ablehnt, wenn kein TLS zustande kommt. Auch das läuft in der Regel über STARTTLS und ist kein implizites TLS.

Zwei Verfahren schließen die Lücke:

• MTA-STS (RFC 8461): Die Empfängerdomain veröffentlicht eine Richtlinie, dass TLS mit gültigem Zertifikat Pflicht ist. Sendende Server halten sich daran. Es braucht kein DNSSEC. Es gibt die Modi testing und enforce. Berichte über Probleme liefert TLS-RPT.
• DANE: Im DNS wird per TLSA-Eintrag festgelegt, welches Zertifikat der Empfängerserver verwendet. Das setzt DNSSEC voraus. DANE sichert die Echtheit des Empfängerservers gegen Downgrade und Man-in-the-Middle.

Für Exchange Online ist laut Microsoft eingehendes SMTP mit DANE seit dem 22.10.2024 allgemein verfügbar, standardmäßig aber ausgeschaltet. MTA-STS wird nach der Dokumentation von Microsoft unterstützt. Ob die eigene Domain solche Richtlinien veröffentlicht, lässt sich mit Online-Werkzeugen prüfen, mehr dazu im nächsten Abschnitt.

Verschlüsselung prüfen: Mail-Header lesen und Empfängerserver testen

Ob eine Mail tatsächlich verschlüsselt ankam, steht im Mail-Header. Bei klassischen Outlook-Versionen öffnet ein Doppelklick auf die Mail, danach Datei, Eigenschaften, das Feld Internetkopfzeilen. Im neuen Outlook und im Webmailer sieht der Weg anders aus. Die Menüführung ändert sich mit den Versionen, deshalb lohnt der Blick in die Hilfe des jeweiligen Programms.

In den Kopfzeilen interessieren die Received-Zeilen. Jeder Server, der die Mail weiterreicht, ergänzt eine. Moderne Server tragen dort Protokollversion und Verfahren ein, etwa TLSv1.3 und TLS_AES_256_GCM_SHA384. Der Auszug unten ist nachgebaut, mit Platzhaltern statt echter Adressen.

Der Header ist allerdings kein lückenloser Nachweis im Sinne von Art. 5 Abs. 2. Er belegt nur die Teilstrecken, auf denen ein Server die Zeile ergänzt hat. Wo Weiterleitungen oder Gateways im Spiel sind, bleibt eine Lücke. Als Baustein einer Dokumentation taugt er trotzdem.

Vor dem Versand lässt sich testen, was ein Empfängerserver kann. CheckTLS fragt die Fähigkeiten ab, ohne eine Mail zu schicken, und zeigt unter anderem, ob TLS angeboten wird und ob ein TLSA-Eintrag für DANE existiert. Das Ergebnis „no TLSA“ ist bei vielen Domains üblich. Der Dienst internet.nl prüft STARTTLS, DANE sowie SPF, DKIM und DMARC. MTA-STS ist laut Dokumentation nicht Teil der Bewertung.

Bei einem negativen TLS-Ergebnis hilft der Hinweis an den Empfänger. Alternativ kommt ein Portal oder ein verschlüsselter Anhang in Frage, dazu weiter unten mehr. Für die eigene Website und deren Schutzmaßnahmen bietet der DSGVO Webseiten-Check eine erste Orientierung. Sicherheitsprüfungen für Domains, einschließlich der E-Mail-Authentisierung, finden sich bei den Web Security Checks.

SPF, DKIM und DMARC: Schutz vor gefälschten Absendern

Verschlüsselung schützt vor Mitlesen, nicht vor Fälschung. Genau darum ging es in den Rechnungsfällen: Ein Angreifer schickt eine Mail, die wie vom echten Absender aussieht, oder nutzt ein gekapertes Postfach. Gegen gefälschte Absender helfen drei Verfahren, die zusammenwirken.

Der Druck zur Einführung kam zuletzt von den großen Anbietern. Google und Yahoo verlangen seit dem 01.02.2024 von allen Absendern unter anderem SPF oder DKIM, TLS und eine niedrige Spam-Rate. Wer mehr als 5.000 Mails pro Tag an Gmail-Adressen schickt, braucht SPF, DKIM und mindestens eine DMARC-Richtlinie. Microsoft hat für Hochvolumen-Absender an Outlook.com, Hotmail und Live ab dem 05.05.2025 ähnliche Anforderungen eingeführt. Die Regeln im Einzelnen stehen in der Dokumentation von Google.

Die DSK-Orientierungshilfe sieht vor, dass beim Empfang DKIM und DMARC geprüft werden. Hier zeichnet sich eine Entwicklung ab, an der Verantwortliche besser nicht vorbeischauen. Weitere Hintergründe zu gefälschten Nachrichten liefert der Beitrag E-Mails, Phishing und die Echtheit elektronischer Nachrichten. Zum Umgang mit unbekannten Absendern und Anhängen gibt es einen eigenen Beitrag.

Ende-zu-Ende mit S/MIME und OpenPGP: der Stand 2026

Wer über die Transportverschlüsselung hinausgehen will oder muss, hat zwei etablierte Verfahren. Beide verschlüsseln den Inhalt im Mailprogramm. Beide brauchen Schlüssel, die zuvor ausgetauscht werden. Die Orientierungshilfe der DSK nennt Ende-zu-Ende den „durchgreifendsten Schutz“, weil er auch ruhende Daten schützt.

S/MIME

S/MIME arbeitet mit Zertifikaten, die eine Zertifizierungsstelle ausstellt. Sie sind in Outlook, Apple Mail und vielen anderen Programmen direkt nutzbar. Den öffentlichen Schlüssel des Empfängers erhält der Absender meist über eine signierte Mail, aus der sich das Zertifikat übernehmen lässt.

Bei den Zertifikaten hat sich seit 2021 vieles geändert. Die früher üblichen Klassen 1 bis 4 sind überholt. Seit dem 01.09.2023 gelten die Baseline Requirements des CA/Browser Forums mit vier Typen, die sich nach dem Prüfumfang unterscheiden: Mailbox-, Organization-, Sponsor- und Individual-validated. Den aktuellen Stand der Anforderungen veröffentlicht das Forum selbst.

OpenPGP

OpenPGP arbeitet ohne zentrale Zertifizierungsstelle. Jeder erzeugt ein eigenes Schlüsselpaar. Die Echtheit wird über Fingerprints oder die Beglaubigung durch Dritte geprüft. Die DSK weist ausdrücklich darauf hin, dass die bloße Veröffentlichung eines Schlüssels auf einem Schlüsselserver kein Indiz für seine Echtheit ist. Praktisch ist der Web Key Directory, über den eine Domain ihre Schlüssel selbst bereitstellt. Eine Einführung zum Signieren liefert der Beitrag E-Mails mit PGP signieren und verschicken.

Der Standard hat sich verändert: RFC 9580 (Juli 2024) löst RFC 4880 ab. Er bringt neue Schlüsselformate, moderne Verfahren wie X25519 und Ed25519 sowie authentifizierte Verschlüsselung. Daneben pflegt das GnuPG-Projekt mit LibrePGP eine abweichende Linie. Das verkompliziert die Lage. Thunderbird nutzt eine eigene Bibliothek namens RNP statt GnuPG, und Mozilla dokumentiert Probleme bei Schlüsseln mit Merkmalen, die RNP nicht unterstützt. Schlüssel wandern also nicht immer reibungslos zwischen den Programmen.

Praxis mit Outlook und Thunderbird

In der Praxis zeigt sich oft ein Unterschied zwischen Ein- und Mehrkonten-Betrieb. Das Plugin GpgOL aus dem Paket Gpg4win lässt sich in Outlook einrichten und funktioniert mit einem Konto. Bei mehreren Konten erscheint dagegen bei jedem Versand eine Abfrage, und die Zuordnung der Schlüssel kann durcheinandergeraten. Für Umgebungen mit vielen Konten ist das ein Hindernis.

Aktuell ist Gpg4win in Version 5.1.1 (veröffentlicht am 23.09.2026) erhältlich, wie die Projektseite zeigt. GpgOL läuft im klassischen Outlook. Ob und wann es das neue Outlook unterstützt, ist laut einem Beitrag im GnuPG-Forum offen. In Thunderbird ist OpenPGP seit Version 78 eingebaut, ein Zusatzprogramm entfällt. Die Einrichtung erfolgt in den Kontoeinstellungen unter Ende-zu-Ende-Verschlüsselung. Wer nur ein Konto nutzt, kommt damit schnell zum Ziel.

Das BSI hat im Dezember 2025 zwölf kostenlose E-Mail-Programme untersucht. Laut Pressemitteilung unterscheiden sich die Programme in der Unterstützung von Ende-zu-Ende-Verschlüsselung. Sicherheitsfunktionen sind oft nicht von Haus aus aktiv.

Ein Nebenaspekt ist der Angriff Efail aus dem Jahr 2018. Er nutzte aktive HTML-Inhalte in Mails aus, um entschlüsselte Texte nach außen zu leiten. Als Gegenmaßnahme gelten aktuelle Programme und eine deaktivierte HTML-Darstellung bei verschlüsselten Mails. Eine Erklärung bietet die Seite efail.de. Panik ist nicht angebracht, aber das Beispiel zeigt, dass auch gute Kryptografie an der Umsetzung scheitern kann.

Portale, Gateways und Microsoft-Verschlüsselung als Alternativen

Das größte Hindernis für Ende-zu-Ende ist der Schlüsselaustausch mit jedem Gegenüber. Deshalb setzen viele Organisationen auf Lösungen, bei denen der Aufwand beim Absender liegt.

• Gateway-Verschlüsselung: Ein Server im Unternehmen übernimmt S/MIME oder PGP. Der Schutz reicht dann bis zum Gateway des Empfängers. Im Postfach liegt die Mail, je nach Einrichtung, entschlüsselt. Die Vertrauensfrage verschiebt sich auf den Betreiber des Gateways.
• Portal: Die Mail enthält nur einen Hinweis. Abgeholt wird die Nachricht im Browser nach einer Anmeldung. Auch die DSK-Orientierungshilfe nennt ein Webportal als Kommunikationsweg gegenüber Betroffenen.
• Microsoft Purview Message Encryption: Im neuen Outlook mit passender Lizenz nutzbar. Empfänger außerhalb von Microsoft erhalten eine Öffnungsanleitung. Auf derselben Nachricht lässt sie sich nicht mit S/MIME kombinieren.
• Passwortgeschützter Anhang: Ein Archiv mit AES-256, etwa mit 7-Zip erzeugt, dient als Umschlag. Das Passwort geht über einen anderen Kanal, zum Beispiel per Telefon (Medienbruch). SMS ist als Kanal umstritten und sollte nur mit Einschränkung genutzt werden.

Wer ein Gateway oder Portal bei einem Dienstleister betreibt, schließt dafür in der Regel einen Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO ab. Mit Microsoft 365 verbundene Risiken beim Konto selbst beschreibt der Beitrag zum Token-Spraying.

Die Abwägung ist nüchtern: Wer die Schlüsselverwaltung scheut, bekommt mit Portal oder Gateway einen praktikablen Mittelweg. Er bringt Abstriche gegenüber echter Ende-zu-Ende-Verschlüsselung, ist aber deutlich besser als eine Klartext-Mail mit sensiblem Inhalt.

Post-Quanten-Kryptografie bei E-Mail: was heute schon zählt

Ende-zu-Ende hat eine Eigenschaft, die oft übersehen wird: Perfect Forward Secrecy gibt es dabei von Haus aus nicht. Die DSK schreibt dazu, dass abgefangene Mails aufbewahrt und bei Offenlegung des privaten Schlüssels später entschlüsselt werden können. Mit künftigen Quantencomputern könnte dieses Szenario auch ohne Schlüsselverlust eintreten.

Die Standardisierung läuft. Mit RFC 9936 (März 2026) liegt ein Standard für ML-KEM in CMS vor, der Grundlage für S/MIME. Für TLS 1.3 sieht die BSI TR-02102-2 hybride Verfahren vor, die klassische und Post-Quanten-Verfahren kombinieren. Für den Alltag ergibt sich daraus kein Handlungszwang. Wer Inhalte versendet, die auch in 15 Jahren noch vertraulich sein müssen, sollte das Thema aber im Blick behalten.

Fehlversand, Datenpanne und Telefax: die Grenzen der Verschlüsselung

Ein Nachteil der Transportverschlüsselung gilt bis heute: Bei einer falschen Empfängeradresse nützt sie nichts. Die Mail landet verschlüsselt auf dem falschen Server und liegt dort im Klartext. Bei Ende-zu-Ende ist das anders, sofern an den vorgesehenen Empfänger adressiert wurde. Die DSK nennt individuelle Adressierung ausdrücklich als Maßnahme.

Daher zählt der organisatorische Teil. Dazu gehören abgeschaltete Autovervollständigung bei sensiblen Empfängern, ein Vier-Augen-Prinzip bei heiklen Inhalten und die Prüfung der Adresse vor dem Absenden. Ob ein Fehlversand als Datenpanne zu melden ist, hängt vom Risiko ab und gehört in ein eigenes Verfahren.

Auch das Telefax taucht in dieser Debatte auf. Der Landesbeauftragte für Datenschutz und Informationsfreiheit Bremen hat das Fax auf einer Seite zu Orientierungshilfen mit unverschlüsselten Mails verglichen. Das Oberverwaltungsgericht Lüneburg hat in einem Beschluss von 2020 (11 LA 104/19) bei besonders sensiblen Daten eine Einzelfallprüfung für nötig gehalten.

Welche Verschlüsselung für welche E-Mail: Entscheidungshilfe

Aus den Urteilen und Leitlinien lässt sich eine Faustregel ableiten. Je höher Schadenspotenzial und Geheimhaltungsbedarf, desto eher kommen Ende-zu-Ende oder ein Portal in Betracht. Bei Rechnungen gilt zusätzlich: Eine Änderung der Bankverbindung wird über einen zweiten Kanal bestätigt, etwa per Telefon.

Die Tabelle dient zur Orientierung und ist keine Rechtsberatung. Die Einstufung des Risikos liegt beim Verantwortlichen und gehört dokumentiert. Dabei hilft eine kurze Prüfung: Was wäre der schlimmste realistische Schaden für die Betroffenen? Wie wahrscheinlich ist er? Welche Maßnahme senkt ihn spürbar?

Fazit

Transportverschlüsselung ist Pflichtprogramm und bei normalem Risiko nach DSK und Rechtsprechung meist ausreichend, wenn sie konsequent und nach dem Stand der Technik eingerichtet ist. Dazu zählen TLS 1.2 oder besser 1.3, implizites TLS im Mailprogramm sowie MTA-STS oder DANE auf Serverseite. Bei hohem Risiko wird Ende-zu-Ende oder eine gleichwertige Lösung erwartet.

Die E-Mail-Verschlüsselung bleibt ein Thema mit Abwägungen. Schlüsselverwaltung ist mühsam, Portale sind ein pragmatischer Mittelweg, und gegen Betrug helfen SPF, DKIM, DMARC sowie ein zweiter Kanal bei Zahlungsdaten mindestens ebenso wie Kryptografie.