S/MIME Checker

Check if a certificate supports S/MIME email encryption

About S/MIME Email Encryption

S/MIME (Secure/Multipurpose Internet Mail Extensions) is a protocol for email encryption and digital signing that uses X.509 certificates. A certificate must include the Email Protection Extended Key Usage (EKU) to be valid for S/MIME. Our S/MIME Checker inspects a server's certificate to determine whether it supports secure email communication, verifying the EKU extension and extracting the embedded email address.

How to Use

Enter the domain name of the server hosting the certificate.
Click Check S/MIME to fetch and analyze the certificate.
Review the S/MIME support status and certificate details.
Check the Subject, Issuer, and embedded email address if available.

Use Cases

Email Security Audit: Verify that your organization's email certificates include the correct S/MIME Extended Key Usage for secure communication.
Certificate Procurement: Confirm that a certificate you plan to purchase or renew will support S/MIME email encryption and signing.
Compliance Checks: Ensure email certificates meet regulatory requirements for encrypted communication in healthcare, finance, and legal sectors.
Vendor Verification: Validate that third-party email services use proper S/MIME certificates for end-to-end encrypted email.

Frequently Asked Questions

S/MIME is a standard for public key encryption and digital signing of email messages. It allows senders to encrypt email content and attachments, and recipients to verify the sender's identity through digital signatures.

TLS (STARTTLS) encrypts the connection between email servers during transit, while S/MIME encrypts the email message itself end-to-end. S/MIME ensures that even if the email server is compromised, the message content remains encrypted.

S/MIME certificates include the Email Protection EKU (1.3.6.1.5.5.7.3.4) in their Extended Key Usage extension. Some certificates also include the Email Signing (1.3.6.1.5.5.7.3.4) and Email Encryption (1.3.6.1.5.5.7.3.4) key purpose IDs.

Because TLS and S/MIME certificates carry different key usage. A web certificate normally omits the email protection usage, which means mail clients will refuse it even though it validates perfectly in a browser. Issuing a separate certificate per use is the correct approach, and it is why S/MIME deployments usually automate issuance separately rather than reusing web PKI material.

It is the identity claim recipients match against. A certificate proves control of a key; the email in the subject is what binds that key to an account. If the address does not match the account being used, senders show the sender name unverified or reject the message — and unlike web certificates there is no visual cue, so the mismatch is easy to miss.

Both, in separate operations. Signing proves the message came from the holder of that key and was not altered. Encryption uses the recipient's certificate public key so only they can read it. The signing half is what users notice as verified; the encryption half is what protects confidentiality, and a certificate used only for signing gives recipients no protection against reading in transit.

Both, depending on direction and on how strict the client is. Most clients will not send with an expired certificate, and many will refuse or warn on receiving mail signed by one, since a signature that cannot be trusted is worse than none. Some older clients accept expired certificates silently, which is the dangerous case — the signature looks verified when nobody verified it.

Usually a chain problem or a policy restriction. The certificate may chain to a root the recipient's trust store lacks, particularly for privately issued S/MIME CAs, which is common in corporate deployments. Policy is the other cause: many organisations restrict which senders may use their domain, so a certificate that is perfectly valid is still rejected because the domain is not on the list.

What the Check Reads

S/MIME differs from TLS in one important way: a certificate is not enough. Identity comes from the email address in the subject, and permission comes from the extended key usage. This page checks both.

1Retrieve the certificate and confirm an extended key usage of email protection is present. Without that usage the certificate is not valid for S/MIME, even when it is a perfectly good TLS certificate — which is the usual cause when someone reuses a web certificate for mail.
2Extract the email identity from the subject, reading the RFC822 name attribute where present. That address is what recipients match against, so a certificate whose email does not match the account is the common failure — and it is invisible in the padlock equivalent, since there is none.
3Report both facts together, plus subject and issuer for identification. A certificate with the right usage but no email identity, or an email identity with no usage, fails for different reasons and the two conditions should be read separately.

This page checks the certificate as served. For mail, the authoritative view is what your mail client or server actually trusts, since S/MIME policy is enforced locally and varies between applications.

Tips & Best Practices

•Use S/MIME certificates for secure email encryption and signing
•Verify S/MIME certificate configuration for email security
•Test S/MIME functionality across different email clients
•Monitor S/MIME certificate expiry to maintain email security

Technical Details

Protocol: Secure/Multipurpose Internet Mail Extensions (S/MIME) support
Features: Email encryption, digital signing, and certificate validation
Clients: Email client S/MIME compatibility
Output: S/MIME support status with configuration recommendations