Outlook New: S/MIME-Signatur im sekundären Konto nicht überprüfbar, Anhänge fehlen

Im neuen Outlook für Windows erscheint beim Öffnen einer digital signierten Mail in einem freigegebenen Postfach ein roter Balken: “Das S/MIME-Zeichen kann beim Anzeigen im sekundären Konto nicht überprüft werden.” Die Mail selbst wird angezeigt, die Anhänge aber nicht, obwohl der Absender welche mitgeschickt hat. Kolleginnen und Kollegen, die dasselbe Postfach als Hauptkonto nutzen, sehen die Anhänge problemlos.

Dahinter stecken zwei Dinge, die sich gegenseitig verstärken: das neue Outlook verarbeitet S/MIME nur im primären Konto, und der Absender hat die Mail opak signiert. Bei dieser Signaturform steckt der komplette Inhalt inklusive Anhänge in einem einzigen kryptografischen Container. Kann der Client den Container nicht öffnen, bleiben die Anhänge unsichtbar. Beides lässt sich einzeln beheben.

Was die Meldung bedeutet

“Sekundäres Konto” heisst im neuen Outlook jedes Postfach, das nicht das Konto ist, mit dem Sie sich angemeldet haben. Das trifft auf freigegebene Postfächer (Shared Mailboxes) zu, die über Vollzugriff und Automapping eingeblendet werden, ebenso auf Postfächer, die Sie über “Freigegebenes Postfach hinzufügen” eingebunden haben, und auf Delegationen. Die S/MIME-Verarbeitung ist im neuen Outlook fest an das Primärkonto gebunden. Trifft eine signierte Nachricht in einem anderen Konto ein, prüft der Client die Signatur nicht und zeigt stattdessen die Meldung.

Das ist keine Aussage über die Gültigkeit der Signatur und kein Zertifikatsproblem beim Absender. Dieselbe Mail lässt sich im Primärkonto oder im klassischen Outlook prüfen und öffnen.

Clear Signing und Opaque Signing

Der S/MIME-Standard (RFC 8551) kennt zwei Formate für signierte Nachrichten. Beide liefern dieselbe Signatur, verpacken die Nachricht aber unterschiedlich.

In der Nachrichtenquelle erkennen Sie die beiden Formate an der Kopfzeile Content-Type. Eine clear-signed Mail beginnt so:

Content-Type: multipart/signed; protocol="application/pkcs7-signature";
    micalg=sha-256; boundary="----=_Part_4711"

Eine opaque-signed Mail so:

Content-Type: application/pkcs7-mime; smime-type=signed-data;
    name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"

Der Unterschied erklärt das Verhalten im neuen Outlook vollständig. Bei einer clear-signed Mail zeigt der Client Text und Anhänge auch dann an, wenn er die Signatur nicht prüft; es fehlt nur der Signaturstatus. Bei einer opaque-signed Mail muss der Client den Container erst über die S/MIME-Verarbeitung auspacken, um an Text und Anhänge zu kommen. Verweigert er das, weil die Nachricht in einem sekundären Konto liegt, bleibt der Container zu. Dass der Text trotzdem lesbar ist, liegt an Exchange Online: Der Dienst rendert den Textteil serverseitig, die Anhänge aus dem Container aber nicht.

Beide Formate verschlüsseln nichts. Auch die opake Variante ist nur Base64-kodiert und für jeden lesbar, der die Nachricht in die Hand bekommt. Microsoft weist in der Exchange-Online-Dokumentation ausdrücklich darauf hin.

Welches Format der Absender wählt

Im klassischen Outlook steuert die Option “Signierte Nachrichten als Klartext senden” (Datei > Optionen > Trust Center > E-Mail-Sicherheit) das Format. Sie ist standardmässig aktiviert, Outlook signiert also clear-signed. Wer die Option abschaltet, sendet opak. Das neue Outlook und Outlook im Web bieten diese Einstellung nicht an.

Mail-Gateways, die zentral signieren, haben eine eigene Einstellung für das Signaturformat. Einige Produkte signieren aus Robustheitsgründen standardmässig opak, weil die Signatur dann auch nach einem Umbruch durch nachgelagerte Systeme gültig bleibt. Erhalten Sie von einem bestimmten Absender regelmässig Mails mit fehlenden Anhängen, lohnt sich ein Blick in dessen Gateway-Konfiguration.

Warum das neue Outlook S/MIME nur im Primärkonto verarbeitet

Microsoft dokumentiert die Einschränkung, nennt aber keinen technischen Grund. Der Grund ergibt sich aus der Architektur des Clients.

Das neue Outlook ist im Kern der Web-Client von Outlook im Web in einer nativen Hülle. Im Browser darf JavaScript nicht auf den Windows-Zertifikatspeicher zugreifen. Deshalb brauchte Outlook im Web jahrelang eine separate S/MIME-Browsererweiterung. Das neue Outlook ersetzt diese Erweiterung durch eine eingebaute Brücke zwischen der Web-Oberfläche und der Windows-Kryptografie. Diese Brücke wird beim Anmelden des Primärkontos initialisiert und erhält dessen Mailbox-Sitzung, dessen Zertifikate und dessen S/MIME-Einstellungen aus Einstellungen > E-Mail > S/MIME.

Freigegebene Postfächer und Zweitkonten laufen über andere Datenpfade. Zweitkonten haben eigene Sitzungen, freigegebene Postfächer werden über die Delegation des Primärkontos geladen. Für diese Pfade war die Brücke bisher nicht angebunden. Das gilt auch für das reine Prüfen einer Signatur, obwohl dafür kein privater Schlüssel nötig wäre: das Parsen und Auspacken der PKCS#7-Struktur läuft über dieselbe Komponente.

Im klassischen Outlook tritt das Problem nicht auf, weil dort die S/MIME-Verarbeitung im MAPI-Stack pro Nachricht passiert, unabhängig davon, aus welchem Store die Nachricht stammt.

Microsoft ergänzt die fehlende Anbindung: Roadmap-Eintrag 565861 erweitert S/MIME im neuen Outlook auf freigegebene und delegierte Postfächer, die am Primärkonto hängen. Die allgemeine Verfügbarkeit ist für Juli 2026 angekündigt, der Rollout erfolgt gestaffelt. Sehen Sie die Meldung weiterhin, ist die Änderung in Ihrem Tenant oder Ihrer Client-Version noch nicht angekommen. Separat hinzugefügte Zweitkonten mit eigener Anmeldung deckt der Eintrag nicht ab.

Auswege

Welcher Weg passt, hängt davon ab, wie das Postfach eingebunden ist und ob Sie die Signatur prüfen müssen oder nur an die Anhänge wollen.

Den Container manuell auspacken

Für den Einzelfall reicht es, den Container ausserhalb von Outlook zu öffnen. Die Signatur wird dabei rechnerisch geprüft, die Vertrauenskette des Zertifikats aber nicht. Speichern Sie die Nachricht als .eml oder sichern Sie den Anhang smime.p7m in einen Ordner.

Unter Windows genügt PowerShell. Das .NET-Framework bringt die Klasse SignedCms mit, die den PKCS#7-Container liest:

Add-Type -AssemblyName System.Security
$bytes = [IO.File]::ReadAllBytes("C:\Temp\smime.p7m")
$cms = New-Object System.Security.Cryptography.Pkcs.SignedCms
$cms.Decode($bytes)
$cms.CheckSignature($true)
[IO.File]::WriteAllBytes("C:\Temp\inhalt.eml", $cms.ContentInfo.Content)

Unter Linux, macOS oder mit Git für Windows steht OpenSSL zur Verfügung. Liegt die ganze Mail als .eml vor, übernimmt OpenSSL auch das Base64-Dekodieren:

openssl cms -verify -noverify \
  -in nachricht.eml \
  -out inhalt.eml

Die Datei inhalt.eml enthält den ursprünglichen Nachrichtentext und alle Anhänge als normale MIME-Teile. Ein Doppelklick öffnet sie in Outlook, wo Sie die Anhänge wie gewohnt speichern.