How to Set Up S/MIME in Apple Mail (macOS and iPhone)

Why macOS and iPhone need different steps

Because the two operating systems store private keys through different front doors. macOS gives you Keychain Access, a normal application that imports a PKCS#12 file directly. iOS has no equivalent app, so anything carrying a private key arrives as a configuration profile — the same mechanism used for VPN settings and device management — which you review and approve in Settings rather than import.

Nothing about the certificate changes between them. It is one file, one password, one identity, and it can sit on a Mac, an iPhone, an iPad and a Windows machine at the same time without anything special being done to it. Only the installer differs, and only the iOS side asks for a device passcode, because iOS will not take a private key onto a device that has no passcode set. If you are still deciding which certificate to put on them, the guide to email certificates and their four validation types explains what each one names and checks.

One practical consequence: keep the original file. People install a certificate on their Mac, delete the download, then buy a second one months later for the phone. That is unnecessary — and if the file really is gone, Keychain Access can export a fresh PKCS#12 from the identity already installed.

What you need before you start

Three things: a PKCS#12 file with a .p12 or .pfx extension, the password protecting it, and an email account in Mail whose address matches the address on the certificate exactly. A .cer or .pem file is not enough — those carry a public certificate with no private key, so they can verify a signature but never create one. On iPhone you also need a device passcode already set.

The address match is the requirement that costs money when it is wrong. S/MIME binds a certificate to a specific mailbox address, and Mail will not offer to sign from an account whose address the certificate does not cover. An alias, a plus-address, or the company domain when the certificate names a personal one all fail the same way, and none of them can be corrected after issuance.

If you have not ordered yet, order for the address you actually send from. S/MIME certificates from My-SSL are issued by Certum, a publicly trusted certificate authority, and arrive as password-protected PKCS#12 files — the format both the Keychain Access import and the iOS profile installer expect, with no conversion step in between.

Installing the certificate on macOS

Double-click the .p12 file. Keychain Access opens and asks for the password that protects it, and once you enter that the identity is stored in your login keychain. Confirm it arrived by opening Keychain Access, selecting the login keychain and the My Certificates category — the entry should expand to show a certificate and its private key paired together. Then quit Mail and reopen it.

That last step is worth doing rather than skipping. Mail reads the keychain when it starts, so a running Mail can sit there with the certificate installed and no sign of it in the compose window, which reads exactly like a failed installation. Quitting properly — not just closing the window — and reopening resolves it.

A pair without the private key means the import took only the public half, and signing will never work from it. That usually means the file was a .cer or .pem after all, or that the PKCS#12 was exported somewhere without its key. Either way the fix is a new file from whoever issued the certificate, not more configuration.

Where the private key actually lives

In the login keychain, unlocked by your account password and nothing else. It is not synced to other Macs, and iCloud Keychain does not carry S/MIME identities between devices, so a second Mac needs the same import performed again. Treat the .p12 as the portable copy and the keychain entry as one installation of it.

Installing the certificate on iPhone and iPad

Get the .p12 onto the device — mail it to yourself, drop it in Files, or AirDrop it from the Mac — then tap it. iOS responds that a profile was downloaded rather than opening anything. Go to Settings, tap the downloaded profile, tap Install, enter your device passcode, tap Install again past the unsigned-profile warning, then enter the certificate password and tap Done.

Two passwords in a row trips people up. The first prompt wants the passcode that unlocks the phone; the second wants the password that protects the .p12. They are unrelated, and entering the phone passcode at the second prompt produces a failure that reads like a corrupt file. Installed profiles are listed under Settings, General, VPN & Device Management, which is the place to check if you are not sure the installation took.

With the certificate installed, turn signing on for the account: Settings, Apps, Mail, Mail Accounts, your account, Account, Advanced, and the S/MIME section. On iOS 17 and earlier the same screens live at Settings, Mail, Accounts, which is what older guides describe — iOS 18 moved per-app settings under an Apps section, and that single change accounts for a good share of the “the setting isn't there” reports.

If the S/MIME section is missing entirely, the device holds no identity matching that account's address. Check the profile installed, then check the address on the certificate against the address on the account. Those two checks account for nearly every case.

Deploying to a fleet rather than a phone

The manual route does not scale, and it is not meant to. Apple documents a certificate payload for mobile device management, so an MDM can push each person's PKCS#12 to their device along with the mail account settings. If you are rolling S/MIME out to a team, that is the path — the tap-through above is for individuals and pilots.

Signing and encrypting a message

On macOS, a signing control appears beside the subject line in the compose window once a matching identity is installed, and it is on by default. An encryption control appears next to it, but only becomes available when Mail already holds a certificate for every recipient. On iOS the equivalent behaviour is governed by the Sign and Encrypt by Default switches, with per-message overrides from the compose header.

The third row is the one that bites years later. Renewal issues a new certificate and a new key pair, and mail encrypted to the old key can only ever be opened with the old key. When you renew, add the new identity and leave the old one installed. Deleting an expired certificate to tidy up is a decision you cannot walk back.

Why you can sign but not encrypt yet

Because encryption needs the other person's certificate and you do not have it. Signing is one-sided: your own key is enough. Encrypting is not, and there is no directory Mail can look someone up in. Their certificate arrives when they send you a signed message — after that, Mail can encrypt to them, and not a moment before.

On a Mac this is invisible. Mail stores a sender's certificate on its own when a signed message arrives, and the encryption control simply starts working for that person. On iPhone it is a deliberate act: open the signed message, tap the sender's address, tap again once the check mark turns blue, and choose to view and install their encryption certificate.

Which brings up the caveat. Since iOS 26, a steady stream of reports on Apple's developer forums and support communities says that tap no longer offers the certificate on iPhone, while the same steps still work on iPadOS 26. The thread runs from September 2025 into April 2026 with no fix announced, and as of August 2026 we have found no Apple release note addressing it. Two workarounds circulate: editing the sender's contact card, which several people report makes the certificate register, and using Outlook for iOS to hold certificates instead. Both are user reports rather than documented behaviour — test on your own device before promising anyone encrypted mail from an iPhone.

None of this affects signing, which is the majority of what S/MIME is used for day to day, and none of it affects encryption on a Mac. It is worth planning around rather than discovering mid-rollout: if encrypted replies from phones are a requirement, verify that one flow on a real device before the certificates are ordered.

What to check when it doesn't work

Start with the address on the certificate, then the installation, then the recipient — in that order. Most reports resolve at the first or second check, and almost none are a fault in the certificate itself. The four cases below cover nearly everything that reaches a support queue about Apple Mail and S/MIME.

• Nothing appears in Mail after importing on macOS. Quit Mail completely and reopen it. Mail reads the keychain at launch, so a running instance will not notice a new identity.
• The iPhone profile installs, but no S/MIME section appears. The address on the certificate does not match the address on the account. Compare them character for character, including the domain.
• The certificate password is rejected. Check which prompt you are answering. iOS asks for the device passcode first and the file password second.
• Signed messages show a warning on the recipient's side. Usually a missing intermediate certificate or a client that does not trust the issuing CA. A certificate from a publicly trusted CA verifies without extra work in Apple Mail, Outlook and Thunderbird alike. The exception is Outlook on the web in Microsoft 365, which checks signatures against a virtual certificate collection an Exchange Online admin has to populate; our guide to why Outlook says an S/MIME certificate isn't trusted covers that fix.

If the same certificate also has to work on a Windows desktop, the Outlook installation guide covers the equivalent steps there, and the identical PKCS#12 file serves both without conversion. If the desktop in question runs Thunderbird, note that it ignores the operating system store entirely and needs the file imported into its own profile — setting up S/MIME in Thunderbird walks through that path.