[mh_key_takeaways]
Most senders assume email encryption is a single technology. It is actually a stack of independent controls that operate at different points in the message journey. Transport encryption protects the connection between servers. Content encryption protects the message body itself.
Understanding how is email encrypted at each layer matters for anyone handling regulated data. A practice that assumes Gmail encrypts everything end to end may be storing PHI in a way that fails HIPAA audit. A HIPAA-focused encrypted email service handles both layers automatically.
This guide walks through the exact cryptography behind TLS, S/MIME, PGP, and portal-based encryption. It covers Gmail, Outlook, Apple Mail, iCloud, and the interoperability rules that govern messages between platforms.
Transport encryption protects the connection, not the message
Transport Layer Security, usually TLS 1.2 or 1.3, wraps the SMTP connection between mail servers in a cryptographic tunnel. Every packet that travels between the sending and receiving server is encrypted for the duration of the connection.
TLS negotiates through STARTTLS, an SMTP extension that upgrades a plaintext connection to an encrypted one. When both servers support it, the message travels encrypted. When one server does not, most systems fall back to plaintext SMTP by default.
The SMTP TLS Reporting standard from the IETF documents both the negotiation flow and the reporting mechanism. Modern platforms like Google Workspace and Microsoft 365 enforce TLS for connections to major providers.
Transport encryption ends when the message arrives at the receiving server. From that point, the message body sits decrypted on the receiving server storage unless content encryption was applied at the sender end.
Content encryption protects the message body itself
Content encryption wraps the message body, headers, and attachments in cryptography that only the intended recipient can unlock. The encrypted payload travels through the standard mail flow but stays unreadable to intermediate servers.
Three approaches dominate. S/MIME uses X.509 certificates issued to individual users. PGP uses per-user key pairs exchanged through key servers or manual transfer. Portal-based systems encrypt the content on the sender server and deliver a link that the recipient opens in a browser.
Each approach solves the same problem differently. S/MIME fits enterprise environments with a PKI. PGP fits technical users who exchange keys. Portal systems fit patient-facing healthcare workflows where recipient key management is impractical.
Content encryption survives any downstream server behavior. Even if the receiving mail server logs the message, indexes it for search, or backs it up to cold storage, the message body remains encrypted until the recipient decrypts it with their key.
Is Gmail email encrypted end to end
Gmail encrypts every message in transit with TLS 1.3 for outbound connections to servers that support it. Gmail also encrypts message storage at rest on Google infrastructure using AES with keys managed by Google.
Neither of those provides end-to-end encryption. Google can access message content for spam filtering, indexing, search, and legal disclosure. The user does not hold a key that keeps Google out of the message body.
Gmail S/MIME on Workspace Enterprise Plus adds certificate-based end-to-end encryption. Confidential Mode adds link expiration and SMS passcode delivery but does not encrypt the message body itself on Google servers.
For HIPAA use, Google Workspace signs a business associate agreement and provides the controls needed for compliance when properly configured. Practices should still verify TLS enforcement and layer content encryption for outbound PHI to non-Workspace recipients.
[mh_example]
Is Apple and iCloud email encrypted
Apple Mail and iCloud Mail encrypt messages in transit using TLS 1.2 or 1.3. Apple encrypts message storage at rest on iCloud servers, but the encryption keys sit with Apple, so Apple can decrypt content when legally required.
Advanced Data Protection, Apple end-to-end encryption feature for iCloud data, explicitly excludes iCloud Mail. Apple documents this exclusion in the Advanced Data Protection support article. The reason is IMAP compatibility.
Apple Mail supports S/MIME on macOS and iOS when a certificate is installed in Keychain Access. Users generate or import a certificate, and outbound messages sign and encrypt automatically to recipients with matching certificates.
For HIPAA use, iCloud Mail is not appropriate for PHI in its default configuration. Practices using Apple devices should route email through Google Workspace, Microsoft 365, or a dedicated HIPAA-compliant service that signs a BAA.
Is email encrypted between Gmail and Office 365
Messages between Gmail and Office 365 travel over TLS in nearly every modern deployment. Both platforms enforce STARTTLS for outbound connections to major providers, so the message travels encrypted in transit.
Neither platform provides end-to-end encryption for the message body between them by default. Google decrypts the message on receipt for spam scanning and storage. Microsoft does the same. Both providers can access content unless additional encryption was applied at the sender end.
For sender-controlled encryption between the two platforms, Google Workspace administrators enable S/MIME on Enterprise Plus, and Microsoft 365 administrators enable Purview Message Encryption or S/MIME. Both approaches require certificate exchange or portal delivery to non-encrypted recipients.
A simpler path for smaller practices is a shared HIPAA-compliant service that handles encryption on top of Gmail or Outlook without requiring PKI. That approach removes the certificate management burden entirely.
How to email encrypted files as attachments
Two paths deliver encrypted attachments. The first attaches a password-protected archive. The second wraps the whole message in content encryption that covers the attachment automatically.
Password-protected archives are the traditional fallback. Create a ZIP or 7z archive with a strong password, attach it to a normal email, and share the password through SMS, phone, or a separate secure channel.
The archive approach works with any recipient and any mail server. Its security depends entirely on password strength and out-of-band password delivery. Practices sending regulated files this way should use passwords of at least 16 characters generated from a password manager.
The content encryption approach uses S/MIME, PGP, or a portal-based service to encrypt the whole message including attachments. Recipients open the message with a key or a portal link. For PHI and other regulated content, this approach gives better auditability than password-protected archives.
[mh_protip]
Understand encrypted email file formats
Content-encrypted emails travel as MIME messages with cryptographic wrapping. The specific format depends on the encryption approach the sender used.
S/MIME messages carry a Content-Type of application/pkcs7-mime. The message body is a signed and encrypted PKCS#7 envelope. Recipients open the message in an S/MIME-capable client that decrypts the envelope with the recipient certificate.
PGP messages carry a Content-Type of multipart/encrypted with an OpenPGP application type. The message body is an OpenPGP-encrypted payload. Recipients decrypt with a PGP client that holds their private key.
Portal-based encryption delivers a wrapper message with a link to the encrypted content on the sender server. HPP files, an older legacy format, work similarly through a downloadable archive that opens in a proprietary reader. Modern portal services skip the HPP step by delivering the message directly to the recipient inbox.
Verify encryption end to end before sending PHI
Verification catches configuration gaps before they turn into HIPAA violations. Two checks matter for every regulated workflow.
First, verify TLS enforcement on both mail servers. NIST Special Publication 800-177 documents the recommended TLS configuration for email in the Trustworthy Email guide. Both sender and receiving servers should enforce TLS 1.2 or higher with strong cipher suites.
Second, verify content encryption reaches the recipient in a usable form. Send a test message with the exact encryption configuration used for real PHI, then confirm the recipient can open and reply to the message without error.
Practices building a compliant email stack also need healthcare website security features for the public-facing side. Encryption on email alone does not protect PHI on intake forms, patient portals, and appointment scheduling pages.
Choose an encryption stack that matches operational reality
Every encryption approach has an operational cost. S/MIME and PGP push key management onto the user or the IT team. Portal-based systems shift the friction to the recipient who has to click a link and sometimes create an account.
Practices with dedicated IT staff often run S/MIME with an internal PKI. Practices without dedicated IT often pick a HIPAA-focused service that handles the encryption behind the scenes. Both approaches meet compliance when configured correctly.
Mailhippo works alongside existing Gmail or Outlook accounts as a HIPAA-compliant secure email service. The base plan includes a business associate agreement and applies TLS with client-side encryption without requiring PGP keys or separate client software. Recipients open messages with one click.
Compare the options side by side. Look at email encrypted workflows, revisit whether is email encrypted for your specific stack, or review how to send email encrypted for one-off transfers. Pick based on how many messages you send per week and how much recipient friction the practice can absorb.
- Transport encryption protects the connection, not the stored message.
- Content encryption protects the message body across every server it touches.
- iCloud Mail is not covered by Apple end-to-end encryption program.
- Gmail and Office 365 encrypt in transit between each other by default.
- PHI needs verified TLS and content encryption together.
[mh_faqs]
