S/MIME Encryption for Everybody, Automated. AI, Your Key
Why email communication needs an automatic cryptographic application layerSeptember 11, 2026

For more than two decades, the Internet has steadily moved toward encrypted communication. HTTPS is the clearest example. What once required specialist knowledge of certificates, trust and renewal has become largely invisible to users because the complexity was absorbed by browsers, hosting platforms, Certificate Authorities and automation infrastructure. Website operators do not normally think about certificate deployment every time they publish a page, the infrastructure handles it. But emails aren't so lucky; it's time to automate encryption too.

1. S/MIME Is Mature. Why Has Email Encryption Not Become Normal?

Web security has successfully transformed, but the Internet's earliest application—email—hasn't gone through the same transformation. S/MIME has provided standards-based email encryption, digital signatures and certificate-backed identity for decades. The underlying cryptography is mature, and modern email clients can support the necessary cryptographic operations. Yet S/MIME remains far from being a default capability of everyday email. The problem is therefore not whether email can be encrypted. The problem is why technology has remained difficult to operate.

The answer is that S/MIME sits across several layers that historically evolved separately. A Certificate Authority validates identity and issues certificates. An email client uses certificates and private keys to sign, encrypt, decrypt and validate messages. Administrators and users are left to connect those worlds, while also dealing with enrollment, key management, certificate installation, renewal, replacement, revocation and trust decisions. Each component can perform its own job correctly while the overall experience remains fragmented.

This is the long-standing Application Gap in S/MIME. The S/MIME certificate exists, the S/MIME client exists, and the cryptographic algorithms exist, but there has been no broadly adopted application layer that makes the complete process automatic and usable. That gap is easy to overlook because every individual technology appears to be present. At scale, however, the missing connection becomes the central problem.

The standards landscape is now moving in the same direction. RFC 8823 defined an ACME extension for automating end-user S/MIME certificate management, and the adoption of S/MIME ACME into the S/MIME Certificate Baseline Requirements provides a stronger foundation for automated certificate workflows. The significance is not that S/MIME has suddenly become possible. It is that the ecosystem is increasingly providing standardized mechanisms to remove operational friction around a technology that has already proved its cryptographic value.

2. The Missing Layer Is Between the Certificate and the Email Application

The distinction matters because certificate automation standard alone does not automatically create an encrypted email experience. A certificate can be issued automatically and still leave users or administrators to figure out how the certificate is used by an email application, how the corresponding private key is handled, how recipients' certificates are discovered, and how signing and encryption become normal parts of sending and receiving messages.

This is why the S/MIME problem should be viewed as an application problem as much as a certificate problem. The CA is responsible for trust and issuance. The email client is responsible for communication and cryptographic use. What has been missing is the layer that connects identity, certificate, key management and email behavior into one continuous workflow.

ZTmail is built around this idea. Rather than treating S/MIME as a certificate feature that users must learn to operate, ZTmail treats S/MIME as a cryptographic application that should operate automatically. The goal is to connect CA and trust infrastructure to the actual act of sending and receiving email, so that certificates lifecycle management and cryptographic operations become part of the application experience rather than a separate administrative project.

This also explains why ZTmail is not designed as a replacement for the existing email ecosystem. The objective is to connect the pieces that already work: PKI, Certificate Authorities, email systems, mail clients and security infrastructure. The missing value is the automation cryptographic application layer that makes them work together as a practical S/MIME system.

The result is a different way to think about email encryption. Instead of asking users or administrators to assemble a cryptographic system from certificates, keys, clients and policies, the application layer can make those components operate as one continuous process. The technology underneath remains standards-based; what changes is the operational model.

3. Two Paths Are Needed to Make S/MIME Work at Internet Scale

Once the Application Gap is understood, another practical issue becomes clear: email is used at two very different levels. Individuals and small teams need an application that makes cryptographic communication simple without requiring certificate expertise. Organizations need an infrastructure model that can apply the same capability across many mailboxes, integrate with existing email security controls and operate continuously at organizational scale. Solving only one of these problems cannot make S/MIME a general capability of Internet email.

ZTmail therefore provides two complementary paths. ZTmail App brings S/MIME directly into the email application experience for individuals and smaller teams. ZTmail Gateway addresses the organizational side by moving S/MIME automation into the email infrastructure. The two paths are different implementations of the same missing application layer: one brings cryptographic automation to the user, while the other brings it into the organization's communication infrastructure.

The same principle applies to trust. ZTmail uses two trust domains so that different communication requirements do not have to be forced into one model. ZTmail Trust is designed for organization-scale S/MIME deployment and trusted identity within the ZTmail ecosystem. Global Trust uses internationally recognized Public CA trust where communication must be recognized beyond that ecosystem. The two domains provide complementary trust paths within one S/MIME automation approach.

This distinction matters because encryption and trust are related, but they are not identical. Encryption protects message content. Digital signatures and certificate-backed identity provide a mechanism for establishing a cryptographically verifiable identity signal. A practical S/MIME system therefore needs both the ability to protect the message and a way to make trusted identity usable in normal communication.

For S/MIME to become broadly adopted, both sides of the Internet email population have to be addressed. It is not enough to make enterprise deployment possible while leaving individuals and smaller organizations with the same certificate complexity. Nor is it enough to make one user's mailbox simple while organizational deployment remains operationally difficult. A scalable model has to make cryptographic communication practical at both levels.

4. AI, Your Key: From Trusted Communication to Intelligent Communication

Email is not only becoming more secure; it is becoming more intelligent. Generative AI is changing how people draft, translate, summarize and act on messages, while the same technology is also making phishing, impersonation and business email compromise more convincing. That creates an important distinction. AI can help people understand and act on email, but it should not become a substitute for cryptographic trust. The stronger model is to combine the two.

ZTmail's approach is captured in the phrase “AI, Your Key.” Users can choose the AI provider they trust and connect to that service using their own API key. The point is not simply adding an AI button to an email client. It is to preserve user control over the AI relationship while making AI available as part of the everyday communication workflow. The provider choice and API credential remain the user's decision, rather than becoming an inseparable dependency on a single proprietary AI service.

The first opportunity is AI for Productivity. A user's chosen AI service can help draft or refine messages, translate content, summarize long conversations, extract tasks and identify information that requires a response. These capabilities reduce the amount of time people spend processing email without changing the underlying trust model of email communication.

The second opportunity is AI for Security. AI can help analyze suspicious messages, explain why a message may be risky, identify patterns associated with phishing or impersonation, and help users interpret the difference between an ordinary email address and a cryptographically supported identity. In this model, AI becomes an assistant for security decisions rather than the source of trust itself.

That distinction is increasingly important as attackers use AI to make fraudulent communication more convincing. Cryptography can establish a verifiable foundation for identity and protect message content; AI can then help the recipient understand that communication and respond to it more effectively. The combination is more useful than either technology alone: cryptography establishes trust, while AI helps people use that trusted communication productively and safely.

This is also why “Your Key” matters beyond AI. ZTmail is built around the principle that users should retain control of their private cryptographic keys and, where they choose to use AI, control the connection to their selected AI service. The application layer should simplify cryptography without hiding the fundamental question of who controls the keys and who processes the information.

5. From Possible Technology to Default Communication Capability

The history of HTTPS shows that encryption becomes broadly adopted when users no longer have to manage the machinery that makes encryption possible. The cryptography matters, but the decisive transformation comes when certificates, trust, renewal and deployment are absorbed into infrastructure and applications.

Email needs the same transition. S/MIME already provides the cryptographic foundation for message encryption, digital signatures and certificate-based identity. PKI provides the trust model. Certificate Authorities provide identity validation and certificate issuance. Email clients provide the communication interface. ACME provides an increasingly standardized mechanism for certificate automation. What has been missing is the application layer that connects these capabilities into a system people and organizations can use continuously.

That is the role ZTmail is designed to fill. It does not ask the Internet to invent another email encryption standard. It asks the industry to finish the automation work around a standard that already exists. When identity, certificates, keys and cryptographic operations become part of the normal email experience, encryption can move from something users or administrators deliberately configure to something the email system simply does.

The launch of ZTmail isn't just about adding another email security product, it is to complete the missing layer between digital trust and everyday communication. Individuals, small businesses and enterprises all need practical ways to use the same underlying cryptographic principles, even though their deployment models are different. Only by addressing both the personal and organizational sides can S/MIME move toward being a general capability of Internet email.

And as email becomes increasingly assisted by AI, trusted communication should become more intelligent without becoming less controlled. S/MIME provides the cryptographic foundation. Automation makes it usable. AI can help people work with it. The user's own keys and chosen AI connection keep control of where it belongs.

S/MIME Encryption for Everybody, Automated. AI, Your Key.

Welcome ZTmail to the world today, welcome to the world of ZTmail today.

Click here to read PDF edition (digital signature and timestamp with global trust and global legal effect, all rights reserved, plagiarism is prohibited! Please indicate when reprinting: Reprinted from ZoTrus CEO Blog)