ZTmail Sign is a document cryptographic application automation service built around the email workflow. It integrates document digital signing, signer identity validation, document encryption, signature validation, trusted timestamping, and certificate lifecycle management into ZTmail App.
Users can sign documents received as email attachments or select local documents through the App's Document menu. Organizations that need to process documents in bulk can use the ZTmail Document Cryptographic Application Automation Gateway.
Traditional online signing platforms typically require users to upload a document to a separate service and manage the signing process in that platform. ZTmail Sign integrates signing into the existing email workflow and supports signing local documents.
Users can sign documents with their own document signing certificates. For cloud signing, ZTmail Sign sends only the document's cryptographic hash to the cloud e‑signing service, while the original document remains on the user's device. This reduces the need to transfer confidential documents to an external signing platform.
No. ZTmail Sign supports both PDF attachments in email and local documents.
Users can right‑click a PDF attachment and select the signing operation, keeping the document within the email conversation. They can also use the Document menu in ZTmail App to sign or encrypt supported local PDF files independently of an email attachment.
No. You can discuss a contract, exchange revised PDF versions, confirm the final version, sign it, optionally encrypt it, and send it back through the same email conversation.
The completed signed document can remain as an encrypted email attachment in your own mailbox, rather than being managed only within a separate signing platform.
ZTmail Sign is designed for individuals, professionals, small and midsize businesses, and organizations that need to sign, encrypt, and verify documents.
Individuals can sign personal documents. Professionals can sign agreements and business documents using their own validated identity. Organizations can present organization or employee identity, protect confidential documents, and automate high‑volume document signing through the Gateway.
No. ZTmail App automates supported certificate application, configuration, backup, renewal, and cryptographic operations. Users select the service and identity level that fit their needs, and the App manages the corresponding certificate workflow.
Some initial choices, such as applying for a document certificate and safeguarding the recovery key, still require user action.
For a PDF received by email, open the message, right‑click the attachment, and choose the signing operation. ZTmail App uses the configured document signing certificate to create the digital signature. For a local PDF, use the Document menu in ZTmail App to access the supported document signing functions. The exact actions available depend on the document type and application version.
Yes. Local document signing uses the user's configured document signing certificate, which is associated with the user's validated identity.
Depending on the certificate selected, the signed document can carry mailbox, individual, organization, or employee identity information. This allows recipients to verify the digital signature and examine the certificate‑backed identity instead of relying solely on a typed name or a visual signature mark.
An electronic signature (e‑signature) is a broad concept covering electronic methods of indicating a person's agreement or intent to sign a document. A digital signature is a specific type of electronic signature that uses cryptographic technology to protect document integrity and support verification of the signer's identity.
(1) Electronic Signature (Cloud e‑Signing)
Cloud e‑Signing allows users to sign contracts and other documents through a cloud signing service without necessarily obtaining their own identity certificates or completing a separate identity‑validation process.
ZTmail Sign offers a distinctive approach to cloud e‑signing: the original document stays on the user's device. Only the document's cryptographic hash is sent to the cloud signing service for signing. The signed data is then returned to ZTmail App to complete the signing process locally. This approach helps protect document privacy and business confidentiality by avoiding the upload of the original document.
(2) Digital Signature (Certificate‑Based Signing)
Certificate‑based digital signing uses a digital certificate and its associated private key to create a cryptographic signature. The signature enables recipients to verify document integrity and validate the identity associated with the signing certificate, subject to certificate trust and signature validation.
(3) How Does ZTmail Sign Support Both?
ZTmail Sign provides both Cloud e‑Signing and certificate‑based digital signing. Cloud e‑Signing offers a convenient signing process without requiring every signer to obtain their own identity certificate. Certificate‑based digital signing enables users to sign documents with their own identity certificates, supporting cryptographic identity verification and document‑integrity protection.
The appropriate method depends on the document, the signers' identity requirements, and the level of assurance needed. The legal effect of a signature depends on applicable law and the specific signing process.
ZTmail Sign supports two PDF digital‑signing methods: Standard Signing (Approval Signature) and Certifying Signing (Author Signature). Both use digital certificates, but they serve different purposes.
(1) Standard Signing (Approval Signature)
(2) Certifying Signing (Author Signature)
(3) Which Should You Choose?
Choose Standard Signing when people need to sign or approve a document. Choose Certifying Signing when the document's originator needs to certify its contents and define permitted changes afterward.
Yes, if the certificate is appropriate for the intended purpose. However, if recipients need to establish the identity of an organization or verify that an individual is associated with an organization, an Organization Validated (OV/T3) or Sponsor Validated (SV/T4) identity may be more suitable.
The appropriate identity level depends on the document, the signer's role, and the recipient's requirements.
Yes. ZTmail Sign supports two organizational identity types for document signing:
The appropriate certificate depends on whether the signature represents the organization itself or an employee acting in their organizational role. The legal authority and effect of a signature depend on the applicable law and the signer's authorization.
ZTmail supports multiple identity levels where the relevant certificates and service options are available. The same mailbox can hold MV, IV, OV, and SV identities simultaneously, allowing users to select an identity appropriate for different signing needs. The identity displayed in a particular signature depends on the certificate used for that signing operation.
Yes, depending on the certificate trust model and the recipient's PDF reader. ZTmail‑signed PDFs can be opened in Adobe Reader and other compatible applications for signature validation.
However, the way a signature and signer identity are displayed depends on the certificate chain, trust configuration, signature format, and application support. A signature trusted within the ZTmail ecosystem is not automatically trusted by every external PDF reader.
Not by itself. A valid digital signature can provide cryptographic evidence associated with the signing certificate and help establish whether the signed content has changed. Whether a document is legally binding also depends on applicable law, the parties' intent, authority to sign, required formalities, and the circumstances of the transaction.
ZTmail Sign provides cryptographic signing and identity capabilities; users must ensure that their signing process meets the legal and contractual requirements relevant to their documents.
ZTmail Sign Cloud Signing is a cloud‑assisted document signing service that does not require the original document to be uploaded to the cloud signing service.
ZTmail App calculates the document's cryptographic hash locally and only posts the hash to the cloud signing service. The cloud service signs the hash using its platform signing certificate and returns the signed data. ZTmail App then completes the document signing process locally.
No. The original document stays on your device throughout the cloud‑signing process. ZTmail App sends only the document's cryptographic hash to the cloud signing service, rather than uploading the original document.
This architecture is designed to reduce exposure of confidential contracts, personal information, commercial secrets, and intellectual property during signing.
For the cloud‑signing operation described above, ZTmail App sends the document's cryptographic hash to the cloud signing service. The service uses that hash in its signing operation and returns the signed data. The cloud service does not need to receive the original document to perform this part of the process.
The document hash is a cryptographic digest, not a copy of the original document. It is designed to provide a compact representation that can be used to verify the relationship between the document and the signature. A hash is not intended to provide the document's contents.
Many online e‑signing platforms require users to upload the original document so the platform can manage the signing transaction. ZTmail Sign separates the local document from the cloud signing operation: the App retains the document and sends only its hash to the cloud service.
This approach is particularly useful when documents contain confidential personal and business information and users want cloud‑assisted signing without transferring the original document to the signing platform.
Yes. The ZTmail Sign Cloud e‑Signing Service follows cloud‑signing standards developed by the Cloud Signature Consortium (CSC).
This describes alignment with the CSC's cloud‑signing standards; it should not be interpreted as a claim that the service has received a separate CSC certification unless that certification is explicitly documented.
Cloud signing uses the cloud signing platform's signing certificate for the cloud‑signing operation. The displayed identity depends on the selected product model and the signing workflow.
For example, certain General Edition and Hybrid Trust options use an Adobe‑trusted platform signing certificate so that Adobe Reader can display the platform's signing information or display the signature valid based on the signing method. This is different from local signing with the user's own identity certificate, which can display the user's validated identity.
No. ZTmail Sign supports both local signing with the user's configured document signing certificate and cloud‑assisted signing. Local signing is suitable when users want the signature to be tied directly to their own certificate‑backed identity. Cloud signing is useful when the selected service provides platform‑level signing and broader compatibility with supported external PDF readers. The appropriate method depends on the intended signer identity, recipient compatibility, trust requirements, and selected product model.
Yes. ZTmail Sign supports both digital signing and document encryption. Users can digitally sign a PDF with a signing certificate and encrypt it for authorized recipients using document encryption certificates.
Signing and encryption serve different purposes: signing helps recipients verify the signature and detect changes to signed content, while encryption protects the document's confidentiality.
ZTmail Sign uses the public‑key certificates of the intended recipients to encrypt the document. Each authorized recipient can use the corresponding private key to decrypt it. A document can be encrypted for one or multiple authorized recipients, depending on the supported workflow and available certificates.
No shared document password is required when the document is encrypted using recipient public‑key certificates. Each authorized recipient uses their corresponding private key to decrypt the document smoothly. A person who does not have the required private key cannot decrypt the protected content through the normal cryptographic process.
Yes. ZTmail Sign supports encrypting a document for one or multiple authorized recipients. Each recipient needs the appropriate certificate and corresponding private key to access the encrypted document. Before sending a confidential document, make sure the intended recipients are correctly identified and that the required certificates are available.
ZTmail App supports automatic decryption of compatible encrypted documents when the corresponding private key is available and configured. This integrates decryption into the normal document workflow rather than requiring users to manage cryptographic steps manually. If the required private key is unavailable, the document cannot be decrypted by that user. Restoring the relevant certificate and private key may be necessary.
Yes. You can sign a document to provide cryptographic evidence associated with the signer and then encrypt it for the intended recipients. This combines signer verification with confidentiality protection. The operations address different security needs: encryption does not replace a digital signature, and signing does not conceal document contents.
ZTmail Sign uses four trust identity‑validation levels for displaying signer identity:
These levels describe identity validation, not the strength of the encryption algorithm or the legal authority to sign every document.
The identity information depends on the selected certificate and the ZTmail App displaying the signature.
ZTmail App can display the corresponding Trusted Identity indicator and certificate‑backed identity information after the signature and relevant trust information are validated.
T3 focuses on the validated organization identity. T4 links an individual's validated identity with the relevant organization or sponsor relationship.
If a document needs to show the organization as the signer identity, T3 may be appropriate. If it needs to show both the individual and their organizational relationship, T4 may be more suitable.
No. Identity validation and document encryption are separate functions. T1–T4 describe the identity information associated with the signing certificate. Encryption depends on the document encryption certificates, private keys, algorithms, and applicable configuration. Choose the identity level according to how the signer should be identified, and choose the encryption configuration according to who should be able to read the document.
The display depends on the selected product model and trust domain. With compatible globally trusted certificates, Adobe Reader may display the signer's personal or organizational identity. With ZTmail‑trusted certificates, Adobe Reader may not recognize the certificate chain as trusted by default.
Certain Hybrid Trust products combine a ZTmail‑trusted identity certificate with cloud‑signing operations under Global Trust, allowing Adobe Reader to display the platform signing information or signature valid while ZTmail App displays the user's validated identity. The exact display depends on the product model and signature type.
D1, D2, and D3 identify document‑signing product models that use different trust architectures:
The actual validation and display results depend on the certificate chain, trust configuration, product model, and reader application.
ZTmail Trust supports certificate‑backed identity trusted within the ZTmail ecosystem.
Global Trust uses certificates issued under recognized public CA trust chains for broader interoperability with compatible external applications, including supported Adobe Reader workflows.
Hybrid Trust combines ZTmail‑trusted identity with a Global Trust cloud‑signing component in supported product models. This can provide visible user identity in ZTmail App and trusted platform‑signing information or signature valid in Adobe Reader.
(1) How Do They Differ in Practice?
These trust models have different purposes. A ZTmail‑trusted certificate does not become globally trusted simply because it is used alongside a globally trusted cloud‑signing certificate.
The three trust models differ in how document signatures are validated and how signer identity is displayed in Adobe Reader and ZTmail App.
(2) Why Choose Hybrid Trust?
Hybrid Trust combines global signature validation with trusted identity display in ZTmail App. For Standard Signing, it can provide the same Adobe Reader signature‑validity status as Global Trust at a lower cost. For Certifying Signing, the displayed “Certified by ZoTrus Document e‑Signing Cloud Service” identity differs because the signing certificate belongs to the cloud‑signing platform rather than the individual user.
ZTmail Sign provides three main service editions:
The Organization Edition can be selected for organization identity or organization employee identity, depending on whether the document needs to present the organization alone or the employee and organization relationship.
Each edition offers applicable product models with different trust architectures and compatibility characteristics.
Yes. The General Edition includes free document certificate automation for mailbox identity (MV/T1). The free MV‑D1 product is intended for use within the ZTmail ecosystem to get full document signing and encryption experience.
Users who need globally trusted cloud signing can choose the paid MV‑D2 option, which includes 10 cloud‑signing operations. The General Edition's free document certificate and the optional cloud‑signing service are different offerings.
The service page lists the following starting prices:
The actual price depends on the selected D1, D2, or D3 product model. For example, Global Trust and Hybrid Trust have different prices from ZTmail Trust. Please consult the current service and pricing page for the applicable product price and term.
The service offers terms of 1–5 years, while an individual document certificate can be valid for no more than two years. For service terms longer than two years, the App automatically initiates renewal before the certificate expires, without an additional renewal charge. The certificate's validity period and the overall service term are not the same thing.
Yes, where the selected service and validation requirements permit it. The same mailbox can hold multiple identity certificates, such as MV, IV, OV, and SV, simultaneously.
For example, a user who initially has mailbox validation can later obtain an individual or organizational identity certificate. Additional identity levels require the corresponding service and any required identity validation.
Yes. ZTmail Sign supports RSA and SM2 document certificates in applicable services. Users can choose RSA, SM2, or both according to their requirements and the compatibility of the applications and recipients involved.
The selected algorithm affects cryptographic compatibility; it does not determine the identity‑validation level.
Users who initially selected only RSA can apply for an SM2 certificate later at no additional charge, and vice versa, under the applicable service offering.
The available certificate options depend on the selected product and service terms.
Yes. After installing ZTmail App, adding an email account, and selecting Settings → Certificates → Request Certificate, the App automates the supported certificate request, mailbox validation, certificate retrieval, and configuration process.
Users do not need to manually install and configure the resulting document certificate including signing certificate and encryption certificate for use within the supported App workflow.
Yes. The App initiates renewal before a supported document certificate expires. The renewal process is designed to reduce manual certificate management and help maintain signing and encryption functionality.
Automatic renewal depends on the applicable service, certificate issuer, and successful completion of the required process.
For local document signing and encryption, the user's private keys are managed locally by ZTmail App. The local private keys do not leave the device during the certificate request and local cryptographic workflow. The App automatically create an encrypted backup of certificate and private‑key material in the user's own mailbox so it can be restored on another device. Cloud signing is a separate workflow that uses a platform signing certificate in the cloud service.
ZTmail App supports encrypted certificate and private‑key backup to the user's own mailbox. To restore the backed‑up material to another device, follow the App's recovery process and provide the required recovery key.
Keep the recovery key safe and do not delete the backup data maintained by the App. If the relevant private key and backup cannot be recovered, previously encrypted documents may no longer be accessible.
ZTmail Sign does not store users' identity‑validation supporting documents. Identity validation is performed by the applicable validation provider or CA according to the selected product model.
The provider and validation process differ between product models, so users should consult the relevant service information and privacy terms for details.
A trusted timestamp provides verifiable time information associated with a digital signature. It helps establish that the signed data existed at or before the time indicated by the timestamp, subject to successful validation of the timestamp and its trust chain.
A timestamp adds time‑related evidence to the signature; it does not independently prove that the document's contents are true or that the signer had authority to approve the transaction.
A trusted timestamp can help recipients evaluate when a signature existed, which is important when a document needs to be validated long after it was signed and need to prove the signing event time.
Certificate validity and revocation status can change over time. Timestamping and supporting validation information help preserve evidence for later verification, subject to the relevant certificate, timestamp, and validation requirements.
ZTmail Sign integrates trusted timestamping into the signing workflow and supports long‑term validation (LTV) through timestamp information and certificate revocation list services.
The ability to validate a document in the future depends on the signature format, certificate and timestamp trust chains, the availability of relevant validation information, and the reader's verification capabilities.
It supports for RSA and SM2 timestamping and references the international RFC 3161 standard and China's GM/T 0033‑2014 cryptographic standard. The supported timestamping service depends on the selected configuration. Users can also configure another timestamping service as the default where supported.
Yes. Users can set another timestamping service as the default. This allows the timestamping configuration to be aligned with their deployment or organizational requirements, subject to application support and compatibility.
Yes. Medium‑sized and large organizations can deploy the ZTmail Document Cryptographic Application Automation Gateway to automate high‑volume document signing and related cryptographic operations.
Instead of manually opening and signing every PDF, a business system can submit documents to the Gateway through an integration interface. The Gateway applies the configured signing policy and returns the signed or signed‑and‑encrypted document to the business system.
It is the enterprise deployment option for organizations that need to automate document signing, encryption, decryption, timestamping, signature validation, and certificate lifecycle management at scale.
The Gateway can integrate with business systems that generate PDFs and apply organizational signing certificates and configured policies. It is intended to complement existing business systems rather than require employees to process every document manually.
Yes. The Gateway architecture supports policy‑driven document signing. Organizations can define different requirements for document types, signing certificates, identity levels, recipients, and encryption rules according to their business and security needs.
The exact policies and integration details depend on the Gateway deployment and the organization's systems.
Yes. The Gateway can automate digital signing, encryption, timestamping, and related cryptographic operations. The timestamping workflow can use the configured timestamping service, with local deployment of timestamping system options available where required. This enables organizations to apply consistent cryptographic policies across document workflows rather than relying on manual processing for each file.
No. The Gateway is designed to integrate with existing business systems. A system can generate a document, send it to the Gateway through an integration interface, and receive the signed or encrypted result for delivery or archival.
The specific integration method depends on the organization's system architecture and the interfaces supported by the Gateway.
Choose according to the identity you want recipients to see:
Then choose D1, D2, or D3 based on your trust and compatibility requirements.
If Adobe Reader interoperability is important, consider a Global Trust product model (D2) or a Hybrid Trust model (D3), as applicable to your identity level and requirements. D1 uses ZTmail Trust and is intended for use within the ZTmail ecosystem; Adobe Reader may report that the signature is invalid or that the certificate chain is not trusted. The exact result depends on the certificate and reader configuration. Review the current service page to compare how each model appears in ZTmail App and Adobe Reader before purchasing.