S/MIME can sign, verify, encrypt, and decrypt email. The visible result may be a mail client badge or a certificate icon, but the security decision happens underneath: does the certificate bind the public key to the mailbox address that the message claims, and does the client validate that identity and the certificate chain correctly?
The certificate needs an email identity
The CA/Browser Forum's S/MIME Baseline Requirements identify a publicly trusted S/MIME certificate by an extended key usage for id-kp-emailProtection and an email identity in subjectAltName, either an rfc822Name or the SMTP UTF-8 mailbox other name. The current published baseline is version 1.0.16, dated September 28, 2026.
The subject common name is not enough for a mailbox binding. A client should compare the sender address with the validated SAN identity and apply the certificate purpose. OpenSSL documents predefined verification purposes including smimesign and smimeencrypt, and the openssl smime command exposes -verify_email for checking an address against a certificate.
A mail gateway can verify the signature and still make an authorization mistake if it treats any trusted S/MIME certificate as proof of an arbitrary From address. The verification result should be tied to the exact address and the message being evaluated.
Separate signing from encryption
Signature verification answers whether the signed content matches the signer's key and the signer certificate was trusted under the configured policy. It does not establish that the message is safe or that the sender intended every later reply in the thread to be trusted.
Encryption requires a recipient certificate. A client should validate that the recipient address is bound to the certificate before encrypting. A certificate discovered in a directory is still subject to the chosen trust policy, revocation behavior, and identity validation. A valid signature on an unrelated old message is not the same as a current encryption certificate.
Build a practical validation profile
Record which mail clients and gateways validate S/MIME, whether they check the sender address, how they handle expired or revoked certificates, and whether they allow user-added roots. Test with a certificate whose SAN is a different mailbox, a correctly bound certificate, a certificate without the email-protection purpose, and a message whose From header changes after signing.
Do not treat a failed signature as proof of malicious intent. Forwarding, mailing-list rewriting, and client formatting can break the signed bytes. Preserve the original message and the cryptographic result before changing headers during investigation.
For automation, use a verifier that exposes the validated identity and certificate path rather than accepting a success flag alone. Log the signer address, certificate subject, issuer, validity window, result code, and the policy profile used. Those fields let an operator distinguish a cryptographic mismatch from a policy rejection.
S/MIME is useful when the identity binding and validation policy are explicit. The certificate is evidence, not an automatic statement of trust in the sender's intent.