The easiest way to encrypt an email is to use an email encryption gateway that handles cryptographic operations centrally, so neither senders nor recipients need to configure anything in their email clients. For most organizations, the barrier is not the technology itself but the setup and key management; a gateway removes that friction. The sections below cover the main methods, the key standards, and how to get started.
There are two primary methods for encrypting email: message-level encryption, which protects the content of the message itself, and transport-level encryption, which protects the connection over which the message travels. Most organizations need both, but they solve different problems and should not be confused with each other.
Transport Layer Security (TLS) is the most widely deployed form of email protection. When two mail servers communicate over a TLS connection, the data in transit is protected from interception. However, TLS does not protect the message once it arrives at its destination. The content sits unencrypted in the mailbox and on the mail server, readable to anyone with access to those systems.
Message-level encryption, using standards such as S/MIME or OpenPGP, protects the message content itself using cryptographic keys. The message remains encrypted in transit, on the server, and in the mailbox until the intended recipient decrypts it with their private key. This is the approach that provides genuine confidentiality for stored messages, not just for data in motion.
A third method, secure message portals, works differently: the sender's system encrypts the message and stores it, then sends the recipient a notification with a link. The recipient logs in to read the message. This avoids the need for the recipient to have a key or certificate but adds friction to the reading experience.
S/MIME and PGP (also called OpenPGP) are both standards for message-level email encryption, but they differ in how trust is established and how keys are distributed. S/MIME relies on certificates issued by a trusted certificate authority, while PGP uses a decentralized web-of-trust model where users sign each other's keys.
S/MIME certificates are issued by certificate authorities, much like the SSL certificates used for websites. This makes trust verification straightforward in enterprise environments because the chain of trust is managed centrally. S/MIME is natively supported by many corporate email clients, including Microsoft Outlook and Apple Mail, which makes it a common choice for business use. The main drawback is cost and administration: each user typically needs an individual certificate, and those certificates must be renewed.
OpenPGP does not require a certificate authority. Users generate their own key pairs and share their public keys directly or through public key servers. This makes PGP more flexible and accessible for individuals and open-source communities, but it places more responsibility on users to verify that the keys they use actually belong to the right people. In enterprise deployments, a central key management system can address this by collecting and distributing keys on behalf of users.
In practice, organizations often need to support both standards because different communication partners use different infrastructure. A well-configured email encryption gateway can handle both S/MIME and OpenPGP, applying whichever standard is appropriate for each recipient based on available keys.
Several major email clients support S/MIME natively, including Microsoft Outlook, Apple Mail, and the built-in mail apps on iOS and macOS. OpenPGP support in native clients is less common and usually requires a plugin or extension, such as GPG Suite for Apple Mail, though Thunderbird has built-in OpenPGP support.
The practical limitation of client-side encryption is key management. Each user must obtain, install, and maintain their own certificate or key pair, and they must also have access to the public keys of everyone they want to write to. For a small team of technically confident users, this is manageable. For a larger organization with many external contacts, it quickly becomes a significant administrative burden.
Web-based email clients such as Gmail and Outlook on the web have limited native encryption support. Google Workspace offers S/MIME for enterprise tiers, but configuration still requires administrative setup and certificate provisioning. For organizations that rely heavily on web clients, a gateway-based approach that handles encryption before messages reach the client is often more practical.
Setting up email encryption for the first time involves three steps: choosing a standard (S/MIME or PGP), obtaining or generating the necessary keys or certificates, and configuring your email client or gateway to apply encryption automatically. The right starting point depends on whether you are setting up encryption for one user or for an entire organization.
For an individual user, the process typically looks like this:
For an organization, the setup is more involved because every user needs keys, every outgoing message needs to be handled consistently, and incoming encrypted messages need to be decryptable. This is where an email encryption gateway simplifies the process considerably. Rather than configuring each user's client individually, the gateway handles encryption and decryption centrally, using a shared key management system that administrators control.
One important detail often overlooked during setup: encrypting outgoing SMTP traffic does not automatically encrypt the copy of the message saved in the sender's Sent folder. A complete setup needs to address both the message delivered to the recipient and the copy retained by the sender.
You cannot encrypt every email automatically because encryption requires a valid public key for each recipient. If you do not have a key for a particular recipient, the message cannot be encrypted for them, and sending an unencryptable message without any fallback policy can result in delivery failure or unprotected delivery, depending on how the system is configured.
This is the core challenge of email encryption at scale. Unlike transport encryption, which two mail servers negotiate automatically, message-level encryption depends on having the right key for each specific person. Key availability varies: some recipients will have S/MIME certificates, some will have PGP keys, some will have both, and many will have neither.
Organizations that want to enforce encryption for all outgoing messages need a clear policy for what happens when a recipient key is unavailable. Common approaches include:
A well-configured email encryption gateway lets administrators define these policies per domain or per address, so the organization can apply strict rules where they matter most while allowing more flexibility for lower-risk communications.
The easiest way to add email encryption to Atlassian tools like Jira or Confluence is to use a dedicated plugin that intercepts outgoing notifications and encrypts them before delivery. These tools generate a large volume of automated email notifications that can contain sensitive project details, issue descriptions, and comments, content that travels unprotected by default.
Standard email encryption approaches designed for human senders do not translate directly to automated notification systems. Jira and Confluence send notifications from a system account, not from individual users, so client-side encryption configured for individual employees does not apply. The solution is to encrypt at the point where the notification leaves the application, before it reaches the recipient's inbox.
S/Notify Email Encryption from savignano software solutions was built specifically for this purpose. It enables Jira, Confluence, and Bitbucket to send notifications encrypted with S/MIME or PGP, protecting message content beyond what transport encryption provides. This means the detailed information in a notification (issue titles, comments, code references) remains confidential on mail servers until the recipient decrypts it.
savignano software solutions offers two complementary products that make email encryption practical for organizations of different sizes and needs:
Both products are designed to reduce the administrative complexity that makes email encryption difficult to introduce at scale. Uptrust, in particular, is built around a gradual adoption model: organizations can start with selected domains or individual addresses, expand coverage over time, and keep existing email clients and mail servers in place. Administrators control encryption policies, key sources, and fallback behavior without requiring every user to manage certificates or keys themselves.
Savignano also offers consulting services in security architecture and systems integration, drawing on decades of cross-industry experience to help organizations connect platforms and build sustainable, secure communication infrastructure.
If you are evaluating email encryption for your organization or looking to extend protection to your Atlassian tools, get in touch with Savignano to discuss which approach fits your environment.
