E-Mail-Verschlüsselung und Archivierung: Was die DSK fordert

Transportverschlüsselung ist kein optionales Extra mehr. Die Datenschutzkonferenz (DSK) hat in ihrer Orientierungshilfe vom 16. Juni 2021 klargestellt, dass der Versand unverschlüsselter E-Mails mit personenbezogenen Inhalten gegen Art. 32 DSGVO verstößt. Für viele Unternehmen stellt sich damit eine unmittelbar anschließende Folgefrage: Wenn E-Mails verschlüsselt übertragen oder sogar Ende-zu-Ende-verschlüsselt gespeichert werden: wie lassen sie sich dann noch GoBD-konform archivieren?

Dieser Artikel richtet sich an IT-Administratoren, Datenschutzbeauftragte und CISOs, die beide Anforderungen gleichzeitig erfüllen müssen: DSGVO-konforme Verschlüsselung nach den Vorgaben der DSK und NIS2 auf der einen Seite, revisionssichere und durchsuchbare Archivierung nach GoBD auf der anderen.

Transportverschlüsselung vs. Ende-zu-Ende-Verschlüsselung

Bevor die Anforderungen der DSK eingeordnet werden können, ist eine klare Abgrenzung der beiden grundlegend verschiedenen Verschlüsselungskonzepte notwendig.

Transportverschlüsselung (TLS) sichert den Übertragungsweg zwischen zwei Mailservern. Das bedeutet: Die E-Mail liegt auf dem sendenden Server im Klartext vor, wird während der Übertragung verschlüsselt und liegt auf dem empfangenden Server wieder im Klartext vor. Für den Empfänger-Mailserver ist der Inhalt vollständig lesbar. TLS schützt gegen das Abfangen von Nachrichten auf dem Transportweg (sogenannte Man-in-the-Middle-Angriffe), nicht aber gegen den Zugriff auf die Inhalte beim Betreiber des Mailservers.

Ende-zu-Ende-Verschlüsselung (E2E) mit S/MIME oder OpenPGP geht weiter: Die E-Mail wird bereits auf dem Rechner des Absenders verschlüsselt und kann nur vom Besitzer des privaten Schlüssels des Empfängers entschlüsselt werden. Der Mailserver des Empfängers, der E-Mail-Provider und alle Zwischenstationen sehen nur verschlüsselte Inhalte. Diese Nachrichten landen auch im Postfach des Empfängers im verschlüsselten Zustand.

Genau hier entsteht das Archivierungsproblem: Ein Archivsystem, das E-Mails direkt aus dem Postfach oder vom Mailserver abgreift, erhält bei Ende-zu-Ende-verschlüsselten Nachrichten nur Chiffretext und kann diesen weder indexieren noch für eine spätere Volltextsuche oder einen GoBD-konformen Datenzugriff nach Z1/Z2/Z3 aufbereiten.

DSK Orientierungshilfe 2021: Was genau gefordert wird

Die DSK-Orientierungshilfe "E-Mail-Verschlüsselung" vom 16. Juni 2021 ist das maßgebliche Dokument für deutsche Unternehmen. Sie konkretisiert, welche technischen und organisatorischen Maßnahmen nach Art. 32 DSGVO beim E-Mail-Versand erforderlich sind.

Die DSK unterscheidet dabei nach dem Schutzbedarf der übermittelten Inhalte:

Normaler Schutzbedarf (typische Geschäftskorrespondenz ohne besonders sensible personenbezogene Daten): Opportunistische TLS-Verschlüsselung (STARTTLS) gilt als Mindestmaß, ist aber nicht ausreichend, weil sie durch einen Angreifer auf dem Transportweg ausgehebelt werden kann (STRIPTLS-Angriff). Die DSK empfiehlt für diesen Bereich erzwungenes TLS, idealerweise mit DANE (DNS-based Authentication of Named Entities) oder MTA-STS, um die Verbindung abzusichern.

Erhöhter Schutzbedarf (E-Mails mit Gesundheitsdaten, Finanzdaten, Personalinformationen oder anderen besonders schutzbedürftigen personenbezogenen Daten): Hier ist Transportverschlüsselung allein nicht ausreichend. Die DSK fordert zusätzliche Maßnahmen, in der Praxis typischerweise S/MIME oder PGP als Ende-zu-Ende-Verschlüsselung oder alternativ den Einsatz eines verschlüsselten Kommunikationskanals (Secure File Transfer, verschlüsseltes Webportal).

Für ruhende Daten (also E-Mails, die auf Servern gespeichert sind) fordert die DSK ergänzende Maßnahmen, die über die Transportverschlüsselung hinausgehen. Konkret empfiehlt die Orientierungshilfe die Verschlüsselung gespeicherter Daten auf Serverebene und eine restriktive Zugangskontrolle. Das betrifft unmittelbar auch das E-Mail-Archiv.

NIS2: Verschlüsselung als Pflichtmaßnahme nach § 30 BSIG

Seit dem Inkrafttreten des NIS2-Umsetzungsgesetzes (NIS2UmsuCG) und der daraus resultierenden Änderung des BSI-Gesetzes (BSIG) sind Verschlüsselungspflichten für viele Unternehmen nicht mehr nur eine DSGVO-Empfehlung, sondern eine gesetzliche Anforderung mit Bußgeldtatbeständen.

§ 30 BSIG verpflichtet Betreiber wesentlicher und wichtiger Einrichtungen, geeignete technische und organisatorische Maßnahmen zum Risikomanagement zu ergreifen. In § 30 Abs. 2 Nr. 5 BSIG wird explizit die Verwendung von Kryptografie und Verschlüsselung als Maßnahme genannt, die Einrichtungen berücksichtigen müssen.

Der Anwendungsbereich ist weit: Unternehmen ab 50 Mitarbeitern oder 10 Millionen Euro Jahresumsatz in zahlreichen Sektoren (Energie, Transport, Gesundheit, digitale Infrastruktur, Finanzwesen, aber auch Hersteller und viele Dienstleister) fallen unter NIS2. Wer bisher geglaubt hat, Verschlüsselung sei optional, sollte diese Einschätzung revidieren.

Für die Kombination aus Verschlüsselung und Archivierung bedeutet NIS2: Beides muss funktionieren, und zwar gleichzeitig. Behörden prüfen im Rahmen von NIS2-Audits nicht nur, ob Verschlüsselung eingesetzt wird, sondern auch, ob die archivierten Daten selbst angemessen geschützt sind.

Das Archivierungsproblem bei Ende-zu-Ende-Verschlüsselung

Wer S/MIME oder PGP betreibt und versucht, diese E-Mails nachträglich zu archivieren, stößt auf ein strukturelles Problem: Das Archivsystem kann den Inhalt nicht lesen, solange es keinen Zugriff auf den privaten Schlüssel des Empfängers hat.

Mögliche Ansätze und ihre Grenzen:

Schlüsselhinterlegung (Key Escrow): Der private Schlüssel jedes Nutzers wird zusätzlich bei einer zentralen Stelle hinterlegt. Das Archiv kann damit eingehende verschlüsselte Nachrichten entschlüsseln und indexieren. Das Problem: Key Escrow ist komplex in der Verwaltung, stellt ein zentrales Angriffsziel dar und wird von vielen Sicherheitsrichtlinien abgelehnt. Zudem muss für jeden Nutzer und für jeden Schlüsselwechsel der Prozess neu durchgeführt werden.

Dezentrale Entschlüsselung auf dem Client: E-Mails werden erst im Client des Nutzers entschlüsselt und dann in das Archiv weitergeleitet. Das erfordert eine enge Client-Integration und ist bei IMAP-Zugriffen über verschiedene Endgeräte schwer kontrollierbar. Außerdem ist nicht sichergestellt, dass die Weiterleitung an das Archiv nicht umgangen wird.

Archivierung als Klartext nach Gateway-Verarbeitung: Dieser Ansatz ist in der Praxis der effektivste und wird nachfolgend als empfohlene Architektur beschrieben.

Architektur: Gateway-Verschlüsselung mit zentralem Archiv

Die technisch sauberste und in der Praxis bewährteste Lösung für Unternehmen, die sowohl Verschlüsselungspflichten als auch Archivierungsanforderungen erfüllen müssen, ist die Gateway-Architektur. Das Prinzip:

Eingehende E-Mail (TLS-verschlüsselt vom externen MTA)
    |
    v
[E-Mail-Gateway / Security Gateway]
    - TLS-Terminierung
    - Spam-/Virenfilter
    - Optional: S/MIME-Entschlüsselung auf Gateway-Ebene
    |
    +-----------> [Archiv] (Klartext oder re-verschlüsselt mit Archiv-Schlüssel)
    |
    v
[Interner Mailserver / Postfach des Empfängers]
    - Optional: Re-Verschlüsselung für Postfachspeicherung

Schritt 1: Eingang über TLS. Eingehende E-Mails werden ausschließlich über erzwungenes TLS entgegengenommen. Verbindungen ohne TLS werden abgewiesen. DANE oder MTA-STS stellen sicher, dass das TLS-Zertifikat des eigenen Mailservers von externen Absendern nicht gefälscht werden kann.

Schritt 2: Gateway-Verarbeitung. Der E-Mail-Gateway terminiert die TLS-Verbindung, empfängt die Nachricht im Klartext (sofern nur TLS, kein S/MIME verwendet wird) und verarbeitet sie. Bei S/MIME-verschlüsselten eingehenden Nachrichten kann das Gateway auf Gateway-Ebene mit einem organisationsweit hinterlegten Entschlüsselungsschlüssel arbeiten oder die verschlüsselte Nachricht unverändert weitergeben, wenn der Empfänger seinen Schlüssel selbst verwaltet.

Schritt 3: Archivierung vor der Auslieferung. Die Nachricht wird unmittelbar nach der Gateway-Verarbeitung, also bevor sie im Postfach des Nutzers landet, an das Archiv übergeben. Zu diesem Zeitpunkt liegt sie entweder im Klartext vor (bei reiner TLS-Nutzung) oder nach der Gateway-seitigen Entschlüsselung. Das Archiv erhält damit eine vollständig lesbare, indexierbare Kopie.

Schritt 4: Archiv-seitige Verschlüsselung ruhender Daten. Das Archiv speichert die Nachrichten verschlüsselt ab, nicht mit dem Schlüssel des Empfängers, sondern mit einem separaten, ausschließlich vom Archivsystem verwalteten Schlüssel. Diese Verschlüsselung erfüllt die Anforderung der DSK für ruhende Daten, ohne das Lesbarkeits- und Suchbarkeitsproblem zu erzeugen.

Schritt 5: Ausgehende E-Mails über SMTP mit BCC oder Journal. Für ausgehende Nachrichten wird das Archiv entweder über einen Journal-Mechanismus oder über SMTP-Blindkopie eingebunden. Auch hier greift die Archivierung, bevor die Nachricht das Gateway verlässt. Die ausgehende Nachricht wird also vor einer eventuellen S/MIME-Verschlüsselung durch den Client oder das Gateway im Klartext archiviert.

Diese Architektur löst das Kernproblem: Das Archiv erhält niemals Ende-zu-Ende-verschlüsselte Nachrichten, die es nicht lesen kann, weil die Archivierung an einem Punkt im Nachrichtenfluss erfolgt, an dem die Nachrichten noch im Klartext vorliegen. Gleichzeitig sind die archivierten Daten selbst verschlüsselt gespeichert.

Schlüsselmanagement: Was zu beachten ist

Die Archivierung über ein Gateway setzt voraus, dass das Schlüsselmanagement klar geregelt ist. Folgende Punkte sind in der Praxis kritisch:

Trennung von Nutzerschlüsseln und Archivschlüsseln: Der Schlüssel, mit dem das Archiv seine gespeicherten Nachrichten verschlüsselt, darf nicht mit den persönlichen S/MIME-Zertifikaten der Nutzer identisch sein. Verlässt ein Mitarbeiter das Unternehmen und wird sein Schlüssel widerrufen, darf das keine Auswirkungen auf die Lesbarkeit archivierter Nachrichten haben.

Key Rotation und Langzeitarchivierung: Archivschlüssel müssen über die gesamte Aufbewahrungsfrist (bis zu acht Jahre für Buchungsbelege nach § 147 AO) verfügbar bleiben. Kryptografische Schlüsselrotation muss so implementiert sein, dass ältere Nachrichten nach einer Schlüsselrotation re-verschlüsselt werden oder die alten Schlüssel sicher hinterlegt bleiben.

Zugriffsschutz für den Archivschlüssel: Der Archivschlüssel ist das kritischste Geheimnis im System. Er sollte in einem Hardware Security Module (HSM) oder einem dedizierten Key Management Service gespeichert sein, nicht im Dateisystem des Archivservers. Der Zugriff auf den Schlüssel ist zu protokollieren und auf die minimal notwendige Anzahl von Systemprozessen und Administratoren zu beschränken.

Was das für Ihre Archivierungsstrategie bedeutet

Für Unternehmen, die heute eine GoBD-konforme und gleichzeitig verschlüsselungskonforme Archivierungsstrategie aufsetzen, ergibt sich folgende Handlungsempfehlung:

Setzen Sie erzwungenes TLS mit DANE oder MTA-STS für eingehende und ausgehende E-Mails durch. Das ist der Mindeststandard der DSK und löst das Problem für die große Mehrheit geschäftlicher E-Mails, die nur TLS als Verschlüsselungsebene verwenden.

Wenn Sie S/MIME oder PGP für erhöhten Schutzbedarf einsetzen, planen Sie die Archivierungsarchitektur von Anfang an mit ein. Eine nachträgliche Integration ist erheblich aufwändiger als ein Archivierungspunkt, der von Beginn an vor dem Postfach des Empfängers positioniert ist.

Dokumentieren Sie die gewählte Architektur in Ihrer Verfahrensdokumentation nach GoBD. Die Finanzbehörde muss nachvollziehen können, dass alle eingehenden und ausgehenden E-Mails vollständig und unverändert erfasst werden, unabhängig davon, ob sie verschlüsselt übertragen wurden.

Prüfen Sie die Anforderungen nach § 30 BSIG auf Ihre Einrichtung. Falls Sie unter NIS2 fallen, ist die Umsetzung von Verschlüsselung keine Empfehlung mehr, sondern eine Pflicht mit Bußgeldrisiko. Kombinieren Sie die NIS2-Compliance-Dokumentation mit Ihrer DSGVO-Dokumentation zu einem einheitlichen Sicherheitskonzept.

GoBD-konforme Archivierung verschlüsselter E-Mails mit EasyMailArchive

EasyMailArchive unterstützt die Gateway-Architektur nativ: Die Archivierung erfolgt über SMTP-Journal oder BCC-Mechanismus direkt am E-Mail-Gateway, vor der Auslieferung an das Postfach und vor einer eventuellen clientseitigen Verschlüsselung. Die archivierten Nachrichten werden serverseitig verschlüsselt gespeichert (AES-256) und sind vollständig durchsuchbar und exportierbar für Z1/Z2/Z3-Datenzugriffe nach GoBD.

Wenn Sie Ihre bestehende Verschlüsselungsinfrastruktur mit einer revisionssicheren Archivierungslösung verbinden möchten, sprechen Sie uns an. Wir zeigen Ihnen, wie die Integration mit Ihrem E-Mail-Gateway (Microsoft 365 Defender, Proofpoint, Secure Email Gateway oder eigenes Postfix-Setup) konkret aussieht.

Jetzt kostenlos testen oder Beratungsgespräch vereinbaren.

Rechtliche Grundlagen:

DSK Orientierungshilfe "E-Mail-Verschlüsselung" (16. Juni 2021): Mindestanforderungen Transportverschlüsselung, Anforderungen an ruhende Daten
DSGVO Art. 32: Sicherheit der Verarbeitung, Verschlüsselung als explizit genannte Maßnahme
NIS2UmsuCG, § 30 BSIG: Kryptografie und Verschlüsselung als Pflichtmaßnahme im Risikomanagement
GoBD (28. November 2019, zuletzt geändert Juli 2025): Maschinelle Auswertbarkeit, Originalformat, Vollständigkeit archivierter Unterlagen
§ 147 AO: Aufbewahrungsfristen, geändert durch Bürokratieentlastungsgesetz IV seit 1. Januar 2025