E-Mail-Verschlüsselung: Verfahren, Schlüssel und Betriebsmodelle

Die Frage «Ist diese E-Mail verschlüsselt?» ist technisch unvollständig. Eine Nachricht kann auf dem Client lesbar, auf dem Mailserver als Chiffretext gespeichert, auf einem Gateway entschlüsselt, zwischen zwei MTAs per TLS geschützt und beim Empfänger wieder unverschlüsselt abgelegt sein. Eine belastbare Antwort nennt deshalb Schutzobjekt, Endpunkte, Schlüsselinhaber und Klartextstellen. NIST behandelt Transport-, Domänen- und Inhaltsmechanismen aus genau diesem Grund als zusammenwirkende, aber getrennte Kontrollen (NIST SP 800-177 Rev. 1).

Transportverschlüsselung schützt eine Verbindung. SMTP STARTTLS wird für jeden Hop neu ausgehandelt und endet am jeweiligen MTA. Inhaltsverschlüsselung schützt eine MIME-Entität mit S/MIME oder OpenPGP und kann mehrere Transport- und Speicherhops überdauern. Ob sie wirklich Ende-zu-Ende wirkt, hängt nicht allein vom Format ab: Entschlüsselt ein Unternehmensgateway stellvertretend, liegen die kryptografischen Endpunkte an den Gateways und nicht bei den Benutzerclients (RFC 3207, RFC 8551, RFC 9580).

Eine digitale Signatur ist nochmals eine andere Sicherheitsleistung. Sie bindet Daten an einen privaten Signaturschlüssel und ermöglicht Integritäts- und Identitätsprüfung; sie macht den Inhalt nicht geheim. Umgekehrt sagt eine erfolgreich entschlüsselte Nachricht noch nichts darüber aus, wer sie erstellt hat. In S/MIME werden dafür CMS SignedData und EnvelopedData beziehungsweise AuthEnvelopedData unterschieden. OpenPGP trennt Signatur-, Sitzungsschlüssel- und verschlüsselte Datenpakete ebenfalls (RFC 5652, RFC 8551, S/MIME Content Types, RFC 9580, Packet Syntax).

Die Erklärung folgt einer Nachricht und fragt an jedem Hop, wo Klartext vorliegt und wer die Schlüssel kontrolliert. Transportverschlüsselung, Ende-zu-Ende-Verfahren, Gateways, Portale, Metadaten, Diagnose und Recovery werden darauf aufbauend verglichen.

E-Mail-Verschlüsselung kann den Transporthop, den Nachrichteninhalt oder einen Portalzugriff schützen. Diese Modelle haben unterschiedliche Schlüsselinhaber und unterschiedliche Stellen, an denen Klartext vorliegt. Der Artikel folgt deshalb zuerst dem Schutzweg und erst danach den einzelnen Produkten und Verfahren.

Architekturansatz: Schutzmodelle und Klartextgrenzen

E-Mail-Verschlüsselung unterscheidet sich vor allem darin, welche zwei Punkte verschlüsseln und entschlüsseln. Die Tabelle beginnt deshalb beim normalen Nachrichtenweg und zeigt danach, wo Klartext technisch sichtbar bleibt.

Keines dieser Modelle ist pauschal «stärker». Client-zu-Client reduziert Klartextstellen in der Infrastruktur, erschwert jedoch Malwareprüfung, Journaling, eDiscovery und Recovery. Das NCCoE-Praxisbeispiel lässt deshalb die S/MIME-Prüfung am Benutzerclient mit dessen Trust Anchors ausführen, nachdem Transport- und domänenbasierte Kontrollen am MTA abgeschlossen sind (NCCoE: DNS-Based Email Security). Gateways zentralisieren Policy und Schlüssel, werden dafür selbst zu hochprivilegierten Klartext- und Schlüsselstellen. Portale erreichen Empfänger ohne Mailkryptografie, schaffen aber ein zusätzliches Web-, Identitäts- und Speicherverfahren. Die Wahl folgt Datenklassifikation, Bedrohungsmodell, Aufbewahrung, Rechtsanforderungen und den Fähigkeiten beider Kommunikationsseiten – nicht dem Produktnamen.

SMTP-TLS: Schutz pro Transporthop

SMTP wurde ursprünglich ohne verpflichtende Vertraulichkeit entworfen. STARTTLS erweitert eine bestehende SMTP-Sitzung: Nach erfolgreichem TLS-Handshake werden Fähigkeiten erneut per EHLO ausgehandelt. Im opportunistischen Modus kann der sendende MTA bei fehlendem STARTTLS oder einem Zertifikatsfehler auf Klartext zurückfallen. Das verbessert den Schutz gegen passives Mitlesen, liefert aber ohne zusätzliche Policy keine belastbare Garantie gegen Downgrade oder einen aktiven Angreifer (RFC 3207).

MTA-STS veröffentlicht zunächst einen DNS-TXT-Hinweis und bezieht die eigentliche Policy über HTTPS. Im enforce-Modus müssen die angegebenen MX-Namen per PKIX validiert werden; Fehler führen zu verzögerter Zustellung statt Klartext. DANE für SMTP bindet Zertifikats- oder Schlüsselinformationen in DNSSEC-validierte TLSA-Datensätze. REQUIRETLS ist eine SMTP- und Nachrichtenkennzeichnung, mit der ein Absender für die weitere Übertragung TLS verlangt. Diese Verfahren haben unterschiedliche Abhängigkeiten und Reichweiten und dürfen nicht in einem einzigen Häkchen «TLS required» zusammengefasst werden (RFC 8461, RFC 7672, RFC 8689).

SMTP TLS Reporting, TLS-RPT, liefert aggregierte Berichte über erfolgreiche und fehlgeschlagene TLS-Policyprüfungen. Es beweist keine einzelne Zustellung und enthält keine Nachricht; es hilft, Zertifikats-, DNS- und Policyfehler zu erkennen, bevor Queues lange wachsen. NIST empfiehlt Empfangsdomänen, DANE, MTA-STS oder beide zu signalisieren, und beschreibt die unterschiedlichen DNSSEC-, HTTPS- und PKIX-Abhängigkeiten (RFC 8460, NIST SP 800-177 Rev. 1, Abschnitt 5.2).

SMTP-TLS endet am nächsten Mailserver. Soll der Nachrichteninhalt über mehrere Hops hinweg geschützt bleiben, kommen nachrichtenbezogene Verfahren wie S/MIME oder OpenPGP zum Einsatz.

S/MIME: CMS, X.509 und MIME

S/MIME ist keine einzelne Verschlüsselungsbibliothek, sondern eine Verbindung mehrerer Standards. MIME strukturiert Nachrichtenteile; CMS definiert signierte und verschlüsselte Container; X.509/PKIX bindet öffentliche Schlüssel über Zertifikate an Identitäten und Vertrauensanker. Für jeden Empfänger verschlüsselt der Sender den symmetrischen Inhaltsschlüssel mit dessen öffentlichem Schlüssel oder einem vereinbarten Key-Management-Verfahren. Zum Lesen ist der passende private Schlüssel erforderlich (RFC 8551, RFC 5652, RFC 5280).

Der Admin muss zwei Schlüsselrollen trennen. Ein Signaturschlüssel soll nur dem Unterzeichner zur Verfügung stehen; eine zentrale Kopie würde Dritten technisch ermöglichen, neue Signaturen unter dessen Identität zu erzeugen. Ein Entschlüsselungsschlüssel kann nach Organisationspolicy gesichert oder escrowed werden, damit ältere Geschäftsnachrichten nach Geräteverlust, Rollenwechsel oder Zertifikatserneuerung lesbar bleiben. RFC 8551 weist ausdrücklich darauf hin, dass eine Person mehrere aktive Schlüsselpaare für unterschiedliche Zwecke besitzen kann; NIST unterscheidet Schutz und Recovery je Schlüsseltyp (RFC 8551, Multiple Key Pairs, NIST SP 800-57 Part 1 Rev. 5).

Vor dem Senden benötigt der Absender für jeden Empfänger ein geeignetes und gültiges Verschlüsselungszertifikat. Verteilung kann über ein Verzeichnis, signierte Nachrichten, eine Zertifikatsplattform oder manuell erfolgen. Verteilergruppen sind besonders anspruchsvoll, weil Expansion, Sichtbarkeit und Zertifikatverfügbarkeit aller Mitglieder zusammenpassen müssen. Microsoft dokumentiert für Exchange die Attribute userSMIMECertificate und userCertificate sowie die Zertifikatssammlung zur Vertrauensprüfung (Microsoft: S/MIME in Exchange Server, Microsoft: S/MIME in Exchange Online).

OpenPGP: Format ist nicht Vertrauensmodell

RFC 9580 definiert OpenPGP-Pakete, Schlüssel, Fingerprints, Signaturen, Sitzungsschlüssel und verschlüsselte Daten. Ein Schlüsselring ist laut Norm lediglich eine Sammlung von Schlüsseln; wie eine Organisation Schlüssel findet, Eigentümer prüft und Vertrauen entscheidet, liegt ausserhalb dieses Datenformats. Das historisch verbreitete Web of Trust ist daher eine mögliche Betriebsform, aber keine Synonymdefinition von OpenPGP. Andere Umgebungen verwenden manuell geprüfte Fingerprints, organisationssignierte Schlüssel, WKD, Verzeichnisdienste oder zentral verwaltete Gateways (RFC 9580, Keyrings und Fingerprints).

Für E-Mail kapselt PGP/MIME Signaturen und Chiffretext in MIME-Strukturen. Inline-PGP schützt dagegen nur ausgewählte Textteile und führt bei HTML, Anhängen, Zeichensätzen und Zeilenkanonisierung leicht zu Interoperabilitätsproblemen. RFC 3156 standardisiert multipart/encrypted und multipart/signed für OpenPGP. Ob ein Client moderne RFC-9580-Schlüssel, AEAD, verwendete Kurven und PGP/MIME vollständig unterstützt, muss mit den realen Gegenstellen getestet werden (RFC 3156, RFC 9580).

Ein kurzer Key ID ist kein hinreichender Identitätsnachweis. RFC 9580 warnt, dass Key IDs nicht als eindeutig anzunehmen sind; für Prüfungen wird der vollständige Fingerprint verwendet. Widerrufszertifikate, Ablauf, Subkeys, neue Fingerprints und die sichere Verteilung einer Rotation gehören deshalb in denselben Lifecycle wie die erste Schlüsselausgabe.

S/MIME und OpenPGP können auf dem Endgerät oder zentral am Gateway angewendet werden. Das Gateway vereinfacht Policy und Schlüsselbetrieb, erhält dafür aber Zugriff auf den Klartext.

Gatewaymodell: zentrale Policy und zentrale Klartextmacht

Ein Mail-Gateway nimmt normale interne Nachrichten an, klassifiziert Absender, Empfänger und Daten, sucht passende S/MIME- oder OpenPGP-Schlüssel und wählt Verschlüsselung, Signatur, TLS oder Portalzustellung. Eingehend entschlüsselt es gegebenenfalls vor der Übergabe an das interne Mailsystem. Produkte wie SEPPmail, Totemomail beziehungsweise Kiteworks EPG und HIN verwenden unterschiedliche Plattformen, aber dieselbe grundlegende Vertrauensverschiebung: Die Organisation delegiert Kryptografie vom Benutzerendpunkt an eine Infrastrukturkomponente (SEPPmail: Produkte, HIN Mail).

Das löst die Schlüsselverteilung nicht von selbst. Das Gateway braucht weiterhin eine belegte Zuordnung von Empfängeridentität zu öffentlichem Schlüssel, eine Priorität mehrerer Verfahren, Regeln für abgelaufene oder widerrufene Schlüssel und ein definiertes Fallback. Automatischer Schlüsselaustausch zwischen Gateways kann diese Schritte vereinfachen, ist aber selbst ein Vertrauensprotokoll mit Gegenstellenidentität, Cache, Ablauf und Fehlerzustand.

Die Policyreihenfolge entscheidet, welche Kontrollen Klartext sehen. Entschlüsselt ein Inbound-Gateway, können Anti-Malware, DLP und Archivierung danach arbeiten. Verschlüsselt ein Outbound-Gateway zu früh, sind nachgelagerte Scanner blind. Verändert ein Gateway eine bereits signierte MIME-Entität, kann die Inhalts- oder DKIM-Signatur ungültig werden. RFC 6376 macht die kanonisierten Header und den Body zum Signaturobjekt; deshalb sind Signieren, Verschlüsseln, Disclaimer, Umschreiben und DKIM in einer dokumentierten Pipeline zu ordnen (RFC 6376).

Ist beim externen Empfänger kein geeigneter Schlüssel verfügbar, kann ein Portal die Nachricht speichern und den Zugriff über eine Webanmeldung steuern. Damit wechselt das Problem von Mailkryptografie zu Webidentität und Plattformbetrieb.

Portalzustellung: Webanwendung statt Empfängerschlüssel

Bei Portalzustellung erhält der Empfänger eine normale Benachrichtigungsmail und ruft den geschützten Inhalt über eine Webanwendung ab. Der Kryptografie-Endpunkt ist das Portal, nicht der Mailclient des Empfängers. Damit verschiebt sich die technische Aufgabe von Public-Key-Verteilung zu Webidentität, Sessionmanagement, Nachrichten- und Anhangsspeicher, Benachrichtigungslink, Aufbewahrung und sicherem Antwortkanal.

HIN dokumentiert als konkretes Beispiel Registrierung, Mobilnummer und SMS-Code sowie die Option, ein Gerät für spätere Zugriffe zu merken. Dieses Beispiel belegt das Betriebsmodell, nicht eine allgemeingültige Portalimplementierung. Andere Produkte verwenden Passwort, Einmalcode über getrennten Kanal, föderierte Identität oder eine bestehende Kundenanmeldung (HIN: Mail an Nichtmitglieder).

Für Admins braucht ein Portal mindestens folgende Nachweise:

• Welche Daten stehen in der ungeschützten Benachrichtigung und im URL-Token?
• Wie werden Erstregistrierung, Identitätsbindung, Fehlversuche, Gerätemerken und Kontowiederherstellung abgesichert?
• Wo liegen Nachrichten, Anhänge, Schlüssel und Auditdaten, und wann werden sie gelöscht?
• Bleibt eine Nachricht nach Ablauf, Benutzerlöschung oder Tenantwechsel wiederherstellbar?
• Wie werden sichere Antwort, Weiterleitung, Download und Lesebestätigung protokolliert?
• Was geschieht bei nicht erreichbarem Portal, ausgefallenem SMS-Dienst oder kompromittiertem Empfängerkonto?

Ein HTTP-Status 200 belegt nur, dass eine Weboberfläche antwortet. Ein synthetischer Portaldurchlauf muss Benachrichtigung, Registrierung beziehungsweise Login, zweiten Faktor, Öffnen, Anhang, Antwort und den erwarteten Auditdatensatz abdecken.

Metadaten, Header und Archivierung

Inhaltsverschlüsselung schützt nicht automatisch den SMTP-Envelope. Zustellende MTAs benötigen mindestens Empfängeradressen; Systeme erzeugen Received-Zeilen und verarbeiten Grössen- sowie Routinginformationen. Auch bei S/MIME bleiben äussere Header normalerweise sichtbar. RFC 8551 erlaubt, eine vollständige Nachricht als message/rfc822 innerhalb der geschützten MIME-Entität zu kapseln, verlangt aber eine unterscheidbare Darstellung innerer und äusserer Header. Ob Betreff, Absenderanzeige und Empfängerliste tatsächlich geschützt sind, ist eine Client- und Gatewayfunktion, keine sichere Folge des Schloss-Symbols (RFC 5322, RFC 8551, Header Protection).

Archivierung muss festlegen, welche Darstellung erhalten bleibt: ursprünglicher Klartext, signierte Originalentität, verschlüsseltes Original, entschlüsselte Arbeitskopie oder Portalobjekt. Nur Klartext vereinfacht eDiscovery, verliert aber den kryptografischen Originalnachweis. Nur Chiffretext kann nach Schlüsselverlust unlesbar werden. Signaturvalidierung zu einem späteren Zeitpunkt benötigt Originalbytes, Zertifikatskette, damalige Vertrauens- und Sperrinformationen sowie eine Zeitbasis; ein heute abgelaufenes Zertifikat macht eine damals gültige Signatur nicht automatisch wertlos.

Schlüssel- und Zertifikatslebenszyklus

Ein produktiver Kryptodienst benötigt ein Inventar, das über Ablaufdaten hinausgeht. NIST SP 800-57 behandelt Generierung, Aktivierung, Schutz, Inventar, Verteilung, Nutzung, Rotation, Sperre, Archiv, Recovery und Vernichtung als zusammenhängende Managementaufgaben (NIST SP 800-57 Part 1 Rev. 5).

S/MIME-Pfadprüfung umfasst Vertrauensanker, Zwischenzertifikate, Gültigkeitszeit, Name beziehungsweise Mailidentität, Key Usage/Extended Key Usage, Algorithmus und Sperrstatus. OCSP und CRLs sind wiederum Netzwerk- und Cacheabhängigkeiten. Bei einem Soft-Fail bleibt eine Prüfung trotz nicht erreichbarer Sperrinformation möglich; bei Hard-Fail kann ein Infrastrukturproblem alle signierten oder verschlüsselten Nachrichten blockieren. Diese Entscheidung gehört in die Policy und ins Monitoring (RFC 5280, RFC 6960).

Die Diagnose beginnt beim gewählten Schutzmodell: TLS-Hop, Signatur und Verschlüsselung des Inhalts oder Portalzugriff. Erst danach werden Zertifikat, Schlüssel, Policy und Zustellpfad geprüft.

Monitoring und Störungsanalyse

Monitoring muss nach Schutzmodell getrennt werden. Für Transport-TLS zählen angebotene und ausgehandelte Protokolle, Policyfehler, Zertifikatsvalidierung, TLS-RPT und Queuealter. Für S/MIME/OpenPGP zählen fehlende Empfängerschlüssel, ungültige Pfade oder Signaturen, Fallbacks, Rotation und Entschlüsselungsfehler. Für Gateways kommen Policyentscheidung, Message-ID, Key-Fingerprint, Klartextverarbeitung und nächster Hop hinzu. Für Portale sind Registrierung, MFA/OTP, Speicher, Linkablauf, Login, Nachrichtenöffnung und Antwortpfad eigene Signale.

Ein sinnvolles Incidentprotokoll beantwortet:

1. Welche Nachricht und welcher Empfängerpfad sind betroffen?
2. Welches Schutzmodell und welche Policy wurden gewählt?
3. Welcher öffentliche Schlüssel oder welches Zertifikat wurde verwendet, mit welchem Fingerprint und Status?
4. Wo war die Nachricht zuletzt lesbar, verschlüsselt, gespeichert oder gequeued?
5. War das Ergebnis Zustellung, Portalablage, Quarantäne, Fallback, Retry oder permanenter Fehler?
6. Lässt sich das Ergebnis mit einer kontrollierten Testidentität reproduzieren, ohne Produktivdaten offenzulegen?

Backup und Recovery

Verschlüsselte Daten und Schlüssel müssen gemeinsam, aber mit getrennten Schutzmassnahmen geplant werden. Ein Backup verschlüsselter Nachrichten ohne die langfristig benötigten privaten Entschlüsselungsschlüssel ist möglicherweise korrekt gesichert und dennoch fachlich nicht wiederherstellbar. Umgekehrt verwandelt ein unzureichend geschütztes Key-Escrow-Backup viele Einzelgeheimnisse in einen zentralen Angriffspunkt. NIST behandelt die zulässige Nutzung wiederhergestellter privater Schlüssel abhängig von Schlüsseltyp und Kryptoperiode (NIST SP 800-57 Part 1 Rev. 5, PDF).

Der minimale Recoveryumfang umfasst:

• verschlüsselte Originalnachrichten und gegebenenfalls beweissichere signierte MIME-Entitäten;
• private Entschlüsselungsschlüssel mit Metadaten, Passphrasen, Rollen und Freigabeverfahren;
• öffentliche Schlüssel, Zertifikatsketten, Trust Anchors, Sperr- und historische Validierungsdaten;
• Gateway- und Portalpolicy, Routing, Schlüsselzuordnung, Benutzerdaten und Nachrichtenobjekte;
• Audit- und Zeitquellen, damit frühere Entscheidungen nachvollziehbar bleiben;
• einen Restoretest mit alten und neuen Schlüsseln, mehreren Empfängern, Anhängen und Signaturprüfung.

Private Signaturschlüssel sollten nicht als allgemeiner Recoverymechanismus kopiert werden. Muss eine Organisation automatisiert oder stellvertretend signieren, ist dafür eine explizite Organisationsidentität mit eigener Policy besser als die unbemerkte Kopie eines persönlichen Schlüssels. Recoveryfähigkeit und Nichtabstreitbarkeit stehen sonst im Konflikt zueinander.

Diagnosewerkzeuge

Die Fehlersuche folgt dem gewählten Schutzmodell. Bei Transportverschlüsselung werden DNS und TLS geprüft; bei Ende-zu-Ende-Verfahren folgen Zertifikate, Schlüssel und Clientverarbeitung; bei Gateways kommt deren Policy- und Queuezustand hinzu.

MTA-STS, TLS-RPT und DANE im DNS

Resolve-DnsName -Type TXT _mta-sts.example.ch
Resolve-DnsName -Type TXT _smtp._tls.example.ch
Resolve-DnsName -Type TLSA _25._tcp.mx.example.ch

dig +short TXT _mta-sts.example.ch
dig +short TXT _smtp._tls.example.ch
dig +dnssec TLSA _25._tcp.mx.example.ch

Resolve-DnsName und dig zeigen veröffentlichte Transportpolicies. Für DANE muss zusätzlich der DNSSEC-Validierungsstatus belegt werden; ein bloss sichtbarer TLSA-Text ist noch kein authentisierter Datensatz.

STARTTLS und Zertifikatskette

Test-NetConnection mx.example.ch -Port 25 -InformationLevel Detailed
curl.exe --verbose --ssl-reqd smtp://mx.example.ch:25

nc -vz mx.example.ch 25
openssl s_client -starttls smtp -connect mx.example.ch:25 \
  -servername mx.example.ch -showcerts

Test-NetConnection und nc prüfen den TCP-Pfad. curl und openssl s_client zeigen STARTTLS, Handshake und Kette. Ob ein produktiver MTA bei Fehlern zurückfällt oder queued, ergibt sich erst aus dessen Policy und Logs.

S/MIME-Zertifikat und Verwendungszweck

certutil.exe -dump .\recipient-smime.cer
certutil.exe -verify -urlfetch .\recipient-smime.cer

openssl x509 -in recipient-smime.pem -noout \
  -subject -issuer -serial -fingerprint -dates -purpose -ext keyUsage -ext extendedKeyUsage
openssl verify -show_chain -CAfile trust-chain.pem recipient-smime.pem

certutil und openssl x509 zeigen Identität, Fingerprint, Gültigkeit und Verwendungszweck; openssl verify prüft einen angegebenen Truststore. Der Test muss mit denselben Trust Anchors und Sperrregeln wie der produktive Client oder das Gateway wiederholt werden.

OpenPGP-Fingerprint und Schlüsselstruktur

gpg.exe --show-keys --with-fingerprint --with-subkey-fingerprint .\recipient.asc
gpg.exe --list-packets .\message.pgp

gpg --show-keys --with-fingerprint --with-subkey-fingerprint recipient.asc
gpg --list-packets message.pgp

gpg zeigt vollständige Fingerprints, Subkeys, Fähigkeiten und Paketstruktur. --list-packets analysiert nur das Format; es bestätigt weder Eigentümer noch Vertrauen. Fingerprints sind über einen authentisierten zweiten Kanal oder ein definiertes Organisationsverfahren zu prüfen.

Portalpfad und Paketerfassung

Invoke-WebRequest -Method Head -Uri https://securemail.example.ch/
pktmon filter remove
pktmon filter add SecureMail -p 25
pktmon start --capture --pkt-size 0 --file-name securemail.etl
pktmon stop

curl --head --verbose https://securemail.example.ch/
tcpdump -ni any -s 0 -w securemail.pcap 'tcp port 25 or tcp port 443'

Invoke-WebRequest und curl prüfen nur HTTP/TLS-Erreichbarkeit. pktmon und tcpdump erfassen nur an der gewählten Messstelle. Paketdaten können SMTP-Klartext, Adressen und Portalmetadaten enthalten und sind entsprechend zu schützen.

Technische Geschichte

PEM, Privacy Enhanced Mail, standardisierte Anfang der 1990er-Jahre kryptografisch geschützte Internetmail, erreichte jedoch keine breite Interoperabilität. S/MIME verband später die aus PKCS hervorgegangene CMS-Struktur mit MIME und X.509. Die S/MIME-Normen entwickelten sich über mehrere Generationen bis zur 2019 veröffentlichten Version 4.0; CMS selbst ist in RFC 5652 standardisiert (RFC 1421, RFC 8551, RFC 5652).

OpenPGP entstand aus dem PGP-Paketformat und wurde zunächst in RFC 2440, später in RFC 4880 standardisiert. RFC 9580 ersetzte RFC 4880 im Jahr 2024 und modernisierte unter anderem Schlüsselversionen, Fingerprints und Verfahren für authentisierte Verschlüsselung. PGP/MIME nach RFC 3156 bleibt die E-Mail-Kapselung; die Formatentwicklung beseitigt jedoch nicht die organisatorische Aufgabe, Schlüsselidentität und Recovery zu regeln (RFC 9580, RFC 3156).

SMTP STARTTLS wurde 1999 in RFC 2487 standardisiert und 2002 durch RFC 3207 aktualisiert. DANE für SMTP, MTA-STS, TLS-RPT und REQUIRETLS ergänzten später Policy- und Berichtsschichten gegen Downgrade und Fehlkonfiguration. Parallel etablierten Unternehmen Gateways und Webportale, weil externe Empfänger nicht zuverlässig über kompatible S/MIME- oder OpenPGP-Schlüssel verfügen. Dadurch wurde E-Mail-Verschlüsselung weniger zu einem einzelnen Clientfeature und stärker zu einem verteilten System aus SMTP, DNS, HTTPS, PKI, Verzeichnis, Policy, Webidentität und Recovery (RFC 7672, RFC 8461, RFC 8460, RFC 8689).