Exchanging S/MIME Encrypted E-Mail Between Different Clients
Sarah MitchellShare
Secure/Multipurpose Internet Mail Extensions (S/MIME) is a single standard implemented by many clients, and a message encrypted in Outlook opens cleanly in Apple Mail, Thunderbird, or a phone, provided one piece of groundwork happened first. Almost every cross-client failure traces back to that groundwork being skipped, so this guide starts there.
The Bootstrap Rule
Encrypting a message to someone uses their public E-Mail Certificate, which your client must already hold.
The standard distributes those E-Mail Certificates inside signed messages, so the working pattern between any two people is the same everywhere. Each person sends the other one signed message first, each client quietly stores the E-Mail Certificate it received, and encryption becomes available in both directions from then on.
An encrypt button greyed out for a recipient means this exchange has not happened yet, not that anything is broken. Send signed, ask for a signed reply, and the button lights up.
What Each Side Needs
Both people need their own E-Mail Certificate installed and assigned in their client of choice, with the platform guides covering the setup on each. Issuance against the mailbox completes after a validation step confirming control of the address. Learn About S/MIME Mailbox Validated E-Mail Certificates 🔗
Both sides also need the Intermediate Certificates available, since a client that cannot build the chain treats an otherwise perfect signature as untrusted, which then blocks the harvesting that encryption depends on. Learn About Intermediate Certificates 🔗
Client Differences Worth Knowing
Outlook stores harvested E-Mail Certificates against its contacts, and in some configurations wants the sender added as a contact before the entry sticks. Apple Mail and Thunderbird harvest automatically from any signed message, no contact step involved.
Webmail sits apart, since browser based interfaces generally cannot perform the cryptography themselves. Hosted arrangements such as Workspace handle it server side on supported plans, while everything else reads encrypted mail through a desktop or mobile client connected to the same mailbox.
Important : Encrypted mail is locked to the Private Keys of its recipients forever. A new computer, a reinstalled client, or a replaced E-Mail Certificate without the old PKCS12 file backed up means old encrypted messages stay sealed, so every participant should keep their file and password archived safely.
With the groundwork understood, the remaining failures sort into three patterns.
Diagnosing Cross-Client Failures
A recipient who cannot decrypt at all is reading on a device missing their Private Key, common when mail is opened on a phone that never had the PKCS12 file installed. Installing their identity on that device resolves it, and nothing on the sender side helps.
A signature shown as invalid rather than untrusted means the message was altered in transit, usually by a gateway rewriting content, such as footers appended after signing. The fix lives in the mail flow rules rather than in any E-Mail Certificate.
An encryption failure naming an expired or revoked E-Mail Certificate means the harvested copy has aged out, and a fresh signed message from that person carries the replacement. Replacements on your own side issue quickly when needed. Learn About Reissuing Your Certificate 🔗
The standard itself rewards a background read once the mechanics are working. Learn About S/MIME E-Mail Certificates 🔗
