S/MIME Certificate Discovery: How to Encrypt the First Email Automatically
.png)
S/MIME certificate discovery: how to encrypt the first email automatically
How can you send an encrypted email to someone whose S/MIME certificate you don't have? This is one of the most persistent challenges in secure email communication.
S/MIME (Secure/Multipurpose Internet Mail Extensions) enables organisations to encrypt and digitally sign emails using public key cryptography. But before sending an encrypted message, the sender needs the recipient's public key certificate.
Traditionally, that certificate must be exchanged manually, retrieved from a directory, or obtained from a previously signed email.
S/MIME Certificate Discovery (SCD) offers another approach: automatically finding recipients' encryption certificates through DNS and HTTPS, before the first email is sent.
This proposed decentralised mechanism could make encrypted email easier to deploy across organisations, without requiring manual certificate exchanges or a central certificate directory.
What Is S/MIME certificate discovery?
S/MIME Certificate Discovery (SCD) is a proposed method for automatically locating the public key certificates needed for S/MIME email encryption.
It allows a compatible email client or secure email gateway to discover certificates published by the recipient's domain using existing internet infrastructure.
Instead of requiring users to exchange certificates manually, SCD uses:
- DNS records to indicate whether a domain supports certificate discovery.
- HTTPS to retrieve publicly available S/MIME certificates.
- Well-known paths to provide predictable certificate locations.
- Certificate validation to ensure retrieved certificates meet the sender's security requirements.
The result is a federated approach to S/MIME certificate discovery in which each organisation controls its own certificate publication.
Why Is S/MIME certificate discovery important?
S/MIME email encryption depends on public key certificates.
When a sender encrypts an email, the recipient's public key is used to protect the message. The recipient uses the corresponding private key to decrypt it.
The difficulty is obtaining that public key certificate before communication begins.
The first-email encryption problem
Consider an employee who wants to send confidential information to a new business partner.
Their organisation supports S/MIME encryption, but the recipient's certificate is not available locally.
The sender may have to:
- Ask the recipient to send a digitally signed email.
- Request the certificate as an attachment.
- Search a public or organisational certificate directory.
- Ask an administrator to obtain and import the certificate.
These steps introduce friction, especially when communicating with new external partners.
For organisations exchanging sensitive information with hundreds or thousands of recipients, manual certificate discovery can become a significant operational burden.
SCD is designed to eliminate that initial certificate exchange by making certificates discoverable before communication begins.
How does S/MIME certificate discovery work?
SCD combines two established approaches: DNS-based service discovery, similar in concept to MTA-STS, and web-based public key publication, similar to the OpenPGP Web Key Directory.
Step 1: Check whether the recipient's domain supports SCD
Before sending an encrypted email to alice@example.org, a compatible sender checks the recipient domain's DNS configuration.
A designated TXT record indicates whether the domain supports S/MIME Certificate Discovery.
If the domain does not advertise SCD, the sender can continue using its existing certificate lookup methods.
This opt-in approach avoids unnecessary HTTPS requests to domains that do not participate.
Step 2: Locate the recipient's S/MIME certificate
For participating domains, certificates are published through a predictable HTTPS location, such as:
https://smimecert.example.org/
The proposed mechanism uses a well-known directory structure and a hashed representation of the mailbox's local part to locate individual certificates.
This means certificate files do not need to expose readable email addresses in their filenames.
Hashing reduces direct exposure of mailbox names, although it should not be treated as complete anonymity or protection against guessing attacks.
Step 3: Retrieve and validate the certificate
The sender downloads the certificate and applies its existing S/MIME certificate validation policy.
Checks include:
- Whether the certificate chains to a trusted certificate authority.
- Whether the certificate is within its validity period.
- Whether its identity matches the intended recipient.
- Whether it is appropriate for email encryption.
- Whether it has been revoked, according to the sender's validation policy.
Certificate discovery does not automatically establish certificate trust.
The certificate must still pass the checks required by the sending organisation.
Step 4: Encrypt the email
Once a valid certificate has been retrieved and accepted, the sender can use its public key to encrypt the email.
The certificate may then be cached or stored for future messages, subject to certificate validity, revocation checks, and local security policy.
This makes encrypted communication possible without first requesting a signed message from the recipient.
S/MIME certificate discovery vs traditional certificate exchange
Different certificate distribution methods solve the same fundamental problem: how to obtain the recipient's public key.
Unlike centrally operated directories, SCD is designed around domain-controlled publication.
Each organisation publishes its own certificates without requiring a universal certificate provider or central registry.
Decentralised certificate discovery without a central directory
One of SCD's defining characteristics is its federated architecture.
Every participating organisation publishes certificates for its own domain.
There is no global registry to join, no central certificate lookup operator, and no requirement for bilateral agreements between organisations before publishing certificates.
This provides several potential advantages.
Greater organisational control: Certificate publication remains under the control of the domain owner.
Reduced central dependency: Discovery does not depend on a single global directory provider.
Incremental adoption: Organisations can enable certificate publication independently.
Simplified hosting: Certificate files can be hosted using conventional HTTPS infrastructure, including static hosting services.
Reduced third-party visibility: Lookup information is not automatically exposed to a central certificate directory operator.
However, DNS infrastructure, hosting providers and network intermediaries may still observe aspects of the lookup process. Decentralisation reduces centralised dependencies; it does not eliminate every metadata or availability risk.
Mailbox certificates vs domain certificates
SCD supports two different certificate publication models: individual mailbox certificates and domain-level certificates.
Individual mailbox certificates
A mailbox certificate belongs to a specific email identity, such as alice@example.org.
A sending system retrieves the recipient's certificate and uses it to encrypt messages for that mailbox.
This model is suitable for organisations that manage individual S/MIME certificates for employees or users.
Domain certificates
Some organisations prefer to perform email encryption and decryption centrally through a secure email gateway.
In the proposed SCD design, a domain can publish a certificate intended for domain-level gateway encryption.
The domain authenticates that publication using a signature associated with a public key advertised in DNS.
This allows participating senders to identify a domain-level encryption certificate without requesting a separate certificate for every mailbox.
Important: A domain certificate should not be treated as interchangeable with an ordinary mailbox certificate. Its use requires explicit support for the proposed mechanism and an appropriate trust and security policy.
Is S/MIME certificate discovery secure?
SCD separates two important security functions: certificate discovery and certificate trust.
Certificate discovery answers:
Where can I find a certificate for this recipient?
Certificate validation answers:
Can I trust this certificate for encrypting email to this recipient?
SCD does not replace existing S/MIME certificate validation requirements.
A certificate obtained through SCD must still satisfy the sender's trust policy, including certificate authority validation, identity verification, appropriate usage and revocation checks.
For mailbox certificates, the existing PKI trust model remains essential.
For the proposed domain-certificate model, the additional domain signature mechanism helps authenticate the published certificate.
This separation is important because a discovery service should not be able to make an otherwise untrusted certificate acceptable.
SCD can also complement existing certificate caches, allowing previously validated certificates to remain available when discovery infrastructure is temporarily unavailable, subject to the sender's security policy.
How SCD supports automated email encryption gateways
For organisations using a secure email gateway, certificate discovery can help reduce manual certificate management and simplify encrypted communication with external partners.
A compatible gateway can participate in SCD in two ways.
Publishing S/MIME certificates
A gateway that manages user certificates may be able to publish current certificates automatically.
This can involve:
- Exporting eligible public certificates.
- Generating the required directory structure.
- Publishing certificate files through HTTPS.
- Updating published certificates after renewal.
- Removing certificates that should no longer be advertised.
For gateway-level encryption, the organisation may instead publish a domain certificate using the proposed domain-signature mechanism.
Discovering certificates for outbound email
When sending a message to an external recipient, a compatible gateway can check whether a suitable certificate is already available.
If not, it can attempt SCD discovery.
When a participating recipient domain publishes an acceptable certificate, the gateway can retrieve and validate it before encrypting the outgoing message.
This creates the possibility of automatic S/MIME encryption from the first email, without requiring end users to exchange certificates manually.
The gateway's existing encryption policies remain responsible for deciding when encryption is required and what happens if no acceptable certificate is found.
How to Deploy S/MIME Certificate Discovery
The proposed publication model is designed to work with existing DNS and HTTPS infrastructure.
A basic deployment involves the following components:
Because the publication mechanism relies on static files, organisations do not necessarily need a dedicated certificate lookup API or database.
Static hosting or object storage with HTTPS support can provide the publication infrastructure.
However, correct implementation requires following the complete SCD specification, including its DNS record format, certificate naming rules, validation requirements and caching behaviour.
S/MIME certificate discovery and the future of secure email
Email encryption technology is mature, but certificate distribution continues to create practical deployment challenges.
For organisations communicating with external customers, suppliers and partners, certificate exchange can slow down the adoption of S/MIME encryption.
SCD addresses this challenge by combining existing internet technologies into a decentralised certificate discovery mechanism.
It follows the broader principle behind standards such as MTA-STS and OpenPGP Web Key Directory: allowing domain owners to publish security-related information through infrastructure they already control.
By making certificates discoverable before the first email, SCD could remove an important operational obstacle to wider S/MIME adoption.
S/MIME certificate discovery in CipherMail
CipherMail is working on integrating S/MIME Certificate Discovery into the CipherMail Secure Email Gateway, covering both certificate publication and certificate lookup.
The objective is to help organisations automate certificate discovery and reduce the manual work associated with exchanging encryption certificates.
The proposed specification is available for review and feedback.
Read the S/MIME Certificate Discovery specification (PDF)
For organisations looking to simplify S/MIME encryption and certificate management, explore the CipherMail Secure Email Gateway and its approach to centrally managed email security.
Frequently asked questions about S/MIME certificate discovery
What is an S/MIME certificate?
An S/MIME certificate is a digital certificate used to support email encryption and digital signatures. It associates a public key with an email identity and allows compatible email systems to verify signatures or encrypt messages using the recipient's public key.
How do I find someone's S/MIME certificate?
Traditionally, you can obtain an S/MIME certificate from a digitally signed email, a certificate directory, or directly from the recipient. S/MIME Certificate Discovery proposes an additional method that allows compatible systems to retrieve published certificates automatically through DNS and HTTPS.
Can I send an encrypted email without receiving a signed email first?
Yes, provided you already have access to a valid and trusted encryption certificate for the recipient. SCD is designed to make that certificate discoverable automatically, potentially allowing encryption from the first email.
Does S/MIME Certificate Discovery require a central server?
No central global directory is required. Each participating domain publishes its own certificate information through DNS and HTTPS. A domain still needs hosting infrastructure to serve its certificate files.
Does SCD replace S/MIME certificate validation?
No. SCD provides a method for discovering certificates, not a replacement for certificate trust. Retrieved certificates must still satisfy the sender's applicable validation and security requirements.
What is the difference between S/MIME and OpenPGP?
Both technologies support encrypted and digitally signed email. S/MIME typically uses X.509 certificates and certificate-authority-based trust, while OpenPGP uses a different key and trust model. SCD is a proposed discovery mechanism for S/MIME, inspired in part by the web-based discovery approach used by OpenPGP.
Can S/MIME certificate discovery work with an email encryption gateway?
Yes, if the gateway implements the proposed mechanism. A compatible gateway can publish certificates for its domain and retrieve certificates from participating recipient domains, supporting automated certificate discovery for outbound encrypted messages.
Is S/MIME Certificate Discovery an established internet standard?
The SCD mechanism described here is a proposed specification. It should not be confused with an already universally supported or finalised internet standard. Organisations should check implementation availability and compatibility before planning deployment.
.png)
