S/MIME: What is it, why should I care, and how does it relate to SparkPost?. Learn about S/MIME encryption, signing, and its relevance to SparkPost, especially for regulated industries needing secure email communication.

• Premise: S/MIME (Secure/Multipurpose Internet Mail Extensions) is a long-standing standard for sending signed and encrypted emails—critical for industries that handle sensitive data like finance, healthcare, and government.

• Goal: Explain what S/MIME does, why it matters, how it differs from DKIM/DMARC/TLS, and how it integrates with SparkPost.

• **Highlights:**Definition: S/MIME enables two core capabilities:Encryption → Protects message content (privacy).

• Signing → Confirms sender identity, prevents tampering, and ensures non-repudiation.

• Industry use: Required or preferred by regulated sectors needing end-to-end message privacy and verifiable identity.

• **Comparison to other email protections:**TLS: Secures transmission between servers (transport layer).

• S/MIME: Secures the message content itself (presentation layer).

• DKIM/DMARC: Authenticate domains, not individuals, and work at the admin/server level.

• **Mechanics:**Uses public/private key pairs and digital certificates issued per email identity (e.g., alice@company.com).

• Requires supported mail clients (Apple Mail, Outlook, Thunderbird, iOS Mail, etc.).

• **Limitations:**Keys and certificates can be complex to manage.

• Encrypted payloads can't be scanned for malware.

• Headers (From, To, Subject) remain visible.

• **Integration with SparkPost:**SparkPost users can sign messages with S/MIME for added authenticity. For encrypted sending, recipients must first share their public key (e.g., by sending a signed message). Commercial partners like Virtru and Echoworx simplify this for enterprise workflows.

• Why is S/MIME important if I already use TLS or DKIM?TLS protects the connection between servers, while S/MIME protects the content itself—ensuring it stays private and verifiable even after delivery.
• Who needs S/MIME the most?Regulated industries (finance, government, healthcare) and any organization that sends confidential, legally binding, or identity-sensitive email.
• What problems does S/MIME solve?It prevents interception and spoofing, guarantees sender authenticity, and provides proof that a message wasn't altered.
• Does SparkPost natively support S/MIME?SparkPost supports sending S/MIME-formatted messages; you just need to sign/encrypt your content before submitting via API or SMTP.
• How do I get certificates?Certificates can be issued by providers such as Comodo (free for non-commercial use) or self-signed for internal testing.
• What if my recipient can't read encrypted emails?They'll still see the signed message header, but to decrypt, they must install a compatible client and have their private key imported.
• How is key exchange handled for app-generated emails?Recipients can email your service with a signed message; their public key can then be extracted automatically via inbound relay webhooks.

S/MIME is a long-established method of sending encrypted, signed email, based on public Internet standards.

The short version:

• Encryption gives you message privacy.
• Signing gives you authentication (of the sender), non-repudiation of origin, and message integrity checks.
• S/MIME works differently than DKIM and DMARC and can coexist with them.

PrivacyIf your messages contain nothing personal, private, or legally important, then you probably won't need to think about S/MIME. Modern email delivery systems such as SparkPost already use "opportunistic TLS" to secure the message transport from sending server to recipient server.

The "opportunistic" part does mean however that if the sending server can't negotiate a secure connection, we'll send the mail in plain text. This isn't suitable if you want to force the message to be secure all the way. You can take a peek at which mailbox providers claim TLS support and which actually do. Assuming the recipient's server does support TLS, your message is secured like this:

*TLS secures the conversations between mail servers (which it's why it's called Transport Layer Security). MIME (including S/MIME) is concerned with message content and its treatment, and can be thought of as being part of the "Presentation layer".

S/MIME secures the message content* all the way ("end to end") from the message origin to the recipient mail client, encapsulating the message body.

S/MIME encrypts the message body with the recipient's public key. The body cannot be decoded without the recipient's private key—not by any "person in the middle" such as your ISP, SparkPost, or the recipient's mail server.

Email encryption process highlighting TLS between a gear-labeled "Message Source" on the left, an flame icon representing encryption in the middle, and a envelope-labeled "Recipient" on the right.

A diagram illustrating email security with S/MIME encryption, showing a message source icon leading to an email symbol, both connected by TLS, with a locked envelope symbol representing the recipient, highlighting secure message delivery.

Mail systems for person-to-person messaging, such as Microsoft Exchange Server, have long supported S/MIME.

If you are using SparkPost to send to specific recipients with mail-clients that can read S/MIME, then it could make sense to S/MIME sign your messages. S/MIME signing adds further assurance that the message is actually coming from you (or your system), and has not been tampered with, which may be valuable in some use-cases. All you need for that is your own key and some free software that we'll demonstrate in part 2 of this article.

Using S/MIME encryption is a separate choice to make. You'll need the public key for each of your recipients. Obtaining this could be as easy as having them send you (or your app) a signed email. We'll explore a practical tool for sending S/MIME signed and encrypted mail through SparkPost in a follow-up post.

Consumer GmailThe ordinary Gmail web client displays incoming mail signatures (see below), but it's not set up to hold your private key to read encrypted messages. Even if that were possible via third-party plugins, uploading your private key is not a great idea from a security standpoint.

I couldn't get Yahoo! Mail to decode signatures in messages at all.

The consumer version of Microsoft Outlook/Hotmail accounts alert you to the presence of an S/MIME signature, but don't give you full access to view or check the certificate.

Hosted business mailFor organizations with hosted mail, Microsoft Office 365 and G Suite Enterprise have S/MIME support.

Outlook mail clientsClient-based Microsoft Outlook (e.g. 2010 for Windows) works:

Clicking on the icons gives you more information:

On Outlook 2010 / Windows, the certificate store is accessed via File / Options / Trust Center

Message titled "Test message with signature" from Steve Tuck, featuring a verified email address, date and time, and standard encryption details.

Message titled "Testing attachments etc," with the body text mentioning that S/MIME isn.

Message with the subject "Here is our declaration" featuring plain text and an orange arrow marking the message as important.

That's our quick overview of the practical uses of S/MIME. If you want to get your own mail certificates, there's a list of providers here. I found Comodo works well (free for non-commercial use – open this in Firefox, not Chrome).

In part 2, we'll explore how to apply S/MIME signing and encryption to messages that you deliver via SparkPost.

Further readingMicrosoft has a good introductory article on S/MIME in their documentation.

For more info on the EFAIL vulnerability and how it's been addressed, see the official EFAIL website. Other easy-to-follow explanations are available on the EFAIL wiki page and in CipherMail's blog post EFAIL: Which is vulnerable, PGP, S/MIME or your mail client?.

Read more from this category

Feb 3, 2020Introducing Programmable Email