HorizLogoSm.fw_.png
Start Trial

Tag: pgp

Posted on

PGP Email Encryption Explained for Gmail and Outlook

pgp email encryption guide featured image

[mh_key_takeaways]

PGP email encryption has been the go-to method for security-conscious technical users since the 1990s. The current OpenPGP standard, RFC 9580, still uses the same public-key model that Phil Zimmermann designed in 1991, refreshed with modern algorithms.

PGP is strong, well-audited, and free in its GnuPG form. It is also famous for being harder to use than any browser-based alternative, which is why enterprises pair it with commercial key management and why patient-facing practices usually reach for a portal-based encrypted email service instead.

This guide covers what PGP actually does, how it fits with Gmail, Outlook, and Symantec Encryption, where it stands next to S/MIME, and when a simpler alternative saves days of key management work.

PGP uses public-key cryptography to protect the message body

PGP encrypts the message body with a symmetric AES key that is itself encrypted with the recipient public key. The recipient decrypts the AES key with their private key, then decrypts the body.

The same message can be signed with the sender private key, which lets the recipient verify the sender identity by checking the signature against the sender public key.

Public keys are shared through key servers, personal websites, or attached to a first message. The recipient can verify the public key belongs to the claimed sender by comparing the key fingerprint out-of-band, typically over a phone call.

The full protocol is defined in RFC 9580. GnuPG on Linux and the command line, GPG Suite on macOS, and Kleopatra on Windows all implement the same standard.

PGP does not protect the subject line or the routing headers. It only encrypts the message body and any attached payloads inside the PGP envelope.

PGP for Gmail requires a browser extension

Gmail does not include native PGP support in either the web client or the mobile apps. A browser extension bridges Gmail and the local PGP toolchain.

Mailvelope is the most widely used extension. It stores keys in a browser-managed keyring, wraps the Gmail compose window with an encrypt and sign toolbar, and outputs an armored OpenPGP block that Gmail sends as normal message text.

FlowCrypt is a paid alternative that adds enterprise features like automatic key discovery, a shared keyring, and Outlook integration. It handles the same PGP protocol under the hood.

The recipient side needs the same extension or another PGP-aware client to decrypt. That works well for developer-to-developer mail but breaks down for patient mail because patients do not install extensions.

Practices already on Google Workspace Enterprise Plus can enable hosted S/MIME instead, which handles encryption at the Gmail server side. S/MIME setup and key management is documented in the guide on S/MIME email encryption.

pgp email encryption in article illustration one

PGP for Outlook uses gpg4win or a commercial add-in

Outlook on Windows integrates with PGP through an add-in. Gpg4win with the GpgOL plug-in is the free option and installs a set of encrypt, sign, and decrypt buttons in the compose ribbon.

The add-in reads keys from the local GnuPG keyring. Enterprise deployments typically populate the keyring through a central key server or a directory that stores each user public key alongside their Active Directory entry.

Symantec Encryption Desktop, sold today under the Broadcom Symantec Encryption product line, is the commercial packaging. It adds central policy control, a Symantec Encryption Management Server for key escrow, and support for Outlook and other clients.

Outlook on macOS does not have an official gpg4win port. Users on macOS typically switch to Apple Mail with GPG Suite for PGP, or they run Outlook in a browser and use a PGP-aware webmail extension.

Outlook on the web does not support PGP add-ins directly. Organizations using OWA for their primary interface generally pick S/MIME or Purview Message Encryption instead, or route mail through a gateway that applies encryption at the transport.

Symantec PGP centralizes key management for the enterprise

Symantec PGP was originally sold by PGP Corporation, acquired by Symantec in 2010, and now sold under the Broadcom umbrella. The product line is Symantec Encryption Desktop and Symantec Encryption Management Server.

The Encryption Management Server is the piece that most GnuPG deployments do not have. It centralizes key generation, escrow, revocation, and policy enforcement across the tenant.

Encryption Desktop installs on each endpoint and handles the Outlook add-in, disk encryption, and file encryption. It reads policy from the management server on start and applies encryption rules to outbound mail.

The commercial packaging removes the key management overhead that stops many teams from adopting PGP. It does not remove the recipient-side requirement, so PGP still fits internal enterprise mail and B2B mail with a matched setup better than it fits patient mail.

Support and licensing are through Broadcom. Pricing is not published publicly, and quotes come through a Broadcom sales contact or an authorized reseller.

[mh_example]

PGP compared to S/MIME on the practical decisions

PGP and S/MIME both use public-key cryptography to encrypt email. They differ on trust model, mail client support, and enterprise integration.

PGP relies on a web of trust, where users sign each other keys directly. S/MIME relies on a certificate authority, where a trusted CA signs each user certificate.

S/MIME is built into Outlook, Apple Mail, and Google Workspace Enterprise Plus without a plug-in. PGP requires an extension or an add-in for every mainstream email client.

Feature PGP S/MIME
Trust model Web of trust Certificate authority
Standard OpenPGP RFC 9580 S/MIME RFC 8551
Native Outlook support Add-in required Built in
Native Gmail support Browser extension Hosted S/MIME on Enterprise Plus
Native iPhone Mail Not supported Built in with configuration profile
Key exchange Manual or key server Certificate exchange in signed messages
Typical use case Developer to developer, B2B security teams Enterprise internal, government

For patient mail, neither PGP nor S/MIME is a great fit because patients do not hold keys. Portal-based encrypted email services skip the key exchange step and are documented in the guide on email encryption.

pgp email encryption in article illustration two

Key management is the hard part of PGP

Generating a PGP key pair takes one command. Managing that key pair across a laptop, a phone, a work desktop, and a home machine, over five years and multiple client switches, is the actual work.

Best practice is to keep the private key on a hardware security module or a YubiKey rather than on the disk. That removes the risk of a stolen laptop exposing years of encrypted mail.

Public keys need to be published somewhere the sender can find them. Options include the personal Keyoxide profile, a personal website, a company directory, or the older SKS keyserver network, which is now mostly deprecated.

Key revocation is the other hard problem. When a private key is compromised, the user needs to publish a revocation certificate so that senders stop encrypting to the old key.

Enterprise deployments handle this through a management server. Individual users typically write the revocation certificate to paper when they generate the key and store it in a safe.

HIPAA compliance needs more than PGP encryption alone

PGP encryption satisfies the transmission security part of the HIPAA Security Rule when applied to messages containing protected health information. That is not the full compliance picture.

HIPAA also requires a signed business associate agreement with any vendor that handles PHI, access controls on the mailbox and the key store, audit logs of who sent and received each message, and an incident response procedure for lost or stolen keys.

Google Workspace and Microsoft 365 offer a BAA on eligible paid plans, but the practice must actively request and sign it. Free consumer Gmail and personal Outlook.com are never covered by a BAA, regardless of whether PGP is layered on top.

The HHS Covered Entities reference covers when a BAA is required. Any vendor that touches, stores, or transmits PHI on the covered entity behalf falls under the rule.

Practices building a full patient communication stack also need to think about the surrounding website. Guidance on security features for healthcare websites covers form handling, SSL, and portal integration alongside encrypted mail.

[mh_protip]

PGP fits developer and B2B mail better than patient mail

PGP shines in two common use cases. The first is developer-to-developer mail, where both sides already have keys, run a PGP-aware mail client, and value the strong cryptography.

The second is B2B mail between two security teams, where the setup cost is paid once and the volume justifies it. Enterprises exchanging incident data, threat intelligence, or contract packages often use PGP over commercial email gateways.

Patient mail rarely fits either shape. Patients do not have keys, do not run a PGP-aware client, and will not install a browser extension on the phone they use to check email.

For patient mail, portal-based encrypted email services deliver a link that the patient opens with a passcode. The message and any attachments live inside the portal, and the recipient reads and replies without installing anything.

Referring providers and insurance carriers usually accept portal-based delivery because it does not depend on their own encryption setup. That decouples the practice mail from every partner IT team.

Automation with PGP uses gpg and Bouncy Castle

Automated PGP encryption for batch mail from a report generator or a lab bridge uses the gpg command line on Linux and the Bouncy Castle PGP API on Java.

The gpg –encrypt –recipient email@example.com command reads the file from stdin, encrypts with the recipient public key, and writes the armored output. A shell script pipes the output into mutt or msmtp for delivery.

Bouncy Castle provides the PGPEncryptedDataGenerator, PGPCompressedDataGenerator, and ArmoredOutputStream classes. The Java code loads the recipient public key from a keyring, wraps the message bytes, and writes the resulting armored OpenPGP block into a MimeBodyPart.

For applications sending PHI at scale, calling a secure email API that handles encryption server-side is usually faster than adding key management inside the application. The API pattern also simplifies deployment because the container image does not carry key files.

The choice comes down to whether the recipients already run PGP. If yes, the code path stays inside the application. If no, a portal delivery service handles the recipient side without asking them to set up anything.

When PGP is the right answer and when to pick something else

PGP is the right answer when both sides already run PGP, the recipient will not accept portal links, and the volume justifies the setup cost. It is also the right answer when the recipient is a security team that expects an armored OpenPGP block in the message body.

S/MIME is the right answer for internal enterprise mail where every mailbox is on the same Outlook or Google Workspace tenant and every user already has a certificate through the corporate PKI.

Portal-based encrypted email is the right answer for patient mail, referring providers, and insurance carriers. The recipient opens a link, signs in with a passcode, and reads the message without any account setup.

For a small practice sending a mix of internal, referring provider, and patient mail from Gmail or Microsoft 365, layering a dedicated encrypted email service on top of the existing mailbox covers all three cases with one setup step.

Whichever method fits, run a round-trip test with a real recipient before rolling it out. The most common cause of failed PGP deployments is that the sender got a green Encrypt button but the recipient never received a readable message.

[mh_faqs]

Posted on

How Is Email Encrypted A Practical Guide for Healthcare and Business

how is email encrypted guide featured image

[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.

how is email encrypted in article illustration one

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.

how is email encrypted in article illustration two

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]

Posted on

What Does Encrypted Email Mean and How Encryption Protects Messages

what does encrypted email mean guide featured image

[mh_key_takeaways]

Encrypted email means the message content is scrambled into unreadable ciphertext during transit, storage, or both. Only a recipient holding the correct decryption key can convert it back to plain text.

That definition sounds straightforward. The complication is that encryption happens at different points in the message lifecycle, and each point protects against a different threat. Understanding the layers is the difference between a real safeguard and a marketing label.

This guide walks through what encryption means at each layer, what it protects, and where it stops. For practices sending patient information, the layer question feeds directly into whether a service qualifies as one of the compliant encrypted email services under HIPAA.

The mechanics of email encryption in plain language

Encryption uses a mathematical function to convert readable text into a scrambled string. The function requires a key, which is a piece of secret data. The same key or a paired key reverses the function on the receiving end.

Symmetric encryption uses the same key on both ends. It is fast but requires the sender and recipient to share the key over a secure channel first.

Asymmetric encryption uses a public key to encrypt and a private key to decrypt. The sender uses the recipient’s public key, which can be shared openly. Only the recipient’s private key can decrypt the message.

Email systems combine both. The message body is encrypted with a symmetric key for speed. The symmetric key is then encrypted with the recipient’s public key. The recipient decrypts the symmetric key with their private key, then decrypts the message.

Understanding the mechanics helps interpret what a service is actually doing when it claims to encrypt messages. Sibling coverage on the practical outcome is in what does encrypting email do.

The three points where email encryption happens

An email passes through several stages between the sender’s compose window and the recipient’s inbox. Encryption can apply at each stage.

  • Transit between mail servers, protected by TLS.
  • Storage on the sender’s mail server, protected by at-rest encryption.
  • Storage on the recipient’s mail server, protected by at-rest encryption.
  • The recipient’s local device, protected by disk encryption.

A message can be encrypted at one point and exposed at another. TLS protects the wire but not the stored copy. End-to-end encryption protects both the wire and every stored copy, but not the recipient’s decrypted local version.

Compliance auditors ask about each layer individually. A general claim of “encrypted email” without specifying which layer is not a defensible answer.

what does encrypted email mean in article illustration one

TLS between mail servers is the baseline layer

Transport Layer Security encrypts the connection between two mail servers during message delivery. Gmail, Outlook.com, and Microsoft 365 all attempt TLS 1.2 or 1.3 by default.

TLS protects against network-level eavesdropping. An attacker sitting on a coffee shop Wi-Fi or an ISP link cannot read the message body while it moves between servers.

The limitation is that TLS applies only during transit. Once the message reaches the recipient’s server, it is decrypted, stored, and re-encrypted with a different key that the server controls. Both the sending and receiving providers can read the stored copy.

TLS also fails silently when the receiving server does not support a compatible version. The message falls back to plain text, and the sender is not warned. The NIST SP 800-52 Rev. 2 guidance documents the accepted TLS versions and cipher suites.

For HIPAA scenarios, TLS alone is usually not enough because the sender cannot prove the message stayed encrypted through the full delivery path.

End-to-end encryption keeps the mail provider out of the loop

End-to-end encryption uses the recipient’s public key to encrypt the message on the sender’s device. The message stays encrypted through every server it passes through, including both mail providers.

Only the recipient’s private key, held on the recipient’s device, can decrypt the message. Neither mail provider ever sees plain text, which is a stricter model than TLS or gateway-based encryption.

S/MIME and PGP both operate at this layer. S/MIME uses certificates issued by a trusted authority. PGP uses keys the user generates and controls directly.

The tradeoff is that both sides need to hold matching keys or certificates. For practices sending to patients who do not have PGP or S/MIME, end-to-end is impractical. Gateway encryption with portal fallback is usually the better fit.

The sibling article does email encryption really work covers this reliability question in more depth.

[mh_example]

Gateway encryption sits in the middle of the spectrum

Gateway-based services intercept outbound mail at the sender’s mail server, encrypt the message body on that server, and deliver it to the recipient through a secure channel.

Microsoft Purview Message Encryption is the built-in gateway for Microsoft 365 Business Premium and Enterprise. Google Workspace hosted S/MIME serves a similar role on Enterprise Plus. Dedicated services like Mailhippo operate at the same layer for accounts on any plan.

The recipient experience varies. Some services deliver directly to the recipient’s inbox with TLS enforcement. Others deliver a link to a secure portal where the recipient signs in with Microsoft, Google, or a one-time passcode.

Gateway encryption is the pragmatic middle ground for most compliance workflows. It removes the per-contact certificate exchange required by S/MIME while still producing audit logs and enforcing encryption at the message level.

What encrypted email actually protects against

Encryption addresses specific threats. Knowing what those threats are helps calibrate expectations about what a specific service delivers.

  • Network-level eavesdropping on the wire between mail servers.
  • Unauthorized access to stored messages on the sending or receiving mail server.
  • Interception at intermediate mail relays operated by third parties.
  • Bulk data harvesting during a mail provider breach.
  • Legal discovery requests directed at the mail provider, for end-to-end scenarios.

Encryption does not protect against a compromised endpoint, a phishing attack that captures the user’s password, or a device left unlocked. Those threats live outside the encryption boundary.

The CISA guidance on protecting against cyber attacks covers the layers that encryption cannot address on its own.

what does encrypted email mean in article illustration two

What encrypted email does not protect against

The most common source of an email breach is not intercepted encryption. It is a legitimate account accessed by an attacker after a phishing or credential-stuffing attack.

Encryption does not stop an attacker who logs into the recipient’s mailbox with the correct password. Once inside, the attacker reads decrypted messages in the normal client just like the real user would.

Encryption also does not stop a compromised device from exfiltrating messages. Malware that has taken control of the endpoint reads mail after the client has decrypted it.

Multi-factor authentication, workforce training, and endpoint protection sit alongside encryption in a real security stack. The sibling article what is an encrypted email mean covers the definitional side.

For practices whose email decision is part of a broader security posture, a review of healthcare website security features covers the parallel considerations on the web side.

How the recipient experiences an encrypted email

The recipient experience varies by encryption model. A TLS-encrypted message looks identical to any other email because the encryption is invisible between servers.

An S/MIME message in Outlook shows a small ribbon icon in the message header. Apple Mail on macOS and iOS shows a lock icon. Clients without S/MIME support display the encrypted payload as an attachment they cannot open.

A gateway-encrypted message delivered through a portal arrives as a normal-looking notification email with a link. The recipient clicks the link and signs in with Microsoft, Google, or a one-time passcode to read the message.

The sibling article what does encrypted email look like covers the visual side in more detail. The recipient-side handling question is covered in what happens when I encrypt an email.

[mh_protip]

Compliance frameworks and what they expect encryption to mean

HIPAA requires reasonable safeguards for electronic protected health information. The Security Rule does not mandate a specific encryption algorithm but requires TLS 1.2 or higher for transmission and encryption at rest for stored PHI.

CMMC requires FIPS 140-2 validated cryptographic modules for Controlled Unclassified Information. That is a stricter standard than HIPAA and rules out some consumer-grade encryption implementations.

GDPR requires appropriate technical measures to protect personal data of EU residents. Encryption of email carrying personal data is one of the measures the regulation explicitly names.

Each framework asks a variant of the same question. Is the encryption strong enough, applied consistently, and documented well enough to defend during an audit? The HIPAA Journal breakdown of encryption requirements is a useful reference for the healthcare side.

Practices coordinating email compliance with broader digital operations can align with a healthcare marketing agency so patient-facing channels share the same posture.

Where dedicated compliant services fit

A dedicated compliant email service applies the encryption automatically at the mail gateway, keeps the audit trail, and provides the Business Associate Agreement or equivalent contract in the base plan.

Mailhippo is one example of that model. It works with existing Gmail or Microsoft 365 mailboxes, encrypts every outbound message without requiring the user to click an Encrypt button, and includes the BAA at signup.

That removes the two most common failure modes on user-driven encryption. Staff cannot forget to encrypt a specific message, and the vendor cannot claim it never handled PHI.

The sibling articles what does it mean encrypted email and HIPAA compliant secure email service cover the same territory from adjacent angles.

The short answer for a practice or business owner

Encrypted email means the message content is protected against interception and unauthorized access at one or more points during its lifecycle. The specific meaning depends on the encryption model in use.

TLS between mail servers is the baseline that Gmail and Microsoft 365 already provide. Gateway encryption is the pragmatic layer that adds message-level protection and audit trails. End-to-end encryption is the strictest layer, reserved for the highest-sensitivity content.

A practice deciding which layer it needs starts with the compliance framework, then works backward to the technical setup. Framework first, technology second.

Practices aligning email decisions with the broader digital footprint can review their healthcare digital marketing services so patient outreach, forms, and encrypted communication share a common standard.

[mh_faqs]

Posted on

How to Encrypt Email Across Every Major Provider

how to encrypt email guide featured image

[mh_key_takeaways]

Email encryption looks different in every mail client. The button lives in different menus. The recipient sees a different sign-in flow. The license required to unlock it changes by provider tier.

This guide covers how to encrypt email in Outlook, Gmail, Apple Mail, and Yahoo, plus S/MIME certificate setup and hosted alternatives. Where a healthcare team needs a simpler flow, a dedicated secure email service with a BAA in the base plan removes the license tier and portal steps entirely.

Read the sections in order. Each includes the exact click path, the recipient experience, and the license or certificate required to make it work.

The Three Practical Types of Email Encryption

Every encryption option in a mail client falls into one of three buckets. Knowing the bucket helps predict how the recipient will open the message.

TLS handles server-to-server transit. It runs automatically between providers that support it. The sender takes no action. The recipient sees a normal email in their inbox.

S/MIME and PGP encrypt the message body end to end using certificates or keys installed on each side. Setup is per user. Once configured, the flow is one click.

Portal-based encryption from Microsoft or Google routes the message through a hosted page. The recipient clicks a link and signs in or enters a one-time passcode. This adds friction but works with any recipient regardless of their client.

The right choice depends on who the recipient is and whether both parties can maintain certificates.

Encrypting Email in Outlook Step by Step

Outlook 365 and the New Outlook client both use Microsoft Purview Message Encryption behind the Encrypt button.

Compose a new message. On the ribbon, click the Options tab. Click Encrypt. Choose Encrypt-Only for standard protection or Do Not Forward to block forwarding, copying, and printing.

Add the recipient, subject, and body. Attachments inherit the same protection as the message. Click Send.

The Encrypt button requires Microsoft 365 Business Premium, E3, E5, A3, A5, or G3/G5. Business Basic and Business Standard do not include it. The Purview Message Encryption documentation lists every eligible plan.

External recipients receive a notification email with a portal link. They sign in with Microsoft, Google, or a one-time passcode. Related guide: how to encrypt email in Outlook.

how to encrypt email in article illustration one

Encrypting Email in Gmail and Google Workspace

Gmail offers two encryption paths, each tied to a different plan level.

Confidential Mode is available on all Google accounts, including personal Gmail. In the compose window, click the lock and clock icon at the bottom. Set an expiration date and optional SMS passcode.

Confidential Mode restricts forwarding, copying, and downloading. It does not encrypt the message end to end. Google can still read the content, so it does not meet HIPAA end-to-end requirements on its own.

Hosted S/MIME is available only on Google Workspace Enterprise Plus, Enterprise Standard with add-on, and Education Plus. Admins enable it in the Google Admin console under Apps, Google Workspace, Gmail, User settings.

With hosted S/MIME on, users see a padlock icon in the compose window. Green padlock means encryption is available for the recipient.

Encrypting Email in Apple Mail on macOS and iOS

Apple Mail supports S/MIME natively. Setup happens through Keychain Access.

On macOS, obtain an S/MIME certificate from a public CA or internal PKI. Double-click the .p12 file to import into Keychain. Restart Mail.

When composing a message to a recipient whose public key is in your contacts, a lock icon appears next to the subject line. Click it to toggle encryption on.

On iOS and iPadOS, install the certificate through a configuration profile pushed from an MDM provider or emailed as an attachment. Go to Settings, Mail, Accounts, select the account, then Advanced. Toggle S/MIME on.

Apple Mail S/MIME works only when the recipient also has a certificate installed and their public key is in the sender contact record. Cross-provider encryption to Gmail requires the Gmail recipient to have hosted S/MIME.

[mh_example]

S/MIME Certificate Setup and Exchange

S/MIME needs an X.509 certificate for each user. Certificates come from public CAs like DigiCert, GlobalSign, and Sectigo, or from an internal PKI.

Purchase a personal email certificate matching the user email address. Follow the CA verification steps, which typically involve a validation email and identity check. Download the .p12 or .pfx file.

Install the certificate to the local certificate store on Windows, Keychain on macOS, or the mail client store on mobile. Restart the mail client.

Before the first encrypted send, exchange signed messages with each recipient. Each signed message carries the sender public key, which the recipient client stores in the contact record.

Certificates typically expire after one year. Renewal happens through the CA portal. Expired certificates block new encrypted sends until reissued. Track expirations in a shared calendar.

how to encrypt email in article illustration two

PGP Encryption for Technical Users

PGP is the alternative to S/MIME. It uses key pairs generated locally instead of certificates issued by a CA. Journalists, security researchers, and open-source maintainers use it heavily.

Install GPG Suite on macOS, Gpg4win on Windows, or OpenKeychain on Android. Generate a key pair with a passphrase. Upload the public key to a keyserver like keys.openpgp.org or share it directly with recipients.

Configure the mail client extension. Enigmail for Thunderbird, GPG Mail for Apple Mail, and Mailvelope for browser-based Gmail all handle PGP encryption per message.

PGP has no central authority. Trust builds through key signing and web of trust models. The learning curve is steeper than S/MIME, which is why most business users skip it.

Healthcare senders rarely use PGP because recipients cannot install extensions on hospital systems. S/MIME or hosted encryption fits the workflow better.

What the Recipient Sees on Each Method

Recipient experience predicts adoption. If opening the message is hard, the sender gets a phone call instead of an acknowledgment.

  • TLS encrypted messages appear as normal emails in the inbox. No sign-in step. No portal.
  • S/MIME encrypted messages open directly in the recipient mail client provided their certificate is installed. Otherwise the client shows an encrypted attachment icon and refuses to display the body.
  • Microsoft Purview Message Encryption sends the recipient a notification email with a link. They sign in with Microsoft, Google, or a one-time passcode.
  • Gmail Confidential Mode sends a notification with a Google-hosted link. Non-Gmail recipients enter an SMS passcode if the sender enabled it.
  • A dedicated encrypted email service like Mailhippo delivers messages that open with one click, without portals or passcodes on the recipient side.

Practices whose recipients are older patients or busy referring physicians measure the friction cost carefully. One extra step per message compounds across a caseload.

[mh_protip]

Automatic Encryption Rules for Consistent Compliance

Manual clicking depends on staff remembering to encrypt. Rules take that decision out of the sender workflow.

Exchange Online admins create mail flow rules that trigger on subject keywords, sender group, recipient domain, or content matching a sensitive information type. The rule action applies Office 365 Message Encryption automatically.

Google Workspace admins configure content compliance rules under Apps, Google Workspace, Gmail, Compliance. Conditions include predefined data types for medical record numbers, Social Security numbers, and credit card numbers.

Rules cover the gap when workforce members forget to click Encrypt. They also apply to messages sent from mobile devices that lack a ribbon.

Test each rule against a monitored test mailbox before pushing to production. False positives on internal messages create friction that pushes users to send from personal accounts.

HIPAA Requirements Beyond the Encryption Click

Encryption satisfies one HIPAA Security Rule safeguard. Full compliance requires several more.

The practice signs a business associate agreement with the email provider. Microsoft and Google both offer BAAs on eligible plans. Sign it before sending PHI. The HHS Security Rule guidance covers each safeguard.

Additional obligations include workforce training on PHI handling, audit logging on message access, access controls with unique user IDs, sanction policies for violations, and incident response procedures.

A healthcare practice that clicks Encrypt but leaves the BAA unsigned is not compliant. OCR breach investigations routinely surface this gap.

Practices that also run patient-facing websites face parallel obligations. See HIPAA-compliant healthcare website design for the site-side controls that pair with encrypted email.

When a Dedicated Encrypted Email Service Makes Sense

Native encryption in Outlook and Gmail works well for organizations already on the qualifying license tier with dedicated IT staff. Elsewhere, cost and complexity push practices toward a dedicated service.

Small practices on Business Basic or a starter Workspace plan avoid the per-seat cost jump to unlock encryption. Multi-provider teams running Gmail and Outlook side by side avoid maintaining certificates in two ecosystems.

Mailhippo is a HIPAA-compliant email service that works with existing Gmail and Outlook accounts, includes a business associate agreement in the base plan, and delivers encrypted email to recipients without a portal sign-in. TLS plus client-side encryption cover the transmission safeguard without per-recipient S/MIME certificates.

Related guides: how to encrypt an email across clients, how to send encrypted email, and encrypt email for the terminology overview.

Match the method to the workflow. Native buttons for standardized enterprise tenants. S/MIME for internal certificate-managed teams. A dedicated service for practices that want one-click send and one-click open across every recipient.

[mh_faqs]

Posted on

How Can I Encrypt My Emails in Gmail, Outlook, and Office 365

how can i encrypt my emails guide featured image

[mh_key_takeaways]

The question “how can I encrypt my emails” has different answers depending on which mail provider is in front of you. Gmail, Outlook, and Microsoft 365 each expose different controls, and personal accounts on all three offer less than their business counterparts.

This guide walks through the encryption paths available in each platform, explains where S/MIME and PGP fit, and covers the compliance layer for practices that need audit trails. For practices sending patient information, dedicated encrypted email services are usually the shortest path.

Each section below covers the steps for a specific platform or method. Skip to the section that matches your setup.

Three layers of email encryption you need to understand first

Email encryption is not one thing. It operates at three layers, and each solves a different problem.

The first layer is TLS between mail servers. It protects the message on the wire from one server to the next. Gmail, Outlook.com, and Microsoft 365 all enforce TLS 1.2 or 1.3 by default when the receiving server supports it.

The second layer is message-level encryption. The mail provider encrypts the message body on its own servers and delivers it to external recipients through a portal or a signed session. Microsoft Purview Message Encryption and Google Workspace hosted S/MIME operate at this layer.

The third layer is end-to-end encryption. The message body is encrypted on the sender’s device and stays encrypted until the recipient decrypts it. S/MIME with client-held certificates and PGP both operate at this layer.

Most business scenarios stop at the second layer. The third layer adds friction that only pays off when the message content is unusually sensitive or the recipient’s mail server cannot be trusted with plain text.

How to encrypt emails in Gmail with a Workspace account

Gmail on Google Workspace Enterprise Plus supports hosted S/MIME. The admin enables it in the Google Admin console under Apps, Google Workspace, Gmail, User settings.

Once enabled, users upload their S/MIME certificate through Gmail settings. Compose messages then show a lock icon next to the recipient field, indicating that the message will send encrypted.

Encryption only applies when the recipient also holds a certificate. For recipients without one, Gmail falls back to standard TLS delivery. That fallback is the reason S/MIME alone is not sufficient for a healthcare workflow.

The Google Workspace S/MIME setup guide walks through the certificate upload and enforcement policies. Confidential Mode is not a substitute for S/MIME and does not satisfy HIPAA.

Practices on lower Workspace tiers do not have hosted S/MIME. Those accounts need a third-party gateway or a dedicated compliant email service.

how can i encrypt my emails in article illustration one

How to encrypt emails in Outlook with a Microsoft 365 plan

Outlook on Microsoft 365 Business Premium, E3, and E5 exposes an Encrypt button in the compose window. It sits in the Options ribbon on the desktop app and in the three-dot menu on Outlook web.

Clicking Encrypt triggers Purview Message Encryption. The user picks an encryption policy such as Encrypt Only or Do Not Forward. The message travels encrypted, and external recipients receive a portal link with sign-in options.

The Microsoft Purview Message Encryption documentation details the policy options and the recipient experience. Setup usually completes in the admin center within an hour if Azure Rights Management is already active on the tenant.

Business Basic and Business Standard do not include the Encrypt button. Practices on those plans either upgrade or add a dedicated encryption layer. Sibling coverage for the Outlook-specific path is in can I encrypt emails in Outlook.

For a broader walkthrough of Gmail-side encryption steps, see how can I encrypt an email.

Setting up S/MIME on a desktop Outlook client

Desktop Outlook supports S/MIME natively. The user needs a certificate issued to their email address, installed in the Windows certificate store or on a smart card.

  • Obtain an S/MIME certificate from a trusted certificate authority. Commercial certificates cost $20 to $60 per year.
  • Import the certificate into the Windows certificate store under Personal, Certificates.
  • In Outlook, open File, Options, Trust Center, Trust Center Settings, Email Security.
  • Under Encrypted email, click Settings and select the imported certificate.
  • Optionally enable Encrypt contents and attachments for outgoing messages to make encryption the default.

Once configured, the compose window shows a lock icon when the recipient’s certificate is available. If the recipient has never sent a signed message, Outlook cannot encrypt to them until their certificate is exchanged.

The exchange step is the operational tax of S/MIME. It works well inside a practice where every mailbox has a certificate. It falls apart with external partners and patients who do not.

[mh_example]

Using PGP with Thunderbird or Mailvelope

PGP encryption uses a public-private key pair that the user generates and controls. It works with any email account, including personal Gmail and Outlook.com, but requires a compatible client on both ends.

Thunderbird has built-in PGP support since version 78. The user generates a key pair in Account Settings, End-to-End Encryption. The public key is shared with correspondents through a keyserver, direct exchange, or embedded in outgoing signatures.

Mailvelope is a browser extension that adds PGP support to Gmail and other web-based clients. It handles key generation and message encryption directly in the browser without the mail provider seeing plain text.

PGP is the preferred method for individual users, journalists, and technical audiences who prioritize key control. It is rarely the right method for a healthcare practice because patients and referring providers will not install a PGP client.

For a client-facing walkthrough of PGP versus gateway encryption, the sibling article how do my clients encrypt email covers the tradeoffs.

Encrypting attachments without encrypting the message

Sometimes the message body is fine to send in plain text and only the attachment carries sensitive data. Password-protecting the attachment lets the email travel through any provider.

  • Compress the file using 7-Zip, WinRAR, or Windows built-in compression with AES-256 encryption enabled.
  • Set a strong password of 12 characters or more with mixed case, numbers, and symbols.
  • Attach the encrypted archive to the email as normal.
  • Share the password over a separate channel, such as a phone call, SMS, or in-person conversation.

This method is common for one-off file transfers between organizations that have no shared encryption infrastructure. It is not compliant on its own for HIPAA because it does not produce an audit trail and the password channel is often insecure.

Practices exchanging patient files frequently should route those exchanges through a compliant email service instead. The sibling piece on how to encrypt my sent emails covers the outbound side in more depth.

how can i encrypt my emails in article illustration two

Government and military email encryption requirements

Army and other DoD email accounts require encryption through the DoD Common Access Card or Personal Identity Verification card. The CAC holds the S/MIME certificate that Outlook and OWA use to encrypt outbound mail.

Signed drivers for the CAC reader and the ActivClient middleware need to be installed on the endpoint. Once installed, Outlook detects the certificate and enables Sign and Encrypt buttons in the compose ribbon.

Encrypting from a home computer to a .mil address requires the sender’s CAC and the recipient’s published certificate. The DoD Global Address List holds those certificates for internal-to-internal traffic.

Contractors handling Controlled Unclassified Information under CMMC use a similar S/MIME model or a compliant email gateway. The NIST SP 800-171 Rev. 2 guidance covers the required controls for those workloads.

Compliance-driven encryption for HIPAA, CMMC, and GDPR

User-driven encryption on a per-message basis rarely satisfies a compliance framework. The framework requires a documented standard, retained audit trails, and a signed agreement with the vendor handling the data.

HIPAA requires a Business Associate Agreement with the email vendor. CMMC requires FIPS 140-2 validated cryptographic modules for CUI. GDPR requires a Data Processing Agreement covering personal data of EU residents.

A gateway-based compliant service handles all three by applying encryption at the mail server, retaining logs, and providing the signed agreement in the base plan. That removes the burden of a user deciding whether a specific message qualifies.

Practices that also send bulk patient communications should coordinate with a healthcare marketing agency so that outreach and compliance sit on the same infrastructure.

The HIPAA Journal breakdown of compliant email is the authoritative external reference for the healthcare side.

[mh_protip]

Verifying that a message was actually encrypted

An encrypted send is only useful if the encryption held. Every major mail client provides a way to verify.

In Gmail, open the message, click the three-dot menu, and select Show Original. The header displays the TLS status of the delivering connection.

In Outlook desktop, right-click the message and choose Message Options. The header shows Received lines with TLS version details.

For end-to-end encryption, the client shows a lock icon or shield in the message header. S/MIME messages in Outlook show a blue ribbon. Encrypted messages in Gmail show a green lock.

If none of those indicators appear, the message either traveled without encryption or the encryption fell back to a lower tier than the sender expected. That is worth catching before the next send rather than after an audit.

When a dedicated compliant email service saves setup time

The setup steps above cover the manual paths available in Gmail, Outlook, and Microsoft 365. Each works for individual users comfortable managing certificates or keys per contact.

A dedicated compliant email service replaces the manual path with an automatic one. The practice connects its existing mailbox, adds a DNS record, and every outbound message is encrypted at the gateway. No per-contact certificate exchange is required.

Mailhippo is one example of that model. It works with existing Gmail and Microsoft 365 accounts, includes the Business Associate Agreement in the base plan, and delivers messages directly to recipient inboxes without a portal login for standard scenarios.

For the underlying encryption model comparison, the sibling article how to encrypt email covers the technical layer in more depth. For the recipient-side experience, how can you encrypt an email walks through what the reader sees.

Choosing the right method for your workflow

The right encryption method depends on volume, sensitivity, and recipient technical skill.

Individuals sending occasional sensitive messages to technical peers can use PGP through Thunderbird or Mailvelope. The setup pays off because the recipient list is small and every recipient has the tools.

Small businesses on Microsoft 365 Business Premium can use the Encrypt button. It handles the recipient experience through the portal and needs no per-user certificate.

Healthcare practices, law firms, and financial services with compliance obligations need a gateway-based service. It removes the user decision and produces the audit trail auditors ask for.

Practices reviewing the broader digital footprint alongside the email decision can also review their healthcare website security features so the same standards apply across email, forms, and portals.

[mh_faqs]

Posted on

Encrypt an Email in Gmail Outlook and Beyond With Real Compliance

encrypt an email guide featured image

[mh_key_takeaways]

To encrypt an email means scrambling the message body and attachments so only the intended recipient can read them. The steps vary by mail platform and by how strong the encryption needs to be.

This guide walks through the practical methods in order of increasing security, covers the cost of each, and explains where each fits. For practices sending patient information, dedicated encrypted email services are usually the shortest path.

Skip to the section that matches your mail platform if you already know which one you use. Otherwise, read from the top to compare.

The five ways to encrypt an email you might encounter

Encryption for email comes in five practical forms. Each targets a different scenario, and knowing the differences prevents wasted setup effort.

  • TLS between mail servers, on by default across Gmail, Outlook.com, and Microsoft 365.
  • Confidential Mode in Gmail, which restricts actions but does not encrypt the body.
  • Microsoft Purview Message Encryption in Outlook, triggered by the Encrypt button.
  • S/MIME and PGP end-to-end encryption, using certificates or key pairs.
  • Gateway-based encryption services that route mail through a compliant server.

TLS is baseline. Confidential Mode is not real encryption. Purview and S/MIME are the Microsoft- and Google-native strong options. Gateways are the third-party option that works on any account.

Related coverage on the same territory is in to encrypt an email and can I encrypt an email.

How to encrypt an email in Outlook using the Encrypt button

Microsoft 365 Business Premium and Enterprise plans include Purview Message Encryption. The user experience is a single button in the compose window.

  • Open Outlook and start a new message.
  • On the desktop app, click Options in the ribbon, then Encrypt.
  • On Outlook web, click the three-dot menu in the compose window, then Encrypt.
  • Choose an encryption policy from the dropdown, such as Encrypt Only or Do Not Forward.
  • Compose and send the message as normal.

Internal recipients on the same tenant read the message directly in Outlook. External recipients receive a portal link and sign in with Microsoft, Google, or a one-time passcode.

The Microsoft Purview Message Encryption documentation covers the policy options and setup steps in more depth. Sibling coverage in how do you encrypt an email outlook covers the same flow from a different angle.

encrypt an email in article illustration one

How to encrypt an email in Gmail with hosted S/MIME

Gmail on Google Workspace Enterprise Plus supports hosted S/MIME, which encrypts messages end-to-end using certificates. It is the only Google-native option that meets healthcare compliance.

The admin enables S/MIME encryption for outgoing email in the Google Admin console. Each user uploads a personal certificate through their Gmail settings.

Once configured, composing a message shows a lock icon next to the recipient field. If the recipient’s certificate is available, the icon shows green and the message will encrypt automatically.

Recipients without a certificate fall back to standard TLS delivery. That fallback is why S/MIME alone is not sufficient for a full compliance program.

The Google Workspace S/MIME setup guide covers the certificate policies. For the Outlook variant of the same standard, see encrypting an email outlook.

How the main platforms compare on cost and compliance

The right platform depends on the existing subscription, the compliance requirement, and the recipient’s technical skill. A side-by-side view helps narrow the choice.

Method Monthly cost per user Meets HIPAA Recipient friction Setup effort
Outlook Encrypt button (M365 Business Premium) Around $22 Yes, with BAA Low, portal fallback Low
Google Workspace Enterprise Plus S/MIME Around $30 plus certificate cost Yes, with BAA High, needs recipient certificate High
PGP via Mailvelope on any plan Free, plus mail plan cost Case by case documentation Very high, needs PGP client Medium
Gateway service on any plan $5 to $15 Yes, BAA in base plan Low, portal fallback Low, DNS record

For a solo practice, the gateway path costs the least and meets compliance out of the box. For a Microsoft 365 tenant already at Business Premium, the Encrypt button is already paid for and adds nothing more. Google Workspace Enterprise Plus is the most expensive path per user.

[mh_example]

Encrypting an email containing PHI

Protected health information carries specific HIPAA obligations. Encrypting an email that contains PHI is one part of a larger compliance stack.

The mail vendor needs to sign a Business Associate Agreement. The encryption needs to meet TLS 1.2 or higher for transmission and AES-256 or similar for at-rest storage.

Every send and open needs to appear in a retained audit log. Workforce training under the Security Rule needs to cover which channels are approved for PHI.

A single Encrypt button click on Outlook or a lock icon in Gmail satisfies the encryption piece. It does not satisfy the BAA, the audit log, or the training piece by itself.

Gateway services designed for healthcare cover all three technical pieces automatically. Sibling coverage in encrypt an email containing PHI covers the PHI-specific angle.

Encrypting an email through a gateway service

Gateway services encrypt outbound mail at the server, which removes the user decision. The setup is a DNS change rather than a client configuration.

  • Sign up with the vendor and receive an SPF record and DKIM key.
  • Add both records to the DNS zone for the practice domain.
  • Wait for DNS propagation, usually within a few hours.
  • Send a test message and verify it routes through the vendor’s server.
  • Sign the Business Associate Agreement or Data Processing Agreement provided by the vendor.

Once configured, every outbound message from the mailbox routes through the vendor’s gateway. The gateway applies the encryption policy before releasing the message.

End users see no change. Staff continue composing in Gmail or Outlook, and the encryption happens invisibly. Mailhippo is one example of that model.

The HIPAA Journal breakdown of compliant email covers the vendor-selection criteria in more depth.

encrypt an email in article illustration two

Encrypting an email with a PGP browser extension

PGP through a browser extension works on any mail account, including personal Gmail and Outlook.com. It is the strongest end-to-end option and the most flexible for individuals.

Install Mailvelope from the Chrome or Firefox extension store. The extension generates a PGP key pair on first run and stores the private key locally in the browser.

Share the public key with correspondents through a keyserver or a signed message. Both sides need each other’s public keys before encryption works.

Composing in Gmail then shows a Mailvelope button. Clicking it opens a secure editor inside the browser. The message is encrypted locally before being pasted into the Gmail compose window.

The tradeoff is friction. Every recipient needs a PGP client, which excludes patients and most business correspondents. PGP fits technical audiences and individual privacy scenarios rather than mainstream healthcare.

Encrypting attachments separately from the message body

Sometimes only the attachment carries sensitive data. Password-protecting the attachment lets the email travel through any provider.

  • Compress the file with 7-Zip, WinRAR, or Windows built-in compression, and enable AES-256 encryption.
  • Set a strong password of 12 characters or more.
  • Attach the encrypted archive to the email.
  • Share the password over a phone call, SMS, or in-person conversation.

The mail server does not see the file contents, so the file travels through Gmail or Outlook as opaque data. The recipient extracts the archive with the shared password.

This method is not HIPAA compliant on its own because it produces no audit trail and the password channel is often insecure. It fits one-off file transfers between organizations without a shared encryption service.

[mh_protip]

Verifying an outbound message actually went out encrypted

An encrypted send is only useful if the encryption held. Both Gmail and Outlook provide ways to verify.

In Gmail, open the sent message and click the three-dot menu, then Show Original. The header displays the TLS status of the delivering connection.

In Outlook desktop, right-click the message and choose Message Options. The header lines show Received records with TLS version details.

For Purview or S/MIME messages, the sent view shows a lock or shield icon in the header. Clicking the icon shows the encryption policy applied.

If none of those indicators appear, the message either traveled without encryption or fell back to a lower tier than expected. Sibling coverage in what happens when you encrypt an email outlook covers the outbound side.

When to encrypt every message versus specific messages

User-driven encryption depends on the user deciding correctly each time. Compliance frameworks treat that decision as a weakness because a single missed message counts as a violation.

The alternative is policy-based encryption at the gateway. Every outbound message routes through the encryption layer, regardless of whether the user clicked a button.

Policy-based encryption uses rules to decide what to protect. Rules can trigger on keywords, recipient domain, sender department, or data classification labels. The user does not need to know the rule was applied.

For healthcare practices, policy-based encryption on every outbound message is the safer default. It removes the failure mode where a staff member forgets to click Encrypt on a specific message.

The right method for your workflow

Choosing the right method comes down to the mail platform, the compliance requirement, and the recipient list.

Microsoft 365 Business Premium tenants can use the Encrypt button in Outlook. The BAA is in place if the tenant is configured correctly, and the recipient side is handled through the portal.

Google Workspace tenants on Enterprise Plus can use hosted S/MIME. Lower tiers need a gateway service or a browser extension.

Practices on any mail plan needing compliance in a solo or small clinic setting default to a gateway service. The cost is the lowest, the setup is the shortest, and the audit trail is built in.

Practices reviewing email decisions alongside the broader patient outreach can pair the choice with a look at healthcare digital marketing services to align intake, messaging, and encryption under a single vendor stack. For the mailbox itself, Mailhippo secure email service covers the loop end to end.

[mh_faqs]

Posted on

What Does Encrypting an Email Do Behind the Scenes

what does encrypting an email do guide featured image

[mh_key_takeaways]

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.

what does encrypting an email do in article illustration one

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.

[mh_example]

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.

what does encrypting an email do in article illustration two

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.

[mh_protip]

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.

[mh_faqs]

Posted on

How to Send Encrypted Email Across Any Client

how to send encrypted email guide featured image

[mh_key_takeaways]

Every modern mail client can send encrypted email, but the definition of encrypted varies across methods. Some protect only the connection between mail servers. Others protect the message content itself. The difference matters for compliance and for real security.

This guide covers how to send encrypted email across Gmail, Outlook, Apple Mail, and portal-based services. Each method has a specific use case, a specific setup cost, and a specific recipient experience.

The right method depends on the sensitivity of the content and the technical setup of the recipient. Match the tool to the message.

TLS Is the Default Encryption Layer for Every Modern Mail Server

Transport Layer Security, or TLS, protects the connection between two mail servers. When Gmail sends to Outlook, both servers negotiate a TLS handshake and encrypt the traffic in flight. Any observer on the network path sees only ciphertext.

TLS is on by default in Gmail, Outlook, Apple Mail, Yahoo Mail, and every other major provider. Users do not enable it. Administrators do not configure it. It happens automatically when both servers support it.

The problem is fallback. If the receiving server does not support TLS, the sending server delivers the message in plaintext by default. There is no warning. The message reaches the recipient. The sender assumes it was encrypted because their client showed a padlock.

For any content that is regulated, the opportunistic fallback rules out TLS as a standalone protection. You cannot verify that every recipient server supports TLS. According to NIST SP 800-45, verified end-to-end encryption is the required protection for sensitive email.

S/MIME Provides Message-Level Encryption in Outlook and Apple Mail

S/MIME uses X.509 certificates to encrypt the message content itself, not just the transport. Once encrypted, only the recipient with the matching private key can read it. The mail provider stores ciphertext and cannot decrypt.

Outlook supports S/MIME on all Microsoft 365 plans that include the desktop apps. Apple Mail supports S/MIME natively on macOS and iOS. Gmail supports S/MIME on Workspace Enterprise Plus, Education Standard, and Education Plus.

Setup requires a certificate for the sender and a certificate for the recipient. Both must come from a trusted certificate authority. The public key gets attached to signed emails, so correspondents can build up a keyring by receiving signed messages from each other.

S/MIME suits organizations that can deploy certificates across all their staff and partners. It does not suit external correspondents like patients, vendors, or one-off recipients who do not have a certificate installed.

how to send encrypted email in article illustration one

PGP Delivers the Same Protection with a Different Key Model

PGP, or Pretty Good Privacy, is the open-source alternative to S/MIME. It uses a public-private key pair generated locally by the user. The public key is shared. The private key is protected with a passphrase and stays on the sender machine.

Thunderbird includes PGP support by default. Mailvelope adds PGP to Gmail and Outlook Web through a browser extension. GPG Suite adds it to Apple Mail. The GNU Privacy Guard command-line tool underlies most implementations.

PGP does not require a certificate authority. Users trust each other public keys directly, either through personal verification or through a web-of-trust model where mutual acquaintances sign each other keys. This is more flexible than S/MIME but harder for non-technical users to manage.

PGP suits technical teams, security researchers, and correspondents who exchange keys manually. It does not suit a healthcare workflow where a receptionist needs to email a lab result to a patient who has never generated a key pair.

Outlook Encrypt Button Uses Microsoft Purview Message Encryption

Outlook 365 users on Business Premium, E3, E5, and comparable Education plans get an Encrypt button in the Options ribbon of the compose window. Behind the scenes, this triggers Microsoft Purview Message Encryption.

External recipients receive a portal link and sign in with Microsoft, Google, or a one-time passcode. Internal recipients on the same tenant see the message inline in Outlook or Outlook on the web without the portal step.

Setup takes minutes if Azure Rights Management is already enabled on the tenant. For tenants that have not activated it, an administrator must enable Rights Management under the Microsoft 365 Admin Center before the Encrypt button appears in Outlook.

According to Microsoft documentation, Purview Message Encryption meets HIPAA transmission requirements when combined with a signed business associate agreement, available on Microsoft 365 Business plans and higher.

[mh_example]

Portal-Based Services Remove the Recipient Setup Barrier

Portal-based encrypted email services solve the biggest problem with S/MIME and PGP. The recipient does not need to install anything, configure anything, or generate any keys. They receive a notification, click a link, and read the message in a browser.

Mailhippo works as an SMTP relay. The sender continues to write and send from Gmail, Outlook, or any other client. Mailhippo intercepts the message, encrypts it, and delivers over TLS when the recipient server supports it or through a portal link when it does not.

The recipient experience is one click. They receive a notification email, click the link, authenticate with a one-time passcode sent to their phone or email, and read the message in a browser. No account creation. No software.

For HIPAA, the service includes a signed BAA in the base plan and logs every message access. Healthcare organizations use this model because patient recipients cannot be expected to manage keys or install plug-ins.

how to send encrypted email in article illustration two

Comparison Across the Main Methods

Each method has a specific fit. The table below summarizes the practical tradeoffs.

Method End-to-End Recipient Setup HIPAA Ready Best For
TLS No None No, opportunistic fallback Non-sensitive routine mail
S/MIME Yes Certificate install Yes, with BAA Internal certified teams
PGP Yes Key pair generation Yes, with process controls Technical correspondents
Purview Message Encryption Yes Portal or Microsoft login Yes, with M365 BAA Microsoft 365 users
Portal-based service Yes Click and passcode Yes, with BAA in base plan External recipients, patients

The clearest divide is recipient friction. S/MIME and PGP are excellent when both parties are set up. Portal-based services and Purview handle every recipient without setup, which matters for healthcare and any business email compliance workflow.

Gmail Encryption Steps Depend on the Workspace Tier

Personal Gmail supports TLS by default and Confidential Mode as an inbox-level access control. It does not support S/MIME. For encryption beyond TLS, personal Gmail users need a browser plug-in for PGP or a third-party service.

Workspace Business tiers support TLS and Confidential Mode. S/MIME hosted encryption is unavailable at these tiers. Healthcare organizations on Business Standard or Business Plus typically layer a HIPAA-compliant service to close the gap.

Workspace Enterprise Plus, Education Standard, and Education Plus include S/MIME hosted encryption. Administrators enable it in the Admin console under Apps, Google Workspace, Gmail, User settings.

Full step-by-step for the Gmail path is covered in the sibling guide how to send encrypted email in Gmail and the tier-specific instructions in how to send encrypted email using Gmail.

[mh_protip]

Outlook Encryption Steps Depend on the Microsoft 365 Plan

Outlook desktop supports S/MIME on all Microsoft 365 plans that include the desktop apps, provided the user has a certificate installed. The certificate goes into the Windows certificate store or the macOS keychain.

The Encrypt button in the Outlook ribbon requires Microsoft 365 Business Premium or Enterprise E3, E5, or higher. Lower Business tiers do not include Purview Message Encryption. This is the most common gap that surprises small-business owners after a plan upgrade.

For lower Microsoft 365 tiers, the practical path is a portal-based service that adds encryption without requiring the plan upgrade. This suits solo practitioners, small clinics, and small-business teams that need HIPAA-covered email but not the enterprise feature stack.

Verification Steps for Every Sensitive Send

Before sending regulated content, verify the method for that specific send. Do not assume. TLS may have dropped to plaintext. S/MIME may have fallen back because the recipient certificate expired. Purview may have failed to trigger because the tenant setting changed.

  • Check the encryption indicator in the compose window before sending.
  • Confirm the recipient will receive the intended experience by sending a test message with non-sensitive content.
  • For portal-based services, verify the audit log records access after the recipient opens the message.
  • For S/MIME, confirm the padlock or lock icon shows green in the sent copy.

According to HIPAA Journal, the most common documented compliance failure is a sender assuming TLS was in effect when the recipient server had disabled it. Verify per send.

Choose the Method by Recipient and Content

The decision framework is simple. Match the recipient technical setup and the content sensitivity to the encryption method with the lowest friction that still meets the security bar.

  • Internal team, routine content, no regulated data: TLS is sufficient.
  • Internal or partner team with certified users, regulated data: S/MIME or PGP.
  • Microsoft 365 users sending to external recipients: Purview Message Encryption.
  • Any recipient without technical setup, regulated data, HIPAA scope: portal-based service with a BAA.

For healthcare providers coordinating email with website and patient acquisition, encrypted email pairs with HIPAA-compliant website design as part of a broader compliance stack.

The last practical point is that the wrong method causes friction for the recipient, and friction becomes a security risk. Recipients who cannot open an encrypted message will ask for it in plaintext. Pick the method that removes that pressure.

[mh_faqs]

Posted on

Email Encryption Explained (Methods, Standards, and Costs)

email encryption guide featured image

[mh_key_takeaways]

Email encryption sounds like one feature. It is actually a stack of choices about transport, content, keys, licensing, and recipient experience. Getting the stack wrong leaves gaps that compliance auditors find.

This guide covers email encryption methods, the standards that back them, the platforms that implement each one, and the price ranges buyers see. For HIPAA senders who want to skip the license tier upgrade, a dedicated secure email service often removes the portal step and includes a BAA in the base plan.

Read the sections in order. Each layer builds on the one before it.

Transport and Content Encryption Are Different Layers

Two encryption layers cover email. Buyers often confuse them, which leads to gaps.

Transport encryption uses TLS between mail servers. When Gmail sends to Outlook, both servers negotiate TLS 1.2 or 1.3 and the message travels encrypted. Neither user takes any action.

Content encryption protects the message body and attachments themselves. S/MIME, PGP, and hosted portal encryption all fit here. The message remains encrypted at rest in the recipient mailbox until decrypted with a key or portal credential.

TLS alone leaves messages readable at the recipient provider, in server logs, and in backup snapshots. HIPAA and PCI treat that exposure as non-compliant for regulated content. Content encryption fixes it.

Every serious encryption deployment uses both layers together.

email encryption in article illustration one

S/MIME Is the Enterprise Standard for Content Encryption

S/MIME encrypts message bodies using X.509 certificates issued by a certificate authority. It is the default choice for organizations with dedicated IT.

Outlook, Apple Mail, and Google Workspace Enterprise Plus all support S/MIME natively. No plugin required. The mail client handles encryption and decryption behind the compose window.

Setup requires purchasing a personal certificate from a public CA like DigiCert, Sectigo, or GlobalSign, installing it in the local certificate store, and exchanging signed messages with each recipient to share public keys.

Certificates typically expire after twelve months. Renewal happens through the CA portal. Expired certificates block new encrypted sends until reissued.

Related guide: S/MIME email encryption covers the certificate model in detail.

OpenPGP Serves Technical and Journalism Communities

OpenPGP is the alternative content encryption standard. It uses locally generated key pairs instead of CA-issued certificates.

Users install GPG Suite on macOS, Gpg4win on Windows, or Mailvelope in the browser. The tool generates a key pair with a passphrase. The user shares the public key with recipients through a keyserver or direct email.

Trust builds through key signing rather than a central authority. Security researchers, journalists, and open source maintainers use PGP heavily because it does not depend on any CA infrastructure.

Business adoption of PGP stays limited. Recipients cannot install extensions on locked-down corporate systems. Healthcare and financial senders skip PGP for that reason.

The technical strength of PGP is not the barrier. The recipient-side friction is.

[mh_example]

Hosted Encryption Services Handle the Recipient Portal

Hosted encryption trades certificate management for a portal step at the recipient end. Microsoft Purview Message Encryption, Google Workspace Confidential Mode, and many third-party vendors follow this pattern.

The sender clicks Encrypt in the mail client. The service routes the message body to its own storage and sends the recipient a notification email with a link. The recipient signs in with an existing account or enters a one-time passcode to read the message.

Vendor gateways from Fortinet, Cisco, Trustifi, Datamotion, and others all follow the same portal pattern with different admin interfaces and reporting.

The recipient friction depends on the vendor. Some services allow one-click reading through a signed URL. Others require full account creation. Test each with a real recipient before committing.

Related guide: email encryption service compares vendor options in depth.

email encryption in article illustration two

Encryption Techniques and Algorithms in Use Today

The math behind email encryption uses proven algorithms defined in published standards.

  • AES-256 handles symmetric encryption of the message body itself. It appears in every current standard.
  • RSA-2048 or elliptic curve algorithms handle the key exchange that carries the symmetric key to the recipient.
  • SHA-256 or SHA-384 handles integrity hashing so recipients can detect tampering.
  • TLS 1.2 with strong cipher suites, or TLS 1.3 without weak fallback, handles transport between servers.
  • Message authentication codes bind sender identity to the message so recipients can verify origin.

Buyers rarely choose algorithms directly. Every modern platform defaults to combinations aligned with NIST guidance. See the NIST cryptographic guidance publications for the current recommended parameters.

Platform-by-Platform Encryption Options

Each mail platform ships different encryption features at different price tiers.

Microsoft 365 Business Premium and higher include Purview Message Encryption behind the Encrypt button. Business Basic and Business Standard do not.

Google Workspace Enterprise Plus and Education Plus include hosted S/MIME. Business Standard and Business Plus include Confidential Mode but not hosted S/MIME.

Apple Mail supports S/MIME natively on macOS and iOS provided the user installs a certificate through Keychain or MDM configuration profile.

Yahoo, AOL, and older ISP webmail platforms do not offer S/MIME or hosted encryption. Users on those platforms rely on TLS transport plus optional PGP through browser extensions.

Match the plan tier to the required feature before rolling out an encryption program.

[mh_protip]

HIPAA Compliance Requires More Than Encryption

Encryption satisfies one HIPAA Security Rule addressable specification. Full compliance requires several additional safeguards.

The covered entity signs a business associate agreement with the email provider. Microsoft and Google both offer BAAs on eligible plans. The HHS Security Rule guidance lists every safeguard.

Administrative safeguards include workforce training on PHI handling, sanction policies for violations, and periodic risk assessments. Physical safeguards include facility access controls on the workstations that send email.

Technical safeguards beyond encryption include unique user identification, automatic logoff on idle sessions, and audit controls that record message access.

Practices that clip on encryption software without addressing the surrounding safeguards are not compliant. Encryption is one piece of a larger program.

Cost Comparison Across Encryption Approaches

Price often decides the buying question more than features. A ten-person practice compares real annual numbers.

Approach Per user per month Annual cost (10 users)
Microsoft 365 Business Premium (Purview) 22 USD 2,640 USD
Google Workspace Enterprise Plus (hosted S/MIME) 30 USD 3,600 USD
Public CA S/MIME certificates (annual) 2 to 5 USD (amortized) 240 to 600 USD plus mail plan
Dedicated encrypted email service with BAA 5 to 15 USD 600 to 1,800 USD

Numbers exclude staff training, audit review time, and the recipient-side support calls that portal-based encryption generates. Practices measuring hidden costs often find dedicated services cheaper end to end.

How to Choose the Right Encryption Approach

The decision comes down to three questions about the sending organization.

First, does the organization already run Microsoft 365 Business Premium or Google Workspace Enterprise Plus? If yes, native S/MIME or Purview cover the encryption need with no additional software.

Second, does the recipient list change frequently, as with a healthcare practice adding new patients weekly? If yes, hosted encryption or a dedicated service avoids the S/MIME public-key exchange step.

Third, is the recipient experience business-critical? If patients or referring physicians will abandon messages that require a portal sign-in, a dedicated service like Mailhippo delivers encrypted email that opens in one click without a portal.

Practices running healthcare marketing sites pair encrypted email with a compliant patient-facing web presence. See healthcare website security features for the site-side controls.

Related guides: email encryption software, secure email encryption service, and encryption for email techniques.

[mh_faqs]

Posted on

Encrypted Email Guide for Business and HIPAA Workflows

encrypted email guide featured image

[mh_key_takeaways]

Encrypted email protects message content from anyone who is not the intended recipient. The term covers three separate technical layers, and they solve different problems. Getting the layer right is what separates a defensible deployment from a false sense of security.

This guide walks through each layer, the tools that implement it, and where each one fits a business or healthcare workflow. It closes with a practical view on when to combine layers and when a portal-based encrypted email service is the right choice.

The reader should come out with enough context to decide which encryption model matches the recipients they email most often and what the budget implications are.

Encrypted Email Covers Three Distinct Layers

The first layer is TLS in transit. It encrypts the network connection between two mail servers. The message body travels through a tunnel that a passive network snoop cannot read.

The second layer is end-to-end encryption at the message level. S/MIME and PGP encrypt the body with the recipient public key. The mail server sees only ciphertext.

The third layer is portal-based delivery. The sender uploads the message to a hosted portal. The recipient authenticates and reads it in a browser. The mail itself never leaves the portal.

Each layer defends against a different threat. TLS covers passive interception. End-to-end covers a compromised or subpoenaed provider. Portal covers recipients who cannot install client-side keys.

TLS Is the Baseline for All Modern Mail Providers

Gmail, Outlook, iCloud, and most business mail providers negotiate TLS 1.2 or 1.3 by default. The two servers exchange certificates, agree on a cipher, and encrypt the connection.

TLS ends when the message arrives at the recipient server. The mail sits at rest on that server in a form the provider can decrypt. A subpoena, a rogue admin, or a provider compromise exposes plaintext.

TLS also fails when the receiving server does not support it. Older on-premise Exchange systems still exist in the wild. Google publishes a delivery status for each domain the user emails, which can reveal these gaps.

MTA-STS and DANE are add-ons that force TLS on the sending side. NIST covers the technical baseline in Special Publication 800-177 Trustworthy Email. Every modern deployment should have MTA-STS enabled at a minimum.

encrypted email in article illustration one

End-to-End Encryption Uses Keys the Provider Cannot See

S/MIME and PGP are the two dominant end-to-end standards. Both work by encrypting the message body with the recipient public key on the sender client before the message leaves the device.

S/MIME uses X.509 certificates from a certificate authority. It is native in Outlook, Apple Mail, and Google Workspace Enterprise. Setup requires a certificate for each user.

PGP uses a web of trust model where users sign each other public keys. It runs on plugins in most mail clients. Setup requires a keypair and public key exchange with every contact.

Both models fail when the recipient has no client-side setup. A referring physician on personal Gmail without S/MIME cannot receive an S/MIME encrypted message. Related linked topic: should I consider encrypted email using ProtonMail as one example.

Portal-Based Encrypted Email Works With Any Recipient

Portal delivery is the practical choice when recipients are variable, include patients, or refuse to install certificates. The sender writes the message in a normal mail client or a web portal.

The service uploads the message to a hosted portal. The recipient receives a notification with a link. They click the link, authenticate with a passcode or SSO, and read the message in a browser.

Microsoft Purview Message Encryption uses this model. Google Workspace confidential mode uses a similar model. Third-party services like Mailhippo use the same model with a HIPAA-focused BAA in the base plan.

Portal delivery works with any recipient on any device. The tradeoff is friction. Replies happen in the portal, not the recipient normal inbox. Threading breaks for downstream record keeping.

[mh_example]

HIPAA Requires More Than Encryption Alone

HIPAA compliance for email requires three things. A signed Business Associate Agreement with the mail provider. Technical safeguards under the Security Rule. Workforce training on encryption use.

Encryption is one technical safeguard. Access controls, audit logging, session timeouts, and secure key management are others. The HHS Security Rule spells out the full list.

A signed BAA is what makes the mail provider a business associate under 45 CFR 164.502(e). Without it, sending PHI through any encrypted service is still a HIPAA violation regardless of encryption strength.

Gmail on Google Workspace Business Standard and above and Outlook on Microsoft 365 Business Standard and above both offer BAAs. Free personal accounts do not. See related healthcare security context for how email fits inside the broader stack.

encrypted email in article illustration two

Common Encrypted Email Deployment Patterns

Small practices with a single mail provider usually run TLS plus a portal gateway. This covers passive interception and external recipient delivery in one setup.

Mid-size clinics with a stable set of peer providers add S/MIME on top for the peer traffic. TLS is baseline, S/MIME handles peer clinical mail, portal handles patients and one-off external contacts.

Larger hospitals with internal PKI use S/MIME across the entire clinical workforce. They still add a portal for patient communication. The two models coexist and are chosen per recipient by the mail client or by a policy rule.

Common encrypted email deployment components include:

  • TLS baseline with MTA-STS enforced on outbound
  • SPF, DKIM, and DMARC configured on the sending domain
  • S/MIME certificates issued to clinical users for peer traffic
  • Portal service for patient and external recipient traffic
  • DLP rules that auto-encrypt messages containing SSN, MRN, or PHI patterns
  • Audit logs retained per HIPAA six-year requirement

Free Encrypted Email Options and Their Limits

Free encrypted email exists but comes with real limits. Personal ProtonMail and Tutanota accounts offer zero-access encryption at rest and portal-based delivery for external recipients.

The catch is no BAA. Free tiers do not qualify for HIPAA use regardless of encryption strength. Storage caps and daily message limits also fail business use quickly.

Free personal S/MIME certificates from Actalis and similar issuers give real end-to-end encryption but require manual install and renewal. Time cost is often higher than a paid service.

For a solo user with occasional secure needs, free options are workable. For a practice with regulatory obligations, paid tiers with BAAs are the only defensible path. Related: free encrypted email for a fuller comparison.

[mh_protip]

Encrypted Email Feature Comparison

The table below compares the main encrypted email models on the dimensions that matter most for a business buyer.

Model Encryption Level Recipient Setup HIPAA Fit Best For
TLS only Transit None Baseline only General business mail
S/MIME End-to-end Certificate install Peer traffic Clinic-to-clinic
PGP End-to-end Keyring install Rare in healthcare Technical users
Portal gateway End-to-end at rest Passcode or SSO All recipients Patient and external mail
Zero-access mailbox End-to-end at rest Account creation With BAA on paid tier Privacy-focused solo users

Encrypted Email Troubleshooting Basics

Delivery failures are the most common encrypted email problem. TLS failures show up as messages sitting in the outbound queue or arriving in plain form when the receiving server does not support TLS.

S/MIME failures usually trace to certificate expiration, address mismatch, or a missing intermediate CA. The recipient client shows a specific error that names the failing check.

Portal delivery failures often trace to the recipient marking the notification as spam. Adding the sender portal domain to a safe-sender list at the recipient side fixes this. See related linked topic: how to troubleshoot encrypted email.

Deliverability upstream matters too. A domain without SPF, DKIM, and DMARC lands portal notifications in spam even when the portal itself works. The Gmail sender guidelines apply to portal notification email the same way they apply to normal outbound mail.

Choosing an Encrypted Email Setup for Your Practice

The right choice depends on three questions. Who are you emailing most often. Are they technical enough to hold a certificate. Do you already run on Microsoft 365 or Google Workspace.

For a practice that emails patients daily and peer clinics occasionally, a portal gateway is the higher-value setup. Patients never install anything. Peer clinics can still receive the portal notification and open it in a browser.

For a practice that emails peer clinics daily and rarely emails patients, S/MIME across the peer network with a portal fallback for patients is the higher-value setup. Peer traffic runs at inbox speed with no extra clicks.

Mailhippo operates as a portal gateway on top of Gmail or Outlook, includes a BAA in the base plan, and requires no per-user certificate management. It fits practices that need patient-safe encryption without moving off their existing mail provider. Practices building a compliant public site alongside their email strategy can pair this with healthcare marketing support so intake, contact, and email flows stay inside the same compliance boundary.

[mh_faqs]

2637 E. Atlantic Blvd.
#1063 Pompano Beach, FL 33062

© 2026 MailHippo, Inc.

View our Privacy Policy or contact our Customer Service team.

Optometrist Marketing Agency – Web Design, SEO, PPC & Maintenance