ZTmail Chat is an encrypted chat experience built on global email infrastructure. It integrates chat and email in ZTmail App, using S/MIME cryptography, certificate automation, digital signatures, and trusted identity display to help users communicate securely without relying on a separate, centralized instant messaging infrastructure.
Traditional instant messaging services typically operate on their own messaging platforms and store conversations within their service environments. ZTmail Chat uses email infrastructure as its communication foundation. A chat conversation remains an email underneath, protected by S/MIME where encryption is applied, and stored in the user's own mailbox. This approach brings chat and email together while using certificate‑based cryptography and trusted identity.
No separate ZTmail chat account is required. ZTmail Chat uses your existing email account and mailbox. You can switch between Mail Mode and Chat Mode in ZTmail App without maintaining a separate messaging account.
Strongly recommended but not required. The other participants do not need ZTmail App. They can continue using an existing S/MIME‑compatible email client.
To exchange S/MIME‑encrypted messages, the participants need the appropriate certificates and private keys, and their email clients must support the relevant S/MIME operations. ZTmail App provides an integrated Chat Mode experience for its own users, while other participants can continue communicating through compatible email clients.
Yes. ZTmail Chat is built on your existing email infrastructure. You can add a supported email account to ZTmail App and use it for both email and chat. Account configuration depends on the capabilities and security requirements of your email provider.
No. ZTmail Chat is designed to work with existing email infrastructure. You can continue using your current email service while ZTmail App provides an integrated chat interface and automates supported S/MIME operations.
Yes. ZTmail App lets you switch between Chat Mode and Mail Mode. The interface changes to suit the task, while the underlying communication continues to use email infrastructure. You can move from a chat‑style conversation to the full email experience when you need more space, formatting, attachments, or other email functions.
Yes. ZTmail Chat can be used with supported personal and business email accounts. Individuals can use it for private communication, while organizations can use ZTmail's cryptographic capabilities and available gateway components to support organizational requirements.
A ZTmail Chat conversation remains an email underneath and is stored in the user's own mailbox as email. When S/MIME encryption is applied, the message content is encrypted by the relevant cryptographic keys. This approach does not require a separate, centralized messaging database to serve as the primary store for chat conversations.
ZTmail Chat is built on email infrastructure rather than requiring a separate centralized messaging platform for its core communication model. The email service continues to provide mailbox and message delivery functions, while ZTmail App provides the chat interface and automates supported cryptographic operations.
Yes. The Reply by Email function lets you respond to a chat message as a regular email. This is useful when you want to move from a short chat‑style exchange to a more conventional email response.
Yes. The Forward by Email function lets you forward a conversation by email to another recipient. Before forwarding, consider whether the recipient is authorized to receive the information and whether the message needs to be encrypted for that recipient.
Yes. Open in Composer lets you continue working with the message in the full email composer. This is useful when you need more space, richer formatting, attachments, or a more formal email structure.
ZTmail App uses IMAP IDLE to receive near‑real‑time message arrival notifications. Actual notification timing depends on the email provider, network connection, account configuration, and other service conditions, chat communication between users on the same mail server should be pretty quick. Near‑real‑time notifications should not be interpreted as a guarantee of instantaneous delivery.
Yes. Your communication partner can continue using an existing S/MIME‑compatible email client. They do not need to install ZTmail App simply to participate in email‑based communication. It is recommended to use ZTmail App for both parties to get better chat experience.
The available experience depends on the capabilities of their email client. S/MIME‑encrypted messages require appropriate certificate and private‑key support.
ZTmail Chat uses S/MIME cryptography. When a message is encrypted, the sender uses the recipient's public‑key certificate to protect the message so that it can be decrypted by the intended recipient using the corresponding private key. ZTmail App automates supported certificate management and cryptographic operations to make this process easier to use.
Yes. When S/MIME encryption is applied correctly, the message content is encrypted for the intended recipient or recipients and requires the corresponding private key for decryption. The encryption protection is based on the S/MIME keys, rather than on the chat interface itself.
The exact protection depends on the message, the recipients' certificates, the client configuration, and how the message is handled. Email routing and mailbox services still perform their normal infrastructure functions.
ZTmail App is designed to automate S/MIME cryptographic operations. Successful encryption depends on the availability of the required recipient certificate and the applicable configuration and policy. If a recipient's public‑key certificate is not available, the required encryption may not be possible until the certificate is obtained.
Users need to enable the encryption when chat, and should not assume that a message has been encrypted merely because it appears in Chat Mode; they should follow the security status displayed by the application.
S/MIME encryption requires the recipient's public‑key certificate. One common way to obtain it is for the recipient to send a digitally signed email. The sender can then obtain the public certificate from that signed message and use it for subsequent encrypted communication, subject to certificate validation and application support.
Encryption protects message confidentiality by restricting access to the message content to parties with the appropriate private key. A digital signature provides cryptographic evidence associated with the signing certificate. It can help the recipient verify the signer and detect changes to signed content. These functions serve different purposes. Encryption alone does not establish the sender's identity, and a digital signature alone does not conceal the message content.
ZTmail Chat uses S/MIME digital signatures and certificate validation to help recipients assess the sender's cryptographic identity. ZTmail App displays the validated identity level in its interface, making certificate information easier to understand than relying only on a displayed email address.
The strength of the identity indication depends on the certificate type, trust domain, and successful validation.
An unsigned message does not provide the same digital‑signature evidence as a successfully signed message. ZTmail App distinguishes messages with different signature and identity‑validation states so that users can understand what has, and has not, been cryptographically established.
An unsigned message is not necessarily malicious, but its sender identity and content integrity have not been established through a digital signature. The Chat UI will display a warning like: Identity Not Validated, Messages NOT Encrypted, Be Extra Careful.
A valid digital signature can help detect changes to the signed content covered by the signature. If the signed content has been altered, signature validation should fail and have warning. A valid signature does not, by itself, prove that the message is truthful, that the sender's intentions are legitimate, or that a requested transaction is authorized.
S/MIME protects the message content covered by the encryption operation. Some message‑routing information and other email metadata may remain visible to the email infrastructure. Users should not assume that every email header or all delivery metadata is concealed.
Cryptographic signatures and certificate validation can help users distinguish messages with validated identities from those without the expected cryptographic evidence. ZTmail App makes validated identity information visible in the interface. These capabilities can help users recognize suspicious messages, but they do not eliminate every form of phishing, social engineering, account compromise, or misuse of a legitimately issued certificate.
ZTmail Chat uses four identity‑validation levels:
These levels describe the type of identity validation associated with the certificate. They are not simply different encryption strengths.
Mailbox validation establishes control of the relevant email address or mailbox according to the applicable validation process. Individual identity validation provides additional evidence about the person's identity.
A validated mailbox does not, by itself, establish the real‑world identity of the person using it.
Organization Validated means that the organization named in the certificate has been validated according to the applicable process. It provides recipients with organization‑level identity information rather than only mailbox‑level information.
Sponsor Validated means that the individual's identity and relationship with the named organization have been validated. In ZTmail Chat identity display model, this corresponds to T4 and can show both the person's name and organization name.
ZTmail App can display the identity level associated with a supported, successfully validated S/MIME certificate. Depending on the certificate, the interface can indicate mailbox validation, individual validation, organization validation, or validation of both an individual and an organization.
The displayed trust level depends on the certificate's identity information and successful validation. A certificate's identity level should not be inferred solely from the sender's display name or email address.
No. Identity validation and encryption are different concepts. T1–T4 indicate different levels or types of identity validation; they do not directly indicate the strength of the encryption algorithm or key.
The applicable certificate, cryptographic algorithm, key parameters, and validation results determine the relevant security properties.
Yes. Users can choose a higher identity‑validation level when their needs change and when they meet the applicable validation requirements. For example, an individual may choose T2, an organization may choose T3, and an employee whose identity and organizational relationship are validated may choose T4.
A mailbox can use multiple identity certificates where supported; upgrading identity validation does not necessarily mean that the existing identity certificate must be removed.
ZTmail Trust is the trust domain used within the ZTmail ecosystem. It supports automated certificate deployment and trusted identity display in compatible ZTmail applications.
Global Trust refers to certificates issued under recognized public Certificate Authority (CA) trust chains, enabling broader trust and interoperability in compatible email clients and other applications.
The two domains serve different purposes and can be combined in an appropriate deployment strategy.
ZTmail Chat’s service options use three trust models:
The specific certificate types available depend on the selected service and product offering.
Hybrid Trust combines Global Trust and ZTmail Trust to balance external interoperability, trusted identity display, and certificate cost. For example, a globally trusted Mailbox Validated (MV) certificate can provide broad compatibility, while a ZTmail‑trusted IV, OV, or SV certificate can provide higher‑level identity information within the ZTmail ecosystem. The two certificates serve different roles; a ZTmail‑trusted certificate does not automatically become publicly trusted simply because it is used alongside a Global Trust certificate.
Not every communication scenario requires the same trust model. Global Trust and Hybrid Trust can be useful when broad recognition by compatible external email clients is important. ZTmail Trust can support automated identity and certificate management within the ZTmail ecosystem. The appropriate choice depends on interoperability requirements, identity‑validation needs, application support, and cost.
The service offers supports different identity and trust requirements, including:
The available trust options may include ZTmail Trust, Global Trust, and Hybrid Trust, depending on the product model selected.
Yes, where the selected service supports them. A mailbox can use certificates associated with different identity levels, such as MV, IV, OV, or SV, to meet different communication needs.
The certificates represent different validated identities or relationships. The appropriate certificate must be available and selected for the relevant signing or communication operation.
Yes. ZTmail supports RSA and SM2 certificate options in applicable services. Users can choose the algorithm or algorithms that meet their interoperability and deployment requirements.
Compatibility depends on the certificates, email clients, cryptographic implementation, and applicable standards supported by the communicating systems.
Not necessarily for every aspect of communication, but the relevant cryptographic operations must be supported by the communicating applications and certificates. For S/MIME encryption, the sender must be able to use the recipient's public‑key certificate and the algorithms supported by that certificate and implementation. The recipient must be able to process the resulting message and use the corresponding private key.
For reliable interoperability, users should confirm that both sides support the certificate and algorithm choices being used.
ZTmail Chat automates supported certificate lifecycle operations, including enrollment, configuration, and renewal workflows. The exact process depends on the certificate type, issuing CA, trust domain, and selected service. Where renewal is supported, the application or service can manage the renewal process before expiration according to the applicable configuration.
ZTmail App supports importing compatible existing S/MIME certificates and private keys. This can help users continue using certificates they already own and retain access to messages previously encrypted with those certificates, provided the relevant private keys are available and compatible.
ZTmail App supports encrypted backup of certificates and private keys to the user's own mailbox, according to the application's backup and recovery workflow. Users should keep the required recovery key safe and avoid deleting backup data maintained by the application.
The availability of a backup does not eliminate the need to protect the recovery key and the mailbox account itself.
Where the supported backup and recovery workflow is available, users can restore backed‑up certificates and private keys on another device by following the application's recovery process and providing the required recovery information.
Successful restoration depends on the backup being available, the recovery key being correct, and the certificate material being compatible with the new environment.
ZTmail Chat is designed to support user‑controlled cryptographic keys. In the App workflow, private keys are managed in the applicable local environment, and encrypted backup may be stored in the user's own mailbox.
Enterprise Gateway deployments have a different key‑management architecture. Organizations should refer to the relevant deployment documentation for the handling and protection of organizational CA keys and employee keys.
ZTmail Chat follows the principle “AI, Your Key. Your Choice.” Where AI features are available, users can use their preferred supported AI provider and their own API key rather than being locked into a single AI provider.
Available providers and functions depend on the application version and configuration.
No. AI and cryptography serve different purposes.
S/MIME provides cryptographic encryption and digital signatures, while certificate validation helps establish identity‑related trust. AI can support productivity and intelligent assistance, but it does not replace the cryptographic functions required for confidentiality, signature validation, or certificate‑based identity.
No. AI can help analyze content or identify potential warning signs, but it cannot guarantee that a message is safe, truthful, or sent by a legitimate person. Cryptographic validation and AI‑assisted analysis address different aspects of trust and should not be treated as substitutes for one another.
Yes. Organizations can use ZTmail's available enterprise components to support certificate‑based encrypted communication and centralized management, depending on the deployment model and requirements.
The appropriate architecture depends on existing email infrastructure, security policies, certificate requirements, and whether the organization needs centralized gateway or key‑management capabilities.
The ZTmail Enterprise Instant Messaging Encryption Gateway is designed to support encrypted instant messaging for medium‑sized and large organizations, including internal and external communication scenarios.
Built on the organization's email infrastructure, it provides a gateway‑based approach to encrypted chat and can support in‑house S/MIME certificate issuance, automated certificate management, and key management as part of the relevant deployment.
No. The gateway is designed to work with existing email infrastructure rather than requiring the organization to replace its email servers or force every employee to adopt a new email client.
The exact integration and routing design depends on the organization's existing systems and deployment requirements.
The Enterprise Instant Messaging Encryption Gateway provides the gateway functions needed to support encrypted messaging and related cryptographic operations in an organizational environment.
The Enterprise Key Management System (EKMS) focuses on centralized management of certificates and cryptographic keys. EKMS can complement the gateway where an organization requires centralized key management. They address related but different functions and should not be treated as interchangeable components.
Yes. ZTmail Chat offers enterprise components intended to support centralized certificate and key management, depending on the selected architecture. Organizations should evaluate where certificates are issued, where keys are generated and stored, how access is controlled, and how the deployment integrates with existing security policies.
ZTmail Gateway is designed to complement existing infrastructure. Its role is to automate supported cryptographic operations and certificate lifecycle management, while existing systems continue to perform their designated functions.
The actual integration architecture should be designed according to the organization's email routing, security inspection, compliance, and key‑management requirements.
Choose according to the identity level and trust requirements of your communications:
Then consider whether you need ZTmail Trust, Global Trust, or Hybrid Trust. The best option depends on the identity information recipients need to verify, the clients and organizations you communicate with, and the trust requirements of your environment.
ZTmail App is intended for individuals and small businesses that want an integrated email and chat experience with automated S/MIME operations. An enterprise gateway is intended for organizations that need to integrate cryptographic application automation into existing infrastructure and may require centralized certificate management, key management, policy control, or integration with existing security systems. The choice is based on deployment and management requirements, not simply on whether the user wants to send encrypted messages.