E-Mail-Verschlüsselung
E-Mail-Verschlüsselung, die ohne Zutun der Mitarbeitenden greift.
Verschlüsselung, die von jedem Einzelnen verlangt, das richtige Häkchen zu setzen, wird vergessen. Wir verschlüsseln zentral: TLS auf dem Transportweg erzwingen, S/MIME und PGP am Gateway statt am Client, Portalzustellung für Empfänger ohne Zertifikat. Eingehende verschlüsselte Mails werden entschlüsselt, bevor Filter und Archiv sie brauchen. Zertifikate und Schlüssel verwalten wir im Betrieb, inklusive Ablauf und Hinterlegung.
Microsoft 365: derzeit nur in Deutschland. Leistungen rund um Microsoft 365 (Beratung, Migration, Betrieb, Security und Workshops) bieten wir derzeit ausschliesslich für Organisationen in Deutschland an. In der Schweiz übernehmen wir keine Microsoft-365-Mandate. Für Schweizer Kunden: Software & KI, Infrastruktur und Projekt-Recovery.
Typische Ausgangslagen
Verschlüsselt wird, wenn jemand daran denkt
In vielen Organisationen ist E-Mail-Verschlüsselung ein Flickenteppich aus Clientzertifikaten, Passwort-ZIPs und der Hoffnung, dass TLS schon irgendwie greift.
Zertifikate auf Einzelplätzen
Einige Mitarbeitende haben ein S/MIME-Zertifikat in Outlook, die meisten nicht. Auf dem Smartphone oder im Browser funktioniert es gar nicht, und beim Gerätewechsel fehlt der private Schlüssel.
Verschlüsselt im Archiv
Eingehende S/MIME-Mails liegen verschlüsselt im Postfach und im Archiv. Durchsuchen lassen sie sich nicht, und nach dem Austritt des Empfängers öffnen sie sich auch nicht mehr.
Der Filter sieht nichts
Eine verschlüsselte Mail mit Schadcode im Anhang kommt ungeprüft durch, weil weder Gateway noch Exchange Online in den Inhalt schauen können.
Partner verlangen Verschlüsselung
Kostenträger, Behörden oder Konzernpartner fordern erzwungenes TLS oder S/MIME und schicken eine Checkliste. Wer was mit wem vereinbart hat, steht nirgends.
Empfänger ohne Zertifikat
Patienten, Bürger oder kleine Partner haben weder S/MIME noch PGP. Am Ende geht die sensible Mail doch im Klartext raus, oder ein Passwort-ZIP mit dem Kennwort in der nächsten Mail.
Abgelaufen und keiner merkt es
Ein Gateway- oder Benutzerzertifikat läuft ab. Partner mit erzwungenem TLS lehnen die Zustellung ab, und die Fehlermeldung landet in einem Postfach, das niemand liest.
Drei Ebenen
Transport, Inhalt, Portal: welche Ebene wofür
Verschlüsselung ist nicht ein Schalter, sondern drei Verfahren mit unterschiedlicher Reichweite. Wir legen je Partner und Datenart fest, welches gilt, und was passiert, wenn es nicht verfügbar ist.
TLS auf dem Transportweg
Verschlüsselt die Verbindung zwischen zwei Mailservern. Die Mail liegt beim Empfänger wieder im Klartext. Standard für fast jede Verbindung, aber nur verlässlich, wenn es erzwungen und das Zertifikat geprüft wird.
S/MIME und PGP für den Inhalt
Verschlüsselt die Mail selbst, Ende zu Ende oder Gateway zu Gateway. Bleibt auch auf Zwischenstationen geschützt und belegt per Signatur, wer gesendet hat. Setzt voraus, dass der Empfänger ein Zertifikat oder einen Schlüssel hat.
Portal für alle anderen
Die Mail bleibt auf einer geschützten Plattform, der Empfänger erhält eine Benachrichtigung und liest und antwortet über eine HTTPS-Seite mit Anmeldung. Funktioniert ohne Zertifikat, braucht aber einen Login-Weg, den der Empfänger versteht.
TLS erzwingen
Opportunistisches TLS reicht nicht, wenn es darauf ankommt
Mailserver verschlüsseln standardmässig, wenn die Gegenseite es anbietet, und senden im Klartext, wenn nicht. Ein Angreifer im Netzwerkweg kann das Angebot unterdrücken. Für Partner mit sensiblen Daten erzwingen wir TLS mit Zertifikatsprüfung.
In Exchange Online geschieht das über einen Outbound-Connector je Partnerdomäne, der TLS verlangt und das Zertifikat des Empfängers prüft. Läuft der Versand über ein vorgelagertes Gateway, setzen wir die Regel dort. Kommt keine verschlüsselte Verbindung zustande, wird die Mail nicht im Klartext zugestellt, sondern zurückgehalten oder abgelehnt.
Was wir für die eigene Domain einrichten
- MTA-STS: Richtlinie per HTTPS veröffentlicht, die sendenden Servern vorschreibt, nur verschlüsselt und nur an die genannten MX-Hosts zuzustellen. Liegt der MX bei einer Filterplattform, müssen deren Hosts in der Richtlinie stehen.
- TLS-RPT: tägliche Berichte anderer Mailserver über fehlgeschlagene TLS-Verbindungen zu Ihrer Domain, ausgewertet statt ignoriert.
- Einführung von MTA-STS erst im Testmodus, dann scharf, mit Rückweg über die DNS-Kennung
- gültige, rechtzeitig erneuerte Zertifikate auf allen eingehenden Systemen
- DANE als Ausblick: setzt DNSSEC für die Zone und TLSA-Einträge für den MX-Host voraus. Exchange Online prüft DANE beim Versand. Für eingehende Mail hängt es davon ab, wer den MX betreibt.
S/MIME und PGP am Gateway
Zentral verschlüsseln statt am Client
Ein Verschlüsselungsgateway signiert und verschlüsselt ausgehende Mails automatisch nach Regeln und entschlüsselt eingehende Mails, bevor sie ins Postfach gehen. Mitarbeitende arbeiten in Outlook, im Browser oder auf dem Smartphone wie gewohnt.
Regeln statt Häkchen
Verschlüsselungsrichtlinien auf Ebene von Domain, Gruppe und Benutzer: immer verschlüsseln, verschlüsseln wenn möglich, oder Pflicht mit Ablehnung, wenn kein sicherer Weg verfügbar ist. Ausnahmen begründet und dokumentiert.
Zertifikate und Schlüssel zentral
Benutzerzertifikate werden über die Plattform beantragt, verlängert und zentral gespeichert. Öffentliche Schlüssel von Partnern werden aus deren signierten Mails übernommen, damit die nächste Antwort automatisch verschlüsselt werden kann.
Fallback-Reihenfolge
Hat der Empfänger ein S/MIME-Zertifikat, wird S/MIME genutzt, sonst PGP, sonst erzwungenes TLS, sonst Portalzustellung. Die Reihenfolge legen wir je Partner fest, damit nichts unbemerkt auf Klartext zurückfällt.
Verschlüsselung am Client
- funktioniert nur, wenn jemand daran denkt
- private Schlüssel auf Einzelgeräten, schwer zu sichern und zu übertragen
- verschlüsselte Mails im Postfach, unlesbar für Filter, Archiv und Suche
- Zertifikatsablauf je Benutzer, ohne zentrale Übersicht
- auf Mobilgeräten und im Browser oft nicht nutzbar
Verschlüsselung am Gateway
- greift automatisch nach Regel, auf jedem Gerät
- Schlüssel zentral gespeichert und hinterlegt
- Inhalte im Unternehmen im Klartext, geprüft und archiviert
- eine Laufzeitübersicht für alle Zertifikate
- Signatur belegt den Absender gegenüber Partnern
Am Beispiel von Hornetsecurity 365 Total Protection: Die Plattform signiert und verschlüsselt ausgehende Mails automatisch per S/MIME und PGP, verwaltet Zertifikate und Schlüssel zentral, erlaubt Richtlinien auf Domain-, Gruppen- und Benutzerebene und bietet mit Websafe eine Portalzustellung. Eingehende S/MIME- und PGP-Mails werden entschlüsselt, wenn der private Schlüssel des Empfängers hinterlegt ist. Laut Herstellerangaben, Stand Oktober 2026. Vergleichbare Plattformen arbeiten nach demselben Prinzip.
Eingehend
Erst entschlüsseln, dann prüfen und archivieren
Die Reihenfolge entscheidet. Eine verschlüsselt zugestellte Mail kann weder auf Schadcode geprüft noch durchsucht noch nach dem Austritt des Empfängers gelesen werden. Deshalb entschlüsseln wir am Eingang.
Die Plattform entschlüsselt mit dem hinterlegten Schlüssel, prüft Anhänge und Links, archiviert die Mail im Klartext und stellt sie zu. Ob die Mail verschlüsselt war und ob die Signatur gültig ist, wird im Betreff oder in einem Hinweis sichtbar gemacht, damit Empfänger wissen, worauf sie sich verlassen können.
- 1
Annahme mit TLS
Die Verbindung zum Filter ist verschlüsselt, bei vereinbarten Partnern erzwungen.
- 2
Entschlüsselung
S/MIME und PGP mit dem hinterlegten Schlüssel, Prüfung der Signatur, Übernahme des öffentlichen Schlüssels des Absenders.
- 3
Filter & Sandbox
Spam, Malware, Sandbox und Link-Prüfung auf dem Klartext. Passwortgeschützte Anhänge werden, wo die Plattform es kann, mit dem Kennwort aus dem Mailtext geöffnet.
- 4
Archiv
Archivierung im Klartext, durchsuchbar und unabhängig vom Schlüssel des einzelnen Empfängers.
- 5
Zustellung
Zustellung an Exchange Online über den gesicherten Connector, mit sichtbarem Hinweis auf Verschlüsselung und Signaturstatus.
Alternative im Tenant
Microsoft Purview Message Encryption
Microsoft bringt eine eigene Verschlüsselung mit, die je nach Lizenz bereits in Ihrem Tenant enthalten ist. Sie ersetzt kein S/MIME gegenüber Partnern, die genau das verlangen, deckt aber viele Fälle ohne zusätzliche Plattform ab.
Wie es funktioniert
Verschlüsselung per Transportregel, Vertraulichkeitsbezeichnung oder manuell in Outlook, etwa «Nur verschlüsseln» oder «Nicht weiterleiten». Empfänger ohne Microsoft-Konto öffnen die Mail in einem Webportal mit Einmal-Code.
Was die Erweiterung bringt
Mit Advanced Message Encryption kommen eigene Vorlagen mit Ihrem Erscheinungsbild, Ablaufdaten für verschlüsselte Mails und der Widerruf bereits versendeter Nachrichten dazu. Das setzt höhere Lizenzen oder ein Add-on voraus.
Zusammenspiel mit dem Gateway
Mit Purview verschlüsselte Mails passieren ein ausgehendes Gateway verschlüsselt, dessen Inhaltsprüfung greift dort nicht mehr. Für das Archiv lässt sich die Entschlüsselung von Journalberichten aktivieren. Wir legen fest, welches Verfahren für welche Mails gilt, damit nichts doppelt verschlüsselt wird.
Betrieb
Was im Betrieb anfällt, und woran es meistens hakt
Verschlüsselung ist nach der Einrichtung nicht fertig. Zertifikate laufen ab, Mitarbeitende kommen und gehen, Partner ändern ihre Anforderungen. Diese Tätigkeiten übernehmen wir im laufenden Betrieb.
Zertifikatsablauf
Laufzeiten aller Gateway-, Benutzer- und Domainzertifikate werden überwacht und rechtzeitig verlängert. Ein abgelaufenes Zertifikat ist sonst der häufigste Grund, warum Partner mit erzwungenem TLS plötzlich ablehnen.
Schlüsselhinterlegung
Private Schlüssel werden zentral und gesichert hinterlegt. Nach Austritt, Gerätewechsel oder Zertifikatswechsel bleiben alte Mails lesbar, und der Zugriff darauf folgt einem dokumentierten Freigabeprozess.
Ein- und Austritte
Neue Mitarbeitende erhalten bei Bedarf ein Zertifikat, Ausgetretene werden geordnet zurückgezogen. Funktionspostfächer bekommen eigene Zertifikate, damit sie nicht an einer Person hängen.
Partnerregeln
Neue Vereinbarungen zu erzwungenem TLS, S/MIME oder PGP werden als Change umgesetzt, mit Testmail an den Partner. Die Liste aller Partnerregeln ist aktuell und für Prüfungen vorzeigbar.
Typische Fehlerbilder
Signatur ungültig, weil nach dem Signieren ein Disclaimer angehängt wurde. Mail im Portal statt per S/MIME, weil eine Regel zu weit greift. Eingehende Mail nicht entschlüsselt, weil der private Schlüssel fehlt. Wir kennen die Ursachen und dokumentieren sie im Runbook.
Nachweis & Reporting
Welche Mails verschlüsselt, welche abgelehnt, welche über das Portal zugestellt wurden. Dazu die Auswertung der TLS-Berichte. Belastbar für Informationssicherheit, Datenschutz und Revision.
Zusammenhang
Verschlüsselung ist Teil der Schutzschicht
Verschlüsselung, Filter und Archiv müssen in der richtigen Reihenfolge zusammenspielen. Deshalb planen wir sie gemeinsam.
Mail-Security
Mailfilter und Advanced Threat Protection vor Exchange Online, abgestimmt mit Defender.
Mehr erfahrenE-Mail-Archivierung
Revisionssicher, im Klartext archiviert und mit einem getesteten Exit.
Mehr erfahrenGesundheitswesen
Verschlüsselte Kommunikation mit Kostenträgern, Zuweisern und Patienten, im Betrieb ohne Wochenende.
Mehr erfahrenFAQ
Häufige Fragen zur E-Mail-Verschlüsselung
Reicht TLS nicht aus?
Für den Transportweg ja, wenn es erzwungen und das Zertifikat geprüft wird. TLS schützt aber nur die Verbindung zwischen zwei Servern. Liegt die Mail beim Empfänger oder auf einer Zwischenstation, ist sie wieder im Klartext. Wo Partner oder Datenarten mehr verlangen, ergänzen wir S/MIME, PGP oder Portalzustellung.
Müssen Mitarbeitende für S/MIME am Gateway etwas tun?
In der Regel nicht. Das Gateway verschlüsselt nach Regeln, etwa für bestimmte Partner oder ein Stichwort im Betreff. Wer bewusst verschlüsseln will, nutzt ein vereinbartes Kennzeichen. Zertifikate auf Einzelgeräten sind dafür nicht nötig.
Wie erreichen wir Empfänger ohne Zertifikat?
Über eine Portalzustellung: Die Mail bleibt auf einer geschützten Plattform, der Empfänger erhält eine Benachrichtigung und liest über eine HTTPS-Seite mit Anmeldung. Alternativ bietet Microsoft Purview Message Encryption ein Webportal mit Einmal-Code. Welcher Weg passt, hängt von Empfängerkreis und Lizenzen ab.
Können verschlüsselte Mails archiviert und durchsucht werden?
Ja, wenn sie vor dem Archiv entschlüsselt werden. Deshalb entschlüsseln wir eingehende Mails am Gateway und archivieren im Klartext. Für mit Purview verschlüsselte Mails lässt sich die Entschlüsselung von Journalberichten aktivieren.
Was passiert, wenn ein Zertifikat abläuft?
Im Betrieb lassen wir es nicht so weit kommen: Laufzeiten werden überwacht, Verlängerungen geplant. Läuft ein Benutzerzertifikat dennoch ab, bleiben alte Mails über den hinterlegten Schlüssel lesbar. Bei einem Gateway-Zertifikat drohen Ablehnungen durch Partner mit erzwungenem TLS, deshalb hat es eine eigene Warnstufe.
Ersetzt das die Kommunikation über KIM im Gesundheitswesen?
Nein. KIM ist der Kommunikationsdienst der Telematikinfrastruktur mit eigenen Zugangsvoraussetzungen. Gateway-Verschlüsselung deckt die übrige Mailkommunikation ab, etwa mit Partnern, Dienstleistern oder Behörden. Wir sorgen dafür, dass beide Wege sauber getrennt sind und Mails nicht versehentlich den falschen Weg nehmen.
Wer verschlüsselt bei Ihnen, und wer weiss, wann die Zertifikate ablaufen?
In 30 Minuten klären wir, welche Partner welche Verschlüsselung erwarten, wo heute Klartext unterwegs ist und wie eine zentrale Lösung neben Exchange Online, Filter und Archiv aussieht.