S/MIME as a protocol has been around for a long time.  In fact almost 30 years as it was developed as a secure extension to the Multipurpose Internet Mail Extensions (MIME) standard back in 1995.   

S/MIME leverages asymmetric encryption (RSA or ECC) to support both encrypting and singing of emails.   But S/MIME as a standard is far from perfect. While the S/MIME standard RFC 8551 specifies the syntax for the messages and how signature and encryption are applied, there was no corresponding standard to define how the underlying PKI should function.   This led to a "wild wild west" approach to issuing S/MIME certificates as vendors created their own processes for vetting and issuing certificates to mailbox users.  Additionally, the information in the x.509 certificates and the format of that information was also vendor-dependent affecting interoperability between email platforms.  

This approach unsurprisingly decreased both the security and value of using S/MIME for email as you 1) couldn't fully trust the sender and 2) often perfectly valid certificates would not validate properly, even if the message sent was signed and or encrypted following the standard. 

Thankfully, this PKI compliance gap has largely been addressed in recent years thanks in large part to the work done by the S/MIME working group within the CA/Browser forum: S/MIME Certificate Working Group | CA/Browser Forum.  New baseline requirements issued by this group has attempted to standardize the contents of S/MIME certificates for various applications as well as align domain and user validation methodologies with those used in the much more mature TLS certificate baseline requirements.  As a whole, S/MIME is in a much better position than it was only a few year ago.  But as I will discuss further in this article, there are still some issues that all practitioners attempting to implement S/MIME in their organization should be aware of.