New Outlook: S/MIME signature cannot be verified in secondary account, attachments missing

When opening a digitally signed email in a shared mailbox in the new Outlook for Windows, a red banner appears: “The S/MIME signature cannot be verified when viewing in a secondary account.” The email itself is displayed, but its attachments are not, even though the sender included them. Colleagues who use the same mailbox as their primary account can see the attachments without any issues.

Two things are behind this, and they compound each other: the new Outlook processes S/MIME only in the primary account, and the sender signed the email opaquely. With this signing format, the complete content, including attachments, is contained in a single cryptographic container. If the client cannot open the container, the attachments remain invisible. Both issues can be resolved separately.

What the message means

In the new Outlook, “secondary account” means any mailbox other than the account you signed in with. This applies to shared mailboxes that are displayed through Full Access and automapping, as well as mailboxes you added through “Add shared mailbox,” and delegated mailboxes. S/MIME processing in the new Outlook is firmly tied to the primary account. When a signed message arrives in another account, the client does not verify the signature and displays the message instead.

This does not indicate anything about the validity of the signature and is not a certificate issue on the sender’s end. The same email can be verified and opened in the primary account or in classic Outlook.

Clear Signing and Opaque Signing

The S/MIME standard (RFC 8551) defines two formats for signed messages. Both provide the same signature, but package the message differently.

You can identify the two formats in the message source by the Content-Type header. A clear-signed email begins like this:

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

An opaque-signed email begins like this:

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

The difference fully explains the behavior in the new Outlook. With a clear-signed email, the client displays text and attachments even when it does not verify the signature; only the signature status is missing. With an opaque-signed email, the client must first unpack the container through S/MIME processing to access the text and attachments. If it refuses because the message is in a secondary account, the container remains closed. The fact that the text is still readable is due to Exchange Online: the service renders the text portion server-side, but not the attachments from the container.

Neither format encrypts anything. Even the opaque variant is only Base64-encoded and can be read by anyone who gets hold of the message. Microsoft explicitly points this out in its Exchange Online documentation.

Which format the sender chooses

In classic Outlook, the “Send clear text signed messages” option (File > Options > Trust Center > Email Security) controls the format. It is enabled by default, so Outlook signs emails as clear-signed. Anyone who disables the option sends opaque-signed messages. The new Outlook and Outlook on the web do not offer this setting.

Mail gateways that sign centrally have their own setting for the signature format. Some products sign opaquely by default for robustness, because the signature then remains valid even after rewrapping by downstream systems. If you regularly receive emails with missing attachments from a particular sender, it is worth checking that sender’s gateway configuration.

Why the new Outlook processes S/MIME only in the primary account

Microsoft documents the limitation but does not state a technical reason. The reason follows from the client’s architecture.

At its core, the new Outlook is the Outlook on the web client in a native shell. In a browser, JavaScript cannot access the Windows certificate store. This is why Outlook on the web required a separate S/MIME browser extension for years. The new Outlook replaces this extension with a built-in bridge between the web interface and Windows cryptography. This bridge is initialized when signing in to the primary account and receives that mailbox’s session, certificates, and S/MIME settings from Settings > Mail > S/MIME.

Shared mailboxes and secondary accounts use different data paths. Secondary accounts have their own sessions, while shared mailboxes are loaded through delegation from the primary account. So far, the bridge has not been connected for these paths. This also applies to merely verifying a signature, even though no private key would be required: parsing and unpacking the PKCS#7 structure uses the same component.

The problem does not occur in classic Outlook because S/MIME processing takes place in the MAPI stack on a per-message basis, regardless of which store the message comes from.

Microsoft is adding the missing integration: Roadmap item 565861 extends S/MIME in the new Outlook to shared and delegated mailboxes attached to the primary account. General availability is announced for July 2026, with a phased rollout. If you still see the message, the change has not yet reached your tenant or client version. The item does not cover separately added secondary accounts with their own sign-in.

Workarounds

Which option fits depends on how the mailbox is connected and whether you need to verify the signature or just access the attachments.

Unpacking the container manually

For an isolated case, simply open the container outside Outlook. The signature is cryptographically verified in the process, but the certificate trust chain is not. Save the message as .eml or save the smime.p7m attachment to a folder.

On Windows, PowerShell is sufficient. The .NET Framework includes the SignedCms class, which reads the PKCS#7 container:

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)

On Linux, macOS, or with Git for Windows, OpenSSL is available. If the entire email is available as .eml, OpenSSL also handles Base64 decoding:

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

The file inhalt.eml contains the original message text and all attachments as normal MIME parts. Double-clicking it opens it in Outlook, where you can save the attachments as usual.