Choose an email client and workflow that actually supports the key format. Plan a secure private-key backup and recovery method, and understand that losing the private key or its passphrase can make encrypted historical messages unreadable.

1. Open Encryption and review the existing public and private key lists before creating another identity.
2. For a new identity, enter the requested name, email, passphrase, expiry and supported key size, then generate the key. Use a unique passphrase kept in a secure password manager.
3. Export or copy the public key for distribution to intended correspondents. Verify its fingerprint through a trusted channel.
4. Configure the supported mail client with the appropriate key material through its documented secure process. Never publish the private key in DNS, a website folder or an ordinary support message.
5. Exchange a non-sensitive encrypted test with a trusted correspondent and confirm both encryption and decryption work before relying on the arrangement.

Only the intended private-key holder should be able to decrypt the test. Keep a verified protected backup and record the key’s identity and expiry so renewal is planned.

If a recipient cannot decrypt, confirm the message used their current public key. If the wrong key was imported, correct the client’s identity selection before sending sensitive material. Deleting a server key does not erase copies already exported to devices.

No. TLS secures a network connection and DKIM authenticates a message signature. End-to-end encryption protects message contents using the correspondents’ keys and requires a compatible workflow on both sides.

• Publishing cPanel DKIM when DNS is hosted elsewhere
• Configuring an application to send through authenticated SMTP
• Testing a cPanel backup before a major website change
• Changing an email mailbox password in cPanel

• cPanel: Encryption