How S/MIME Works in Plain English

S/MIME often feels complicated because most explanations begin in the middle. They mention certificates, public keys, and trust chains without first explaining the actual flow. A better starting point is to describe the process in the order it usually happens.

Step 1: A key pair exists

At the heart of S/MIME is a key pair:

• a private key, which must stay controlled and protected
• a public key, which can be shared

The private key is the sensitive part. It is what allows a user to sign mail and, for encrypted mail, decrypt content intended for that identity.

This is why on-device key generation matters for many Apple users. If the key is created directly on the device, the private key starts life under the user’s control instead of being generated somewhere else and handed over later.

Step 2: A certificate request is created

The next step is usually a certificate signing request, or CSR. A CSR is a structured request that says, in effect:

• here is the public key
• here is identifying information such as the email address
• please issue a certificate that binds this key to this identity

The CSR is not the final certificate. It is only the request. If you need that distinction in more detail, read What Is a CSR?.

Step 3: A CA or issuing service signs the certificate

Once the request is submitted, a certificate authority or internal issuing system reviews it according to policy and returns a signed certificate. That certificate tells compatible clients:

• this public key belongs to this identity
• this issuer stands behind that binding
• this certificate is valid only under certain conditions and dates

If the issuing chain is trusted by the device or mail client, the certificate becomes more useful in practice. If the chain is not trusted, users run into the familiar “certificate not trusted” or “cannot encrypt” style problems.

Step 4: The identity must be available to the mail client

The signed certificate on its own is not enough for most user workflows. The mail client generally needs an identity bundle that includes the certificate and its matching private key. That is why PKCS#12 files are so common in S/MIME workflows.

A .p12 or .pfx file usually acts as the container that carries the certificate and matching private key into a device. On Apple platforms, users often import that identity and then finish configuration through Settings or Mail-specific controls. The app-focused path is covered on the SMIME Toolkit page.

Step 5: Signing starts with your own identity

Once the user has an installed identity and the client recognizes it, the user can often sign outgoing mail. When the message is signed:

• the client uses the sender’s private key
• the recipient verifies the signature with the sender’s public certificate

If verification succeeds, the client can show that the message came from the expected identity and that the signed content was not altered.

This is why signing is often the first success state in an S/MIME deployment. It depends mostly on the sender’s own certificate and trust path.

Step 6: Encryption requires the recipient’s public certificate

Encryption is the part people want most, but it depends on more prerequisites. To encrypt a message to someone else, the sender needs the recipient’s public certificate. Without it, the client has no proper key to encrypt to.

That is why users often ask:

• Why can I sign but not encrypt?
• Why does the encrypt button stay unavailable?
• Why can’t the client find the recipient certificate?

Those are not random bugs. They follow directly from the way S/MIME works. Encryption requires recipient-specific public key material. That is covered in more detail in Recipient Certificate Unavailable.

Step 7: Trust still matters

Even when the certificate exists, the client still needs to trust the issuing chain appropriately. If the certificate was issued by a private CA, devices may also need the CA certificate and, on some Apple workflows, explicit trust settings.

This is where people encounter terms such as:

• certificate chain
• intermediate CA
• root CA
• trust profile
• certificate trust settings

If those terms sound fuzzy, read What Is a CA? and Certificate Chain and CA Trust Explained.

Why the process feels harder on Apple devices

Apple devices support S/MIME, but the operating system still controls the final installation and Mail behavior. That means a helper app can simplify certificate lifecycle tasks, but it cannot honestly claim to erase every platform step.

That is why a careful workflow usually looks like this:

1. generate keys
2. build the CSR
3. request the certificate
4. export the identity as .p12
5. import and trust it in Apple’s environment
6. enable signing and, when possible, encryption

The Apple-specific version of that flow is laid out in How to Set Up S/MIME on iPhone and How to Set Up S/MIME on Mac.

The easiest mental model to keep

If you only want one mental model, use this:

• key pair creates the cryptographic identity
• CSR asks for a certificate
• certificate links identity to the public key
• PKCS#12 moves certificate plus private key into a client workflow
• signing proves sender identity and message integrity
• encryption requires the recipient’s public certificate

Once those pieces click, most S/MIME troubleshooting becomes much less mysterious.