BlueMail's S/MIME support lets you send and receive digitally signed and encrypted email, so your recipients can prove a message really came from you, and sensitive mail can be read only by the person it was addressed to.
Where S/MIME lives
Go to Settings | Privacy & Security | End-to-End Encryption, then tap S/MIME Encryption & Signing and choose the account you are setting up. The same screen holds PGP Encryption if you use that instead; see PGP keys.
S/MIME is part of BlueMail Enterprise. Where it is not yet included, the screen shows an Enterprise license required note with a Billing link.
Adding your certificate
BlueMail uses .p12 and .pfx certificate files, and there are two slots on the account: Signing certificate and Encryption certificate. Tap Select… beside either one, pick your file, and enter the password that protects it at the Certificate password prompt. Many certificates cover both jobs, in which case you import the same file into both slots.
Once imported, BlueMail shows the certificate's validity dates and its SHA-256 fingerprint so you can confirm you loaded the right one.
The certificate has to be issued to the same address as the account. If it is not, BlueMail says so directly rather than leaving you to guess.
Step by step for your platform: iPhone and iPad · Android · Windows · Mac · Linux
Rolling S/MIME out to managed devices
On BlueMail Enterprise, nobody needs to handle certificate files by hand. An administrator can deliver each user's S/MIME identity with the app itself, through iOS Managed App Configuration or Android Enterprise managed configurations, so staff open BlueMail with signing and decryption already working. No file to distribute, and no password passed around.
BlueMail matches a pushed certificate to the right account by the email address inside the certificate, so it reaches the correct mailbox without per-device setup. The import runs once and is then skipped, so reopening the app never repeats it, while publishing a replacement at renewal rolls the new certificate out on its own.
For administrators. Managed configuration is part of BlueMail Enterprise and is switched on for your organization as part of setting you up, so arrange it with your BlueMail contact first. It is enabled per customer rather than being on for everyone. Once live for your tenant, set these keys in the configuration you deliver to BlueMail:
| Key | Type | What it does |
|---|---|---|
enableSmime | boolean | Grants the S/MIME entitlement to the account |
smimeP12 | string | The identity, as a base64-encoded .p12 |
smimeP12Password | string | The password protecting that .p12 |
enableSmime is the managed equivalent of the license grant, so a managed device needs no separate entitlement. Booleans may be sent as real booleans or as the strings "true" and "false".
The same channel carries BlueMail's other managed settings, so S/MIME goes out alongside the rest of your policy in one payload. For the full and current list, and example payloads for your console, see Can I deploy BlueMail with MDM?.
The two platforms differ only in timing: Android broadcasts restriction changes, so BlueMail picks up a new configuration as soon as your EMM applies it, while iOS re-reads it when BlueMail next comes to the foreground.
Signing or encrypting a message
When you compose, a security button sits to the right of the Subject line. Tap it for the S/MIME encryption sheet and pick how to send this particular email:
- None: send without signing or encryption
- Sign: verify your identity to recipients
- Encrypt: only recipients with a key can read it
- Sign & Encrypt: recommended
For a standing preference, use Default behavior for outgoing mail on the S/MIME screen: Digitally sign all outgoing messages, Encrypt messages by default when all recipients support S/MIME, and Send clear-signed copies for compatibility.
Encryption needs the recipient's certificate. BlueMail looks these up as you address the message, and if one is unavailable it names that recipient under Missing S/MIME certificates instead of sending mail they could not open. The easiest way to build up certificates is to exchange signed mail, since a signed message carries the sender's certificate with it.
Reading signed and encrypted mail
The message header carries a badge saying what BlueMail verified: Signed, Encrypted, Signed & Encrypted, or Signed · unverified sender when the signature cannot yet be tied to a trusted authority. Tap it for S/MIME Message Information, which names the certificate that signed or decrypted the message and shows its fingerprint.
Trusted CAs
Verifying other people's signatures relies on trusting the authority that issued them. The Trusted CAs section handles this, and importing your own .p12 also trusts its issuing chain, which usually covers colleagues who share your issuer. For anyone else, tap Import CA certificate and pick their .pem or .cer file.
This is what makes encryption possible, not just tidy. BlueMail keeps a sender's certificate when their signed message arrives and the signature verifies against an authority you trust. So if their issuer is not in this list, the certificate is not kept, and encrypting to that person stays unavailable however many signed messages they send. Importing their CA once fixes both at the same time: their signatures start reading as verified, and you can start encrypting to them.
If something needs attention
- A signature shows as unverified. BlueMail gives the reason underneath, and it points at the fix, most often "The signer's certificate isn't from a trusted authority. Import its CA to trust it." Other reasons cover an address that does not match the sender, and a certificate that has expired, is not valid yet, or is not authorized for email.
- An import did not take. BlueMail reports "Import failed. The password may be incorrect, or the file isn't a valid certificate." Certificate passwords are case-sensitive; if the password is lost, ask your certificate provider for a fresh file.
- You cannot encrypt to someone. Ask them to send you a signed email first, and their certificate comes with it.
