What is S/MIME?

Still have a question, spotted an error, or have a better explanation or a source we should cite?

S/MIME (Secure/Multipurpose Internet Mail Extensions) is an email encryption and signing standard that uses certificates issued by trusted Certificate Authorities. It's the corporate version of email security. Enterprises use it to prove their employees are who they say they are and to encrypt sensitive internal communications.

Here's the practical difference between S/MIME and PGP. With PGP, you manage your own keys and build trust by meeting people in person or through a web of trust. With S/MIME, a Certificate Authority (like DigiCert or Entrust) verifies your identity, issues you a certificate, and your organization can centrally manage everyone's certificates. If an employee leaves, IT can revoke their certificate instantly. You can't do that with PGP.

But Most people encounter S/MIME when they receive an email from a large company or government agency and see a little lock icon or signature badge next to the sender's name. That badge means the email was digitally signed with an S/MIME certificate, proving it really came from that person and wasn't tampered with in transit.

S/MIME does two things. Signing proves the email came from you and hasn't been altered. Encryption scrambles the email content so only the recipient can read it. You can do one without the other. Most corporate use is signing only, because encryption requires the recipient to also have an S/MIME certificate, and that's rare outside of enterprises.

And if you're sending marketing or transactional email, you don't need S/MIME. It's not relevant for bulk sending. Your ESP handles transport encryption (TLS) automatically, and marketing emails aren't meant to be secret. S/MIME is for internal corporate email, financial institutions, healthcare providers, and government agencies that need to prove identity or protect sensitive data.

S/MIME also doesn't affect deliverability the way SPF, DKIM, or DMARC do. Mailbox providers don't use S/MIME to decide whether your email lands in the inbox. It's purely for end-to-end security between sender and recipient.

If you're curious whether an email you received is S/MIME signed, check the email headers. Look for "Content-Type: application/pkcs7-mime" or "application/x-pkcs7-mime". That's the technical fingerprint of an S/MIME message.

Contributors

Who worked on this answer

Every name links to their profile. Every company links to their site. Real people, real accountability.

Ask an AI · tailored to your setup

Ask AI: Do I need S/MIME for my setup?

I read this on the Email Almanac about S/MIME: "S/MIME is an email encryption and signing standard that uses certificates issued by trusted Certificate Authorities. Enterprises use it to prove their employees are who they say they are and to encrypt sensitive internal communications. Most people encounter S/MIME when they see a lock icon or signature badge next to a sender's name from a large company. S/MIME does two things: signing proves the email came from you, encryption scrambles the content so only the recipient can read it." Help me understand if S/MIME applies to my situation: 1. Do I need S/MIME for my type of sending? (marketing, transactional, internal corporate email) 2. How does S/MIME differ from SPF/DKIM/DMARC authentication? 3. If I receive S/MIME emails, what does that tell me about the sender? 4. Should I be concerned if my ESP doesn't support S/MIME? --- My details (fill in what applies): - Email platform/ESP: e.g. Mailchimp, SendGrid, Google Workspace, Microsoft 365 - Sending volume: e.g. 5,000/month or internal team of 50 - Email type: [marketing campaigns / transactional / internal corporate / mixed] - Industry: if healthcare, finance, government, or other regulated - Current challenge: what made you look up S/MIME?

Edit the yellow boxes, then send to the AI of your choice.