🔑 Key Takeaways
- Encryption turns the body and attachments into ciphertext only the recipient key can decode.
- Outlook’s Encrypt button applies a Purview template that controls reply, forward, and copy rights.
- Gmail Confidential Mode adds portal access and expiry but leaves the body readable to Google.
- Native tools encrypt attachments alongside the body; files above 25 MB usually need a portal.
- Encryption never hides sender, recipient, subject, timestamp, or message size from the network.
Encrypting an email means one thing in a headline and something more specific inside the mail flow. The button in Outlook, the shield in Gmail, and the toggle in a dedicated service each perform a slightly different action on the message, the attachments, and the recipient experience.
This guide covers what encryption actually does to the body, attachments, subject line, and metadata across the major clients, and where dedicated tools like an encrypted email service fit when native options do not match the workflow.
The intent is a practical picture, not a cryptography lecture. Practice managers, compliance leads, and IT administrators can use it to align staff training with the real mechanics.
Encrypting an Email Transforms the Body Into Ciphertext
At the mechanical level, encryption replaces the readable message body with a string of characters that mean nothing without a key. The transformation uses a symmetric cipher such as AES-256 for the body itself and an asymmetric algorithm to protect the AES key for the recipient.
The transformation happens in one of three places. The sender client does it locally in S/MIME and PGP. The sender mail server does it in Microsoft Purview Message Encryption and Workspace routing. A dedicated encryption service does it inside its own infrastructure before the message leaves.
The recipient decrypts using their private key, their certificate, or a portal sign-in. The decrypted body appears inside the recipient inbox or portal session, and it stays there until the recipient closes the session or deletes the message.
Anything intercepted on the wire between sender and recipient sees only ciphertext. The NIST guidance on trustworthy email covers the specific cipher and key management standards regulated organizations should apply.
Attachments Encrypt Along With the Body in Native Tools
Attachments follow the encryption method chosen for the message body in most native implementations. Outlook with the Encrypt button, Workspace with client-side encryption, S/MIME, and PGP all cover attachments as part of the encrypted payload.
The recipient sees decrypted attachments alongside the decrypted body once they authenticate. The attachment file names and sizes stay hidden inside the encrypted payload in most cases, so a network observer cannot tell whether the message carried a PDF, a spreadsheet, or a set of image files.
Attachments over 25 MB run into message-size limits on most mail systems. That is where portal delivery through a dedicated service handles the case. The attachment uploads separately to a secure portal, and the recipient authenticates through a link.
File-level encryption with a PDF password or a ZIP password is a separate approach. It does not require email encryption at all. The tradeoff is key exchange, since the sender has to communicate the file password out of band. Email-level encryption avoids that step by binding decryption to the recipient identity.
The Subject Line Usually Stays in Cleartext
Most encryption implementations leave the subject line unencrypted for routing and inbox display. Office 365 Message Encryption, standard S/MIME, PGP, and portal-based systems all follow this pattern. The recipient sees the subject in their inbox alongside the sender name before opening anything.
That reality shapes staff training. Subject lines should not carry patient names, diagnosis codes, financial figures, or contract terms. Neutral phrasing like “Report available” or “Follow-up from clinic” keeps the sensitive content inside the encrypted body.
S/MIME 4.0 supports subject encryption when both sender and recipient clients implement the extension. Adoption is limited. For most cross-organization exchanges, the subject travels in cleartext regardless of what encryption method protects the body.
Practices that route encrypted mail through a subject-line trigger like the word “secure” should also strip that trigger from the outbound subject through a rewrite rule. That way the sensitivity marker does not leak into the recipient inbox preview.
A billing manager at a physical therapy clinic clicks the Encrypt button in Outlook 365 before sending a 3 MB PDF superbill to a patient at yahoo.com. Purview applies the Encrypt template, ciphers the body and PDF together with AES-256, and rewrites the message as a notification with a Read the message button. The subject line "Statement for March visits" travels in cleartext because Purview does not encrypt subjects. The patient signs in through the Microsoft portal with a one-time passcode delivered to her Yahoo inbox and downloads the superbill inside the portal session.
Metadata Continues to Travel in Cleartext
Encryption protects the body and attachments. It does not protect the routing metadata. The sender address, recipient addresses, message ID, timestamp, and message size travel in cleartext through the SMTP relay chain.
An observer with access to the relay path can build a communication pattern from that metadata even without reading a single body. Who sends to whom, when, and how often is often the payload of value in intelligence work.
For most healthcare, legal, and financial email, body encryption plus HIPAA or equivalent framework coverage is sufficient. The metadata gap matters most in high-stakes negotiations, executive communication, and situations where the pattern itself signals value to an adversary.
Organizations concerned about metadata typically move sensitive discussion to secure messaging platforms with additional protections. Email remains the correct tool for most patient and client communication.
Encryption in Outlook Applies a Rights Management Template
Clicking the Encrypt button in Outlook connected to Microsoft 365 applies a rights management template to the message. The default templates include Encrypt, which allows the recipient to reply, and Do Not Forward, which removes reply and forward permissions.
Administrators can create custom templates that add expiration dates, watermarks on displayed content, or restrictions on copying and printing. The template travels with the message and the client enforces the rules.
External recipients on any email platform get a portal link. They sign in with a Microsoft, Google, or Yahoo account, or they request a one-time passcode. The Microsoft Purview Message Encryption documentation covers the exact recipient experience.
Internal recipients on the same Microsoft 365 tenant often see inline decryption because their client already trusts the tenant identity. Cross-tenant Microsoft 365 recipients typically get the portal step, though federation configurations can smooth that path.
Encryption in Gmail Uses One of Three Distinct Mechanisms
Gmail encrypts email through three separate mechanisms, and each does something different. Confusion between them is the most common source of policy gaps in healthcare practices using Workspace.
The mechanisms are:
- TLS in transit, which every Gmail message uses when the receiving server supports it.
- Confidential Mode, a portal-based access control with expiration and passcode options.
- Client-side encryption on Workspace Enterprise Plus and Education Plus, which uses a customer-managed key from an external key service.
Only client-side encryption cryptographically protects the body against Google itself. TLS protects the wire. Confidential Mode restricts access but stores the body normally on Google infrastructure. S/MIME on eligible Workspace plans is a fourth option that administrators enable per domain.
Confidential Mode does not qualify as HIPAA-covered encryption on its own. The Google Workspace admin guide on hosted S/MIME covers the S/MIME configuration path for regulated tenants.
Purview, S/MIME, PGP, and most portal-based systems leave the subject line in cleartext. A subject like "MRI results for John Smith" leaks protected health information before the recipient opens anything. Train staff to write neutral subjects like "Report available" or "Follow-up from clinic" and keep sensitive detail inside the encrypted body. That single habit closes a gap that no encryption product on the market fixes for you.
Comparison of What Each Encryption Method Actually Protects
The table compares what the major encryption methods cover and what they leave exposed.
| Method | Body encrypted | Attachments encrypted | Subject encrypted | Metadata encrypted |
|---|---|---|---|---|
| Outlook Encrypt button (Purview) | Yes | Yes | No | No |
| Gmail Confidential Mode | No, portal only | No, portal only | No | No |
| Workspace client-side encryption | Yes | Yes | No | No |
| S/MIME | Yes | Yes | No, 4.0 optional | No |
| PGP | Yes | Yes | No | No |
| Dedicated encrypted email service | Yes | Yes, via portal for large files | No | No |
Practices routing all outbound mail through a secure email service get consistent body and attachment coverage without matching license tiers or maintaining transport rules across a tenant.
What Encryption Does Not Do
Understanding the limits of email encryption matters as much as understanding what it protects. Encryption does not stop a compromised sender account from generating new encrypted messages to attacker-controlled addresses.
Encryption does not stop a compromised recipient inbox from leaking decrypted content once the recipient reads the message. It does not prevent screenshot exfiltration by an authorized recipient who chooses to share content out of policy.
Encryption does not backfill weak account security. Multi-factor authentication on the sender account, endpoint protection on the recipient device, and access logging remain separate controls that pair with encryption to form a full posture.
The HIPAA Journal covers real breach cases where encryption alone did not prevent PHI exposure because the surrounding controls failed. Encryption is necessary but not sufficient on its own.
Related Setup Steps to Verify After Enabling Encryption
After turning on encryption in Outlook, Workspace, or a dedicated service, a short verification checklist confirms the setup covers the intended workflow. Skipping any of these items produces silent gaps that surface during compliance reviews or breach investigations.
Check each item:
- External recipients on Gmail, Outlook, Yahoo, and iCloud can decrypt without additional software installation.
- The signed business associate agreement covers the specific encryption feature in use, not just the base mailbox.
- Attachments in the size range staff actually send arrive intact and encrypted.
- The sent items folder shows a visible confirmation that the encryption action fired.
- Message trace or audit logs record the encryption event for compliance evidence.
Healthcare practices building patient communication programs around encrypted email benefit from aligning the encryption layer with the broader site and intake experience. A healthcare marketing agency can help ensure the patient-facing message matches the security posture staff execute on outbound mail.
For related reading on how encryption fits into the broader website security posture regulators expect, see the guide on security features for healthcare websites. Encryption is one control among many, and the surrounding controls determine whether it holds up under audit.
Frequently Asked Questions
Encrypting the message body replaces the readable text with ciphertext that requires a key or authentication to decode. In S/MIME, the recipient certificate provides the decryption key. In PGP, the recipient private key does the same. In Microsoft Purview and portal-based systems, the recipient authenticates through a browser sign-in and the server delivers decrypted content inside the portal. The original readable text never travels outside the sender and recipient trust boundary in plain form. Anyone who intercepts the message on the wire sees only ciphertext until a valid key or portal session decodes it.
In Outlook connected to a Microsoft 365 plan that includes Purview Message Encryption, clicking the Encrypt button on the Options ribbon applies an encryption template. The template determines recipient permissions and routing. External recipients get a portal link. Internal recipients often see inline decryption. Attachments protect along with the body. In personal Outlook.com accounts or on plans without the required license, the Encrypt button is absent and the client provides no native encryption. That is a common source of confusion when staff move between tenants.
Native encryption in Microsoft 365 and Workspace covers attachments as part of the encrypted message payload. When the recipient opens the message through the portal or with their key, they see the attachments decrypted alongside the body. S/MIME and PGP encrypt the entire MIME structure so attachments protect the same way. Large attachments above 25 MB usually cannot travel by message-level encryption and need portal delivery through a dedicated service. File-level encryption using a password on a PDF or ZIP is a separate approach and does not require email-level encryption.
In most implementations no. Office 365 Message Encryption, standard S/MIME, PGP, and most portal-based systems leave the subject line in cleartext for routing and inbox display. That is why compliance teams write encryption policies that require neutral subject lines with no PHI or sensitive detail. S/MIME 4.0 introduced an extension for subject encryption, but both sender and recipient clients must support it, and most cross-organization exchanges do not have that support. Assume the subject is visible and write it accordingly.
No. Encryption protects the message in transit and at rest until the recipient decrypts. Once the recipient reads the message inside their inbox, the content sits in plain form in whatever storage the recipient client uses. If an attacker has already compromised the recipient inbox through credential theft or session hijacking, they read the decrypted content along with the recipient. Encryption is one control in a broader posture that includes account security, multi-factor authentication, and endpoint protection on the recipient side.
Metadata stays in cleartext on most email encryption implementations. The sender address, recipient addresses, subject line, message ID, timestamp, and message size travel through routing systems in readable form. Encryption protects the body and attachments only. That is why sensitive negotiations, medical case discussions, and legal exchanges often use dedicated secure messaging platforms instead of email, when the metadata pattern itself carries value to an attacker. For most healthcare communication, body encryption plus a business associate agreement covers the HIPAA requirement.
Encrypting an email cryptographically transforms the body and attachments into ciphertext that requires a key or portal authentication to decode. Confidential Mode is a Gmail feature that stores the body normally on Google servers but restricts access through a link-based portal with expiration and passcode options. Confidential Mode is portal access control, not cryptographic body protection. The distinction matters for HIPAA because Google business associate agreement coverage does not extend to Confidential Mode content the same way it covers standard Workspace mail with the appropriate encryption controls.
