The short answer
Apple Mail handles S/MIME on both platforms with no add-on, but macOS and iOS install the certificate in completely different ways. On a Mac you import the PKCS#12 file into Keychain Access, where it lands in the login keychain under My Certificates, and Mail uses it after a restart. On iPhone and iPad the same .p12 installs as a configuration profile — tap the file, approve it in Settings, enter your device passcode and then the certificate password — after which the Sign and Encrypt by Default switches appear under that account's Advanced settings. As of August 2026, one caveat is worth knowing before you start: the tap-the-sender step that installs a correspondent's certificate is widely reported not to work on iPhones running iOS 26, which blocks encryption until you route around it.
Most guides on this subject cover one device and imply the other works the same way. It does not, and that mismatch is where the afternoon goes. What follows is the Mac path, the iPhone path, and then the part neither Apple nor any certificate authority explains well: why a correctly installed certificate still refuses to encrypt anything.
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.
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.
| Action | Whose key it uses | Available when | Fails how |
|---|---|---|---|
| Signing | Your private key | Immediately, once your certificate is installed | Control missing — no matching identity for the account |
| Encrypting | The recipient's public certificate | Only for recipients whose certificate you already hold | Control greyed out for that recipient |
| Reading encrypted mail | Your private key, including expired ones | As long as the key that decrypts it is still installed | Permanently unreadable if that key was deleted |
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.
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.
Getting the certificate itself
Everything above starts with a PKCS#12 file issued to the address you send from. S/MIME email certificates from My-SSL come from Certum, a publicly trusted certificate authority, so signatures verify in Apple Mail without anyone installing a root first — and one certificate covers your Mac, your iPhone and any other client using that address.
Related reading
- Installing an S/MIME certificate in Outlook — the same file on Windows, where the import lives in a different place again.
- Setting up S/MIME in Google Workspace — what changes when the mailbox does the signing instead of the device.
- S/MIME certificate buying guide — which validation level to order before any of this starts.