HorizLogoSm.fw_.png
Start Trial

Tag: gmail

Posted on

What It Means to Encrypt an Email in Plain Terms

what does it mean to encrypt an email guide featured image

[mh_key_takeaways]

To encrypt an email is to convert the message body and attachments into ciphertext before sending. The mail servers in between see only scrambled data. Only a recipient with the correct key or credential can read the content.

This guide explains what encryption means in practical terms, how an encrypted email looks to sender and recipient, and when a dedicated encrypted email service fits better than the built-in options in Outlook or Gmail.

The details vary by platform. The underlying protection is the same. Content is unreadable to anyone without the correct decryption key or authentication credential.

Encryption Converts Message Content Into Ciphertext

Encryption applies a mathematical algorithm to the message body and attachments. The algorithm uses a key to scramble the content into ciphertext. Only a matching key or credential can reverse the process and produce readable content.

The sender does not see the ciphertext. The compose window looks the same as a normal message. The encryption applies at send time, either automatically based on a policy or manually by clicking an Encrypt option.

The recipient does not see the ciphertext either. The mail client or portal decrypts before display. What both parties see is a normal-looking message with a lock icon or policy label that confirms encryption was applied.

The ciphertext exists on the wire between servers and at rest on the sending platform. Anyone who intercepts the traffic or gains access to the storage sees only scrambled data.

Three Layers of Encryption Cover Different Threats

Email encryption applies at three possible layers. Transport encryption between mail servers uses TLS. Message-level encryption uses S/MIME or PGP. Portal-based encryption stores encrypted messages on a server and delivers a link to the recipient.

TLS protects the message during network transmission. It does not protect the message at rest on the sending or receiving mail server. TLS is the baseline, not the full solution for regulated content.

Message-level encryption protects the content from the sender client to the recipient client. Servers in between see ciphertext. This is true end-to-end encryption and it fits scenarios where both parties can hold cryptographic keys.

Portal-based encryption sits between the two. The sending platform holds the encrypted content and manages authentication. The recipient reads the message in a browser session after signing in or entering a one-time passcode.

what does it mean to encrypt an email in article illustration one

The Sender View Looks Almost Identical to Regular Mail

The sender view of an encrypted email is nearly the same as a normal email. The compose window uses the same fields, the same formatting, and the same attachment controls. The one difference is a lock icon or a policy label on the message.

In Outlook, the sender clicks Options, then Encrypt, and picks a policy. In Gmail on Workspace with client-side encryption, the sender clicks a lock icon in the compose bar. In a HIPAA email service, the sender either clicks a Send Secure button or the encryption applies automatically to every outbound message.

The Send button behaves the same way. The message enters the outbound queue. The encryption applies before or during the send. The sender does not see any technical change.

The Sent folder shows the encrypted message under its subject line, the same as any other sent message. The sender can preview the content because the sender is a party to the encryption.

The Recipient View Depends on Platform and Method

The recipient view varies. Internal recipients on the same mail platform typically see the message inline. External recipients on other platforms follow a different path depending on the encryption method.

A Purview-encrypted message to a Gmail recipient arrives as a notification email with a Read the message button. The button opens outlook.office365.com in a browser. The recipient signs in with a Microsoft or Google account or requests a one-time passcode.

An S/MIME message decrypts inside the recipient mail client if the client has the correct certificate. Otherwise the recipient sees an unreadable attachment. This is why S/MIME works well for internal or business partner scenarios and poorly for patient communication.

A HIPAA email service typically shows the recipient a branded notification with a Read Message button. The button opens a portal where the recipient reads the decrypted content. Some services deliver the message directly to the recipient inbox if the recipient is on a compatible platform.

[mh_example]

Unencrypted Email Exposes Content to Anyone on the Path

An unencrypted email travels as plain text or under opportunistic TLS only. Opportunistic TLS drops back to cleartext if the receiving server does not support TLS. Any mail relay along the path can read the content.

The mail servers at each end store the message in cleartext. A breach of a mail server exposes the content of every stored message. Backups of mail servers also carry the cleartext content.

For casual content this is often acceptable. Personal mail, meeting confirmations, and general business correspondence typically travel unencrypted. The exposure risk is low relative to the content sensitivity.

For regulated content, the exposure changes the calculus. PHI, financial records, legal work product, and trade secrets in unencrypted mail create compliance exposure under HIPAA, GLBA, HITECH, and similar frameworks. The HHS Security Rule treats encryption as an addressable specification for transmission and at-rest storage.

Encryption Methods Compared at a Glance

The four common methods differ in setup complexity, recipient experience, and threat coverage. The table below summarizes the trade-offs.

Method Setup Complexity Recipient Experience Fits Best For
TLS Low, on by default No change Baseline transit protection
S/MIME High, needs certificates Automatic in-client decrypt Internal and B2B mail
Microsoft Purview Medium, needs license Portal sign-in or passcode Outlook tenants on Business Premium
HIPAA Email Service Low, gateway configured One-click portal Patient and PHI communication

The right choice depends on the recipient environment, the license already in place, and the compliance requirements. Practices sending to patients almost always want the one-click portal experience because patient tech literacy varies.

what does it mean to encrypt an email in article illustration two

Encrypting an Email in Outlook Uses Microsoft Purview

In Outlook on Microsoft 365 Business Premium and higher, encrypting an email means clicking Options, then Encrypt, in the compose ribbon of a new message. Two policies are available: Encrypt-Only and Do Not Forward.

Encrypt-Only encrypts the content and lets the recipient reply, forward, and print. Do Not Forward encrypts the content and blocks forward, print, and download. The sender picks the policy at send time.

Microsoft Purview handles the delivery. Internal Microsoft 365 recipients see the message inline. External recipients receive a notification with a Read the message button that opens a browser portal for decryption.

The detailed sender steps are in the Microsoft support guide for encrypted messages in Outlook. Tenants on Business Basic or Business Standard do not have the button and need a license upgrade or a separate service.

Encrypting an Email in Gmail Depends on Workspace Plan

Gmail encryption depends on the Workspace plan. Enterprise Plus and Education Plus support client-side encryption. Other plans support confidential mode, which is not the same thing.

Client-side encryption encrypts the message content in the browser before it reaches Google servers. The keys stay with the customer through an external key service. Google cannot decrypt the message.

Confidential mode sets an expiration and disables forward, copy, print, and download. It does not encrypt the message body in a way that meets HIPAA transmission requirements. Google can still access the content.

Standard Workspace plans that need encryption for HIPAA use a HIPAA email service that routes outbound mail through a gateway. The Gmail interface stays the same. Encryption applies at the service layer.

[mh_protip]

Encryption Is One Layer of HIPAA Compliance

Sending an encrypted email is not the same as being HIPAA-compliant. The Security Rule requires administrative, physical, and technical safeguards. Encryption covers part of the technical safeguards.

The covered entity also needs a signed business associate agreement with the email provider, access logs on message activity, workforce training on when to encrypt, and a documented incident response plan.

Common gaps in the compliance picture include:

  • Sending encrypted mail without a signed BAA in place with the provider.
  • Encrypting outbound mail but leaving stored copies unencrypted at rest.
  • Missing workforce training that leaves staff unsure of when to encrypt.
  • No incident response plan for a mail account compromise scenario.
  • No access logs on message activity for audit review.

Each of these gaps is a real audit finding, not a theoretical concern. Practices building out the wider security posture around encrypted mail also need to cover the website, patient portal, and intake forms. See the guide on healthcare website security features for the site-side controls that pair with encrypted email.

When a HIPAA Email Service Simplifies the Encryption Decision

A dedicated HIPAA email service handles the encryption, the BAA, the access logs, and the recipient portal in a single plan. The sender writes mail in a familiar Gmail or Outlook interface. Outbound mail routes through the service gateway.

Mailhippo is one option in this category. It works with existing Gmail and Outlook accounts. The BAA is included in the base plan. Encryption applies to every outbound message. Recipients open messages with one click and no account creation.

The secure email service approach fits practices that need HIPAA compliance without adding license overhead or IT complexity. The trade-off is a routing dependency on the service.

Related reading covers what encrypted mail actually looks like and how it behaves in specific tools: what does encrypt an email mean, what does encrypting an email do, what happens when you encrypt an email outlook, what is an encrypted email mean, what does an encrypted email look like, and encrypt an email.

The Practical Decision Comes Down to Three Questions

The practical decision on how to encrypt an email comes down to three questions. Who is the recipient. What license is already in place. What compliance framework applies.

If the recipient is another employee or a business partner with technical staff, S/MIME or Purview inline delivery works well. If the recipient is a patient or a member of the public, a portal experience with one-click access is the realistic path.

If the license is Microsoft 365 Business Premium or higher, Purview is the built-in option. If the license is a lower Business plan or a Workspace plan without Enterprise Plus, a HIPAA email service fills the gap without an upgrade.

If HIPAA applies, the choice must include a BAA with the provider handling encryption. A dedicated HIPAA email service handles the BAA by default. The wider healthcare digital footprint, including site and portal, can be coordinated by a healthcare marketing agency that pairs the compliance stack with the marketing stack.

[mh_faqs]

Posted on

HIPAA Compliant Email in Gmail (What Actually Qualifies)

hipaa compliant email gmail guide featured image

[mh_key_takeaways]

Gmail dominates business email, and it dominates small healthcare practice email too. The question is where the line sits between everyday Gmail and HIPAA compliant email Gmail.

The short answer is that personal gmail.com accounts cannot be made compliant. Google Workspace on a paid plan can, with the right configuration and a signed business associate agreement. For senders who want a simpler path, a HIPAA-compliant email service layered over Gmail handles the encryption and the BAA in one step.

This guide walks through the license tiers, the covered services, the encryption options, and the practical setup steps for practices that want to keep Gmail as their day-to-day inbox while meeting the Security Rule.

Personal Gmail cannot carry PHI regardless of encryption

A personal gmail.com address is a consumer account. Google does not sign business associate agreements for consumer accounts, and HIPAA requires a BAA with every business associate that handles protected health information.

Encryption alone does not solve this. A sender who encrypts a message with a third-party tool but sends it from a gmail.com account is still transmitting PHI through a provider that has not agreed to safeguard it.

The Office for Civil Rights has fined practices for exactly this pattern. Small practitioners often assume that adding a padlock icon is enough. The Security Rule looks at both the transmission and the entity handling the transmission.

The compliant path is to move to Google Workspace on a paid plan with the practice’s own domain. That switches the account from a consumer service to a business service that Google will cover under a BAA.

Google Workspace signs a BAA for covered services

Google Workspace administrators can accept a BAA in the Admin console under Account, Legal and compliance. The acceptance is a two-click process for a super administrator.

The agreement covers a defined list of Google services, including Gmail, Calendar, Drive, Meet, Docs, Sheets, Chat, Vault, Keep, Sites, Forms, Slides, and Tasks. Not every Google product is covered.

Non-covered services include Google Groups, third-party marketplace apps, and any Google service the admin has not explicitly enabled for the covered set. Users who share a patient chart in Groups are outside the BAA.

The BAA takes effect at the moment of acceptance and applies to future activity. Past activity is not retroactively covered, so practices should sign the BAA before any staff account touches a patient message.

hipaa compliant email gmail in article illustration one

Encryption in Google Workspace uses TLS and server-side keys

Google Workspace encrypts stored messages at rest with keys Google manages. That protects the mailbox from physical disk theft or unauthorized access to Google infrastructure.

Transport uses TLS 1.2 or higher when the receiving server supports it. Google publishes real-time transparency numbers showing about 95 percent of Gmail traffic uses TLS in both directions.

The 5 percent gap is not random. It reflects small receiving servers, misconfigured domains, and systems that do not support current TLS versions. For a receiving practice on a legacy server, the message may still deliver over plain SMTP.

Enforcing TLS on outbound is a partial fix. Administrators can require TLS to specific recipient domains through the Admin console, but that only works if the receiving side supports it. Otherwise the message bounces.

Native S/MIME requires Enterprise Plus

Google Workspace supports hosted S/MIME on Enterprise Plus, Education Standard, and Education Plus. Business Starter, Standard, and Plus do not include native S/MIME.

Setup requires uploading an S/MIME certificate for each user through the Admin console and configuring the incoming and outgoing S/MIME settings. Certificates come from a certificate authority and typically renew annually.

To send an encrypted message to an external recipient, the sender needs the recipient’s public certificate. That is the friction point. Getting a public certificate from a patient is not a workflow that scales.

For that reason, most practices skip native S/MIME even on plans that support it, and they use a third-party gateway that handles the certificate problem through a portal instead.

[mh_example]

Virtru is a common third-party option for Gmail

Virtru offers a browser extension that adds an encryption toggle to the Gmail compose window. When the toggle is on, the message body and attachments are encrypted before they leave the browser.

External recipients receive a link, open the message in a Virtru portal, and authenticate with a Google or Microsoft account, or with a one-time passcode. The sender can revoke access or set an expiration.

Virtru signs a BAA with covered entities. Pricing is per-user per-month and scales with the size of the practice. Deployment requires the admin to allow the extension through the Chrome policy or install it manually per user.

The trade-off with any browser-based extension is that it depends on the user remembering to toggle the encryption on. A message sent without the toggle goes out in the clear.

hipaa compliant email gmail in article illustration two

Cisco Secure Email Encryption Service works for larger systems

Cisco Secure Email Encryption Service, previously Cisco Registered Envelope Service, is a portal-based product Cisco offers to enterprises. It integrates with the Cisco email security appliance and cloud email security offerings.

Recipients receive an encrypted envelope, click a link, and open the message in a Cisco-hosted portal after authenticating. The sender can require additional verification and can pull the message back after delivery.

Cisco will sign a BAA with covered entities. The service is more common in large hospital systems that already run Cisco email security infrastructure than in solo practices or small groups.

For a small practice on Google Workspace, Cisco is usually more infrastructure than the workflow needs. A smaller gateway or a browser extension delivers the same compliance result with less operational overhead. Practices comparing options often review the broader hipaa compliant email cisco landscape before choosing.

Hosted HIPAA email services layer over Gmail without a plan upgrade

A hosted HIPAA compliant email service handles the encryption, the portal, and the BAA on top of the existing Gmail account. The practice does not need to upgrade to Enterprise Plus or manage S/MIME certificates.

Providers in this category include Mailhippo, Paubox, LuxSci, and Hushmail. Each connects to a Gmail account through OAuth or SMTP relay and encrypts outbound messages before they leave the sender’s device or the relay.

The recipient experience varies. Some services deliver a portal link. Others encrypt via TLS enforcement and pass the message through with no visible portal for recipients whose provider supports it.

Mailhippo takes the middle path. Messages to compliant receiving servers deliver directly, and messages to non-compliant destinations fall back to a portal. That preserves the recipient’s inbox experience wherever the destination server can handle encrypted delivery.

[mh_protip]

Admin console settings that harden a Workspace tenant

Two-step verification should be enforced for every user on the tenant. Enforcement, not just enablement, is the setting that blocks a login without a second factor.

Legacy protocols like POP and IMAP should be disabled for accounts that do not need them. Every enabled legacy protocol is a potential authentication path that bypasses two-step verification.

Data Loss Prevention rules can inspect outbound mail for content patterns like Social Security numbers, credit card numbers, or clinical terms, and either block, warn, or redirect the message. DLP is included on Business Standard and higher.

The Google Workspace HIPAA compliance guide lists the specific settings Google recommends for covered entities. Working through the guide once and documenting the state of each setting is the closest thing to a self-audit for a small practice.

Common breach patterns in Gmail-based practices

Autocomplete misfires cause a large share of email breaches. A clinician types the first two letters of a patient’s name, Gmail suggests the wrong contact, and the message goes to the wrong person.

Forwarded threads are the second common pattern. A patient message gets forwarded to a colleague for consultation, then forwarded again to a family member, and the chain leaves the covered environment somewhere along the way.

Attachment mistakes come next. Staff attach the wrong PDF, or attach the correct PDF to the wrong thread. Google’s undo send window is 30 seconds at most and does not recover a message the recipient has already opened.

The HHS breach portal lists dozens of email incidents per year in the small provider category, and the pattern is consistent. Compliance-grade sending is a combination of platform, encryption, and process, and process is often the weakest link.

What to configure this week if you are on Gmail today

If the practice is on personal Gmail, the immediate step is to purchase a Google Workspace Business Standard plan or higher and migrate the account to the practice’s own domain. Business Basic does not include the security controls needed.

Sign the BAA in the Admin console, enforce two-step verification, disable legacy protocols, and confirm the covered services list matches what staff use for patient communication.

Install a third-party encryption extension or connect a hosted HIPAA email service. Test a message to a personal address on a provider that does not enforce TLS, and confirm the message arrives as a portal link rather than plaintext.

For practices that also need a compliant patient-facing website, forms, and marketing setup around the email service, working with an agency that focuses on HIPAA-compliant website design and the broader healthcare website conversion optimization workflow keeps the email, the intake, and the marketing on the same compliance footing.

  • Sign the Google Workspace BAA in the Admin console.
  • Enforce two-step verification for every user account.
  • Disable POP and IMAP unless a specific workflow requires them.
  • Install a hosted HIPAA email service or S/MIME certificates on Enterprise Plus.
  • Document the covered services list and confirm staff use only those services for PHI.

Setting up hipaa compliant email gmail is a paid Google Workspace plan, a signed BAA, an encryption path for external mail, and staff training. Miss any of those pieces and the account is not compliant no matter how the software looks from the outside.

[mh_faqs]

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

Zix Email Encryption Explained for Healthcare and Compliance Teams

zix email encryption guide featured image

[mh_key_takeaways]

Zix email encryption is a policy-driven secure email gateway used across regulated industries to enforce HIPAA, GLBA, and PCI email rules. The gateway scans every outbound message, applies encryption when a rule matches, and routes the recipient into a secure portal when the receiving server cannot accept TLS.

Healthcare practices adopt Zix for the same reason they adopt other encrypted email platforms. The gateway removes the burden of asking every staff member to remember when to encrypt. Content classification runs on the server, not in the mail client.

The tradeoff is complexity. Policy tuning, directory synchronization, and gateway routing require IT time that smaller practices often do not have. This guide covers how Zix works, what it costs, and where simpler options fit.

Zix Runs as a Gateway Between the Mail Server and the Internet

The Zix architecture places a gateway between the outbound mail server and the internet. Every message the mail server sends passes through the gateway before it reaches the receiving mail server. The gateway inspects the message, classifies the content, and applies the routing decision.

For Google Workspace, administrators configure the outbound gateway in the Gmail routing settings and point outbound mail at the Zix hostname. For Microsoft 365, administrators create an outbound connector in the Exchange Admin Center. The gateway sits in the delivery path without changing the sender client.

The inspection step matters. Zix reads the message subject, body, headers, and attachments. It matches the content against a library of built-in patterns for PHI, financial account numbers, and other regulated fields. Matched messages get encrypted. Non-matched messages route normally.

The gateway model works well for organizations with a dedicated IT team, consistent mail platform, and a compliance officer who owns policy tuning. Smaller practices often find the model heavier than the actual send volume justifies.

Policy Rules Drive the Encryption Decision

Zix ships with a policy library covering HIPAA, HITECH, GLBA, PCI DSS, and state privacy rules. Each policy contains a set of pattern matches, keyword lists, and structural checks. Administrators can enable full policies out of the box or customize them for the practice.

A HIPAA policy typically flags nine-digit numbers formatted as social security numbers, medical record numbers, ICD-10 codes, and combinations of patient identifier plus clinical information. The gateway can also flag messages sent to known covered entity domains or to any address that matches a directory of business associates.

When a message matches a policy, the gateway encrypts and delivers based on the routing rule. The sender does not need to click an Encrypt button. The compliance officer does not need to train the entire staff on when to encrypt. The gateway handles the decision.

The tradeoff is policy accuracy. False positives encrypt messages that do not require it. False negatives release regulated content in plaintext. Policy tuning is an ongoing activity, not a one-time setup. The HHS HIPAA Security Rule lists the transmission security requirements that policy design should map back to.

zix email encryption in article illustration one

Delivery Uses TLS First and Portal Fallback When Needed

Zix delivery follows a two-path model. The first path uses TLS when the receiving mail server supports it and passes Zix directory verification. In that case, the encrypted message decrypts at the gateway boundary and arrives in the recipient inbox as a normal email.

The second path routes to the Zix portal. The gateway sends the recipient a notification email with a link. The recipient clicks the link, signs in with a password, and reads the message inside the browser. First-time recipients set a password. Repeat recipients reuse the account.

Zix directory verification uses a network of known Zix-enabled organizations that can accept encrypted messages directly. If both parties run Zix, the message decrypts on delivery without the portal step. This is the Zix-to-Zix delivery model that reduces friction between practices already on the platform.

The portal fallback is the workhorse for messages sent to patients, external providers, and vendors not on the Zix network. It ensures every regulated message reaches the recipient over an encrypted channel, without depending on the receiving server TLS configuration.

Sender Experience Stays Inside Gmail or Outlook

Zix does not require a separate compose window or a browser plugin. The sender uses the native Gmail or Outlook interface. They write the message, add attachments, and click Send. The gateway takes over from there.

For senders who want to manually flag a message as encrypted regardless of policy, Zix supports a subject line keyword such as [Secure] that forces encryption on that specific message. The keyword is configurable. Administrators can also add an Outlook button through a template deployment.

Sent items appear in the sender Sent folder as normal messages. The sender can view the encrypted status in the message tracking report on the Zix administrative console. Recipients who need a resent link contact the sender, who initiates a resend from the console.

This is the main sender-side advantage. Encryption becomes an infrastructure function rather than a per-message decision. The sender does not have to remember to encrypt because the gateway makes the decision on their behalf.

[mh_example]

Recipient Experience Depends on the Receiving Server

Recipients see one of three experiences based on their mail environment. The first is a plain email in the inbox, delivered over TLS with no portal step. This happens when the receiving server supports TLS and passes Zix directory checks.

The second is the portal experience. The recipient receives a notification email with a link. They click, sign in, and read the message in the Zix web portal. Attachments download inside the portal. Reply from the portal encrypts the reply automatically.

The third is the Zix-to-Zix direct delivery, where both organizations run Zix and messages flow encrypted end to end without a portal step. This is the highest-friction-reduction path but requires both sides on the same platform.

The portal experience adds a step for external recipients. That step is a source of friction for elderly patients, low-technology recipients, and one-off external contacts. The friction is worth it for regulated content, but it should be measured against portal-based services designed for lighter-touch recipient handoffs.

Pricing Reflects Enterprise Feature Set Rather Than Practice Size

Zix does not publish list pricing. Practices request a quote based on seat count, plan level, and add-on modules. Reported public pricing from third-party reviews runs from single digits per mailbox per month at the low end into higher tiers for full enterprise bundles.

Add-on modules include archiving with retention controls, data loss prevention with content classification, inbound threat protection with URL rewriting, and encryption gateways for regulated industries beyond HIPAA. Each module adds to the base per-seat cost.

The pricing reflects an enterprise buyer profile. Practices under twenty seats often find the plan structure heavier than the actual send volume of PHI justifies. The seat rate covers features many small practices never use, and the setup time cuts into practical value.

Buyers should compare quoted Zix pricing against portal-based services that include the BAA and encryption in a base per-seat rate without a gateway deployment. The healthcare website security features guide covers additional layers that combine with encrypted email for a full compliance stack.

zix email encryption in article illustration two

Setup Requires Directory Sync and Policy Tuning

Zix deployment starts with directory synchronization. The gateway needs to know which users belong to the practice, which addresses are external, and which domains belong to known covered entities or business associates. Administrators sync Active Directory or Google Workspace into the Zix console.

The next step is outbound routing. For Microsoft 365, this means an outbound connector pointing at the Zix hostname. For Google Workspace, this means an outbound gateway rule in Gmail routing. Every outbound message routes through the gateway from this point forward.

Policy tuning is the third step and typically the longest. The compliance officer or IT lead reviews the default HIPAA policy, adjusts the pattern matches for the specific practice, and monitors the first weeks of traffic for false positives and false negatives. This is an iterative process.

Inbound routing, if used, requires an inbound connector plus an MX record change to point the practice domain at the Zix inbound gateway. This is a bigger change that affects every inbound message. It should be tested carefully before cutover.

The Gateway Model Has Real Advantages for Multi-Site Practices

Multi-site practices with hundreds of users, mixed mail platforms, and complex compliance needs benefit from the gateway model. Centralized policy means one team owns the encryption rules across every location, regardless of local mail configuration.

The advantages compound with size:

  • Uniform enforcement across every mailbox in every location
  • Centralized reporting for compliance audits
  • Directory-based policy that adjusts as staff join and leave
  • Inbound threat protection bundled into the same gateway
  • Automated encryption on regulated content without user decision

Health systems with an internal IT team, a compliance officer, and established procurement processes match this profile. The gateway pays back its complexity through scale.

Practices under fifty users rarely see the same payback. The setup, tuning, and administrative time exceeds the benefit at that scale. That is where portal-based alternatives become more attractive.

[mh_protip]

Portal-Based Alternatives Skip the Gateway Deployment

Portal-based HIPAA email services take a different approach. There is no gateway between the mail server and the internet. The sender routes messages through the service either by using an add-in inside Gmail or Outlook, by sending through an SMTP relay, or by using a separate compose interface hosted by the vendor.

Mailhippo is an example of the portal model. It works with existing Gmail or Outlook accounts, includes a signed BAA in the base plan, and delivers encrypted messages through a portal link. There are no PGP keys, no S/MIME certificates, and no gateway policy tuning. One click on the send side, one link click on the recipient side.

The portal model trades automated policy detection for simplicity. The sender decides which message needs encryption. There is no gateway scanning body text for PHI patterns. For practices where staff already know which messages contain PHI, the manual decision costs less than the gateway tuning effort.

The right choice depends on the practice profile. Multi-site health systems match the gateway model. Small and mid-size practices often match the portal model. Both approaches satisfy HIPAA transmission security when configured correctly.

Zix Sits Inside a Broader HIPAA Email Toolkit

Zix is one of several methods HIPAA teams use for email transmission security. The full toolkit includes TLS as the transport baseline, S/MIME and PGP for message-level encryption, gateway services like Zix, and portal-based HIPAA email services.

Each method covers a different case:

  • TLS covers the base case where both mail servers support opportunistic encryption
  • S/MIME and PGP handle end-to-end encryption between technically fluent parties
  • Gateway services enforce policy across a large user base with mixed skill levels
  • Portal services deliver encrypted mail to any recipient with a browser

A practice choosing between Zix and a portal service should map its actual email flow. How many outbound PHI messages per week. How many external recipients. How many staff need to send encrypted mail. The answers point to the right model.

The broader HIPAA compliance picture also covers HIPAA-compliant website design, patient intake forms, and access controls on internal systems. Email is one leg of the compliance stack, not the entire picture.

Mailhippo as a Simpler Path to HIPAA Email Compliance

Practices that find the Zix gateway heavier than their send volume justifies often move to a portal-based service. Mailhippo secure email service works with existing Gmail or Outlook accounts, includes a signed BAA in the base plan, and delivers encrypted messages through a one-click recipient link with no keys or certificates.

The tradeoff is manual encryption. The sender chooses which message to encrypt. There is no gateway detecting PHI patterns in the body text. Staff who already know which messages contain PHI make the decision at compose time.

For small and mid-size practices, the portal model deploys faster, costs less per seat, and requires no IT time on gateway policy tuning. Compare quoted Zix pricing against Mailhippo pricing and factor in the setup time before deciding.

Both approaches meet HIPAA transmission security. The right choice depends on staff count, mail platform, external recipient mix, and internal IT capacity. Map your actual email flow before picking a platform.

[mh_faqs]

Posted on

How to Send Encrypted Emails Across Outlook Gmail and Yahoo

how to send encrypted emails guide featured image

[mh_key_takeaways]

Sending an encrypted email means applying an encryption method before the message leaves the sender. The specific steps vary by platform. Outlook, Gmail, Yahoo, and GoDaddy each handle encryption differently, and each has gaps that a dedicated service can fill.

This guide walks through the sender steps for each platform, covers attachments and password-protected files, and identifies where a HIPAA-focused encrypted email service fits the workflow.

The underlying protection is the same across methods. Content is unreadable to anyone without the correct key or credential. The differences are in setup, license, and recipient experience.

Sending an Encrypted Email in Outlook Uses Purview

The Outlook path starts in the compose ribbon of a new message. Click Options, then Encrypt, and pick a policy. Two policies are available: Encrypt-Only and Do Not Forward.

Encrypt-Only encrypts the content and lets the recipient reply, forward, and print. Do Not Forward encrypts the content and blocks forward, print, and download. The sender picks the policy at send time.

The tenant must be on Microsoft 365 Business Premium or higher for the Encrypt button to appear. Business Basic and Business Standard do not include the button. Adding it requires an upgrade or a per-seat license add-on.

External recipients see a notification with a Read the message button. The button opens outlook.office365.com in a browser. The recipient signs in with a Microsoft or Google account or requests a one-time passcode. Detailed steps are in the Microsoft support guide for encrypted messages in Outlook.

Sending an Encrypted Email in Gmail Depends on Workspace Plan

Gmail on Google Workspace Enterprise Plus or Education Plus supports client-side encryption. The admin enables it in the Google Admin console under Security, Access and data control, Client-side encryption. Users see a lock icon in the compose window.

The lock icon toggles encryption on for the message. The message content is encrypted in the browser before it reaches Google servers. The keys stay outside Google through a customer-controlled external key service.

Standard Workspace plans and personal Gmail do not support client-side encryption. Confidential mode is available on every Gmail account. Confidential mode sets an expiration date and disables forward, copy, print, and download. It does not encrypt content in a way that meets HIPAA transmission requirements.

Practices on standard Workspace plans that need encryption for HIPAA route outbound mail through a HIPAA email service. The Gmail interface stays the same. The encryption applies at the service layer.

how to send encrypted emails in article illustration one

Sending an Encrypted Email in Yahoo Requires a Workaround

Yahoo Mail does not offer native message-level encryption on standard consumer or business accounts. There is no Encrypt button in the Yahoo compose window equivalent to the Outlook or Gmail options.

Yahoo users send encrypted mail through one of three workarounds:

  • Install a browser extension such as Mailvelope that adds PGP support to the Yahoo web interface.
  • Attach a password-protected ZIP file to the message and share the password through a separate channel.
  • Route outbound mail through a HIPAA email service that adds encryption at the outbound gateway.

Yahoo does not sign a business associate agreement for consumer accounts. The platform is not appropriate for PHI regardless of the encryption workaround. Practices sending regulated content should move to a compliant mail platform rather than relying on Yahoo with encryption bolted on.

Sending an Encrypted Email From GoDaddy Requires a Third-Party Layer

GoDaddy Professional Email is hosted mail on the godaddy.com or a custom domain. The service does not offer native message-level encryption in the web interface or in the standard IMAP client access.

Practices using GoDaddy for hosted email send encrypted mail through one of three options. Add a third-party S/MIME certificate to Outlook or Apple Mail connected to the GoDaddy account. Use a browser extension that supports PGP or S/MIME. Route outbound mail through a HIPAA email service.

GoDaddy signs a business associate agreement for some hosted email plans through a separate compliance add-on. The BAA covers storage of PHI on GoDaddy infrastructure. It does not cover the encryption of outbound transmission automatically.

Practices sending PHI from GoDaddy typically pair the account with a dedicated encryption service. The GoDaddy account handles inbound receipt and stored mail. The encryption service handles the outbound HIPAA-required protection.

[mh_example]

Sending Encrypted Files Uses the Same Message Encryption Path

Encrypted files travel as message attachments protected by the same encryption applied to the message body. S/MIME, PGP, Microsoft Purview, Google client-side encryption, and HIPAA email services all treat the attachment as part of the encrypted message.

The recipient sees one verification step. After the sign-in or key decryption, both the body and the attachments become readable. Do Not Forward rights in Microsoft Purview show attachments in the portal preview and block download.

Attachment size limits apply. Outlook caps standard attachments at 20 megabytes. Gmail caps at 25 megabytes. Larger files exceed the limit before encryption is even attempted. The message bounces with a size error.

For large files, use a HIPAA-compliant file transfer service and put the link in the message body. The email delivers the link. The file service handles the payload with its own encryption at rest and in transit.

how to send encrypted emails in article illustration two

Sending a Password-Protected File as a Workaround

Sending a password-protected file through email is a common workaround for accounts without full encryption. The sender ZIP-encrypts the file with a password and attaches the ZIP to the message.

Tools that support AES-256 encryption include 7-Zip, WinRAR, and the built-in Archive Utility on macOS with a strong password. The encrypted ZIP is unreadable without the password. This protects the file at rest and in transit.

The password must go through a separate channel. Phone call, text message, or a secure messaging app all work. Never include the password in the same email as the encrypted attachment. That defeats the encryption.

Password-protected attachments do not meet the HIPAA requirement for encrypted transmission of PHI when the message body itself contains identifying information. The workaround protects the file but leaves the body exposed. Dedicated encryption remains the required control for regulated content.

Sender Steps Compared Across Platforms

The sender view differs across platforms. The table below summarizes the steps and license requirements for each.

Platform Sender Step License Required Recipient Experience
Outlook Options, Encrypt, pick policy Business Premium or higher Portal sign-in or passcode
Gmail (Workspace) Lock icon in compose Enterprise Plus or Education Plus Portal sign-in with key service
Yahoo Browser extension or gateway None native Depends on workaround
GoDaddy Third-party layer None native Depends on layer added
HIPAA Email Service Send Secure button or automatic Service subscription One-click portal, no account creation

The service approach is the shortest path for accounts without built-in encryption. It also fits practices on Business Premium or Enterprise Plus that want a simpler recipient experience for patient communication.

[mh_protip]

Sending Encrypted Mail to Recipients With No Encryption Setup

The most common friction point in sending encrypted mail is the recipient. A patient with a personal Gmail account does not have S/MIME certificates. A small business partner may not know how to use PGP.

Portal-based encryption solves this. Microsoft Purview and most HIPAA email services deliver the recipient a notification with a link. The recipient clicks the link, authenticates with a sign-in or one-time passcode, and reads the message in a browser.

The recipient does not install anything. The recipient does not need a specific mail client. The recipient does not need to hold any cryptographic material. The portal experience matches how patients already use online banking or telehealth portals.

Practices sending to patients almost always want the portal experience for this reason. The one-click access matches patient tech literacy across a broad population.

HIPAA Applies to Encryption Choices for Covered Entities

Covered entities and business associates operate under the HIPAA Security Rule. Encryption is one required technical safeguard. The HHS Security Rule guidance treats encryption as an addressable specification.

Addressable does not mean optional. The covered entity must either implement encryption or document why an alternative safeguard is reasonable. Most compliance reviews expect encryption on any transmission of PHI outside the internal network.

The sending platform must also have a signed business associate agreement in place with the covered entity. Microsoft 365 and Google Workspace include a BAA as part of the standard business terms. Personal Gmail and consumer Yahoo do not.

Practices building the wider HIPAA posture around encrypted mail also need to cover the website and patient portal. See the guide on healthcare website security features for the site-side controls.

Dedicated HIPAA Email Services Simplify the Sender Workflow

A dedicated HIPAA email service handles the encryption, the BAA, the access logs, and the recipient portal in a single plan. The sender writes mail in a familiar Gmail or Outlook interface.

Mailhippo is one option in this category. It works with existing Gmail and Outlook accounts. The BAA is included in the base plan. Encryption applies to every outbound message. Recipients open messages with one click, without creating a Microsoft or Google account.

Related reading covers the platform-specific how-tos: how to send varracuda encrypted email, how to send encrypted email, how to send an encrypted email, how to send encrypted email using gmail, send encrypted email, and how to send encrypted email via comcast.

Practices coordinating encrypted email with a wider healthcare digital strategy often pair the mail service with a compliant site and portal setup. A healthcare marketing agency handles the marketing overlay on top of the compliance stack.

[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

How to Send an Encrypted Email on Any Device

how to send an encrypted email guide featured image

[mh_key_takeaways]

Sending an encrypted email is a different set of steps on every device and every mail app. Office 365 has a button. Gmail has two paths that look similar but work differently. Mac Mail and iPhone Mail share the S/MIME model. Yahoo has no native option at all.

This guide walks through the exact steps for each. It also covers the access side so the recipient knows what to do when the message arrives. For a cross-provider path with one workflow, a gateway service handles the recipient side uniformly and delivers encrypted email to any inbox.

Skip to the section that matches your device. Every section stands on its own with the menu paths named directly.

Send an Encrypted Email in Office 365 With the Encrypt Button

Office 365 on Business Standard and above adds an Encrypt button to the compose ribbon. It uses Microsoft Purview Message Encryption underneath.

Open Outlook. Start a new message. Click the Options tab in the ribbon. Click Encrypt. Choose Encrypt-Only or Do Not Forward.

Write the message and click Send. The recipient receives an email with a link. They authenticate with Microsoft, Google, or a one-time passcode and read the message in a browser.

Setup on the tenant side runs through the Microsoft Purview compliance portal. Admins should follow Microsoft Purview encryption documentation for the exact policy configuration.

how to send an encrypted email in article illustration one

Send an Encrypted Email on Mac With S/MIME

Mac Mail has native S/MIME support. Setup starts with installing an S/MIME certificate in Keychain Access.

Double-click the PKCS 12 file. Enter the password. Choose the login keychain. Keychain Access imports the private key and the certificate together.

Open Mail. Start a new message. If the recipient certificate is available, a lock icon appears next to the recipient field. Click the lock to encrypt. Write the message and click Send.

Signed mail from a recipient adds their public key to the local keychain automatically. This populates the encrypt cache without manual action. Related linked topic: how to send encrypted email for the parallel workflow on Windows.

Send an Encrypted Email From iPhone With S/MIME

iPhone Mail supports S/MIME natively. The certificate installs through a configuration profile pushed by MDM or a manual .p12 file.

Send the .p12 file to yourself, then tap it in Mail. Enter the password. Go to Settings, General, VPN and Device Management, and tap the profile. Tap Install and enter the device passcode.

Open Mail. Start a new message. If the recipient certificate is cached, a blue lock icon appears next to the recipient field. Tap the lock to encrypt. Tap Send.

Enterprise deployments push these profiles automatically through Jamf, Intune, or another MDM. Manual install is fine for a solo user but slow to scale beyond a few devices.

[mh_example]

Send an Encrypted Email in Google Workspace

Google Workspace offers two encryption paths. Confidential mode is available on all tiers. Hosted S/MIME is available on Enterprise Standard, Enterprise Plus, Education Standard, and Education Plus.

For confidential mode, click the lock and clock icon at the bottom of the compose window. Set expiration and passcode. Click Save. Write and Send.

For hosted S/MIME, the admin uploads CA certificates in the Google Admin console under Apps, Google Workspace, Gmail, User Settings. Each user then uploads their personal certificate through Gmail settings under Accounts.

Once configured, a lock icon appears next to the recipient field in the compose window. Green means encryption is possible. Related: how do I send an encrypted email for a full walkthrough of the confidential mode versus hosted S/MIME choice.

how to send an encrypted email in article illustration two

Send an Encrypted Email in Yahoo Mail

Yahoo Mail has no native encrypted email feature. There is no Encrypt button, no confidential mode, and no hosted S/MIME.

The practical workaround is to connect the Yahoo account to Thunderbird by IMAP. Install an S/MIME certificate in Thunderbird. Send encrypted mail from Thunderbird using the Yahoo address as the From address.

The alternative is a gateway service that authenticates against the Yahoo account and sends portal-delivered encrypted mail on its behalf. This is a workaround, not a supported feature.

Yahoo does not offer a Business Associate Agreement. Yahoo is not appropriate for HIPAA use. Practices sending PHI should migrate off Yahoo to a business mail provider that offers a BAA before starting a real encryption program.

Access an Encrypted Email You Received

Access on the recipient side is the mirror of the send side. The path depends on how the sender encrypted the message.

An Outlook Encrypt message arrives with a link. Click it. Authenticate with Microsoft, Google, or a one-time passcode. Read the message in a browser.

An S/MIME encrypted message opens normally inside a client that supports S/MIME and holds the recipient private key. An unsupported client shows an unopenable attachment. Recipients on personal Gmail cannot open S/MIME encrypted mail.

A portal-delivered message from a gateway service arrives with a notification link. Click the link. Enter the passcode. Read the message in the hosted view. Related linked topic: how to open an encrypted email.

[mh_protip]

HIPAA Notes for Sending Encrypted Email

Sending PHI over email requires a signed Business Associate Agreement with the mail provider. Encryption alone does not equal HIPAA compliance.

Microsoft 365 Business Standard and above and Google Workspace Business Standard and above both offer BAAs. Apple iCloud, Yahoo Mail, and free personal Gmail and Outlook.com do not.

The HHS Security Rule requires access controls, audit logging, session timeouts, and workforce training in addition to encryption. Policy documentation is required for a defensible program.

Verify recipient identity before sending PHI. A wrong email address is a HIPAA breach even when the message is encrypted. See related healthcare security context for how email fits inside the wider stack.

Common Sending Problems and How to Fix Them

The Encrypt button is missing in Outlook. Cause. Business Basic tier or free Outlook.com. Fix. Upgrade to Business Standard or higher, or use a gateway service.

The lock icon is grayed out in Mac Mail. Cause. Recipient certificate is not in the local keychain. Fix. Ask the recipient to send a signed message first. The public key caches automatically.

Common sending problems and fixes:

  • Missing certificate on iPhone. Install through Settings and trust the profile
  • Recipient reports unopenable attachment. Recipient client does not support S/MIME
  • Portal notification landed in spam. Add sender portal domain to safe senders
  • Sender From address does not match certificate. Fix in Outlook Trust Center
  • Certificate expired. Renew with the CA and reinstall on all devices

Related: how to troubleshoot encrypted email for a deeper diagnostic walkthrough.

Cross-Device Encrypted Email With a Gateway Service

Managing S/MIME certificates across desktop and mobile at scale is real operational work. Gateway services remove the certificate step by handling encryption at the server.

The sender writes the message in the normal mail app on any device. A trigger word in the subject or a plugin button triggers encryption. The service uploads the message to a hosted portal.

The recipient receives a notification. They click, authenticate with a passcode, and read in a browser. This works on any device with any modern browser.

Mailhippo works this way. It sits on top of Gmail or Outlook, includes a BAA in the base plan, and works uniformly across desktop, iPhone, iPad, and Android. Practices sending PHI to a mix of clinical peers and patients can pair this with healthcare marketing services to keep the intake, contact, and email chain inside the same compliance boundary.

[mh_faqs]

Posted on

Are Emails Encrypted by Default in 2026

are emails encrypted guide featured image

[mh_key_takeaways]

Most email today rides on some form of encryption. The question is which kind, at what stage, and whether it survives long enough to matter.

Ask are emails encrypted and the honest answer is a qualified yes. Transport encryption covers the connection between mail servers when both sides support it. Message-level encryption, the kind used for encrypted email delivery, protects the content from the sender’s device to the recipient’s inbox.

The gap between those two matters for anyone sending regulated data. This guide walks through where each layer applies, which providers use which methods, and what changes when HIPAA or a business associate agreement enters the picture.

TLS in transit is the default, not end-to-end protection

TLS, or Transport Layer Security, is the standard method for encrypting the link between two mail servers. When a sending server hands a message to a receiving server, both sides negotiate a TLS session and the traffic across that hop is encrypted.

Google reports that around 95 percent of Gmail traffic uses TLS on outbound and inbound. Microsoft 365 numbers are similar. The 5 percent gap is real, and it usually reflects small receiving servers that do not support modern TLS versions.

TLS does not encrypt the message body itself. It encrypts the connection. Once the receiving server accepts the message, it stores the content in whatever form its policies dictate.

Opportunistic TLS also falls back to plain SMTP if the handshake fails. MTA-STS and DANE are the two standards that force a receiving server to require TLS, and they close that downgrade path. Most large providers publish MTA-STS records now, but many smaller domains do not.

Gmail encrypts in transit and at rest, but not end to end

Are all Gmail emails encrypted? In transit, almost all of them are, when the receiving provider supports TLS. Google publishes real-time transparency numbers on this at their Safer Email Transparency Report.

At rest, Gmail stores every message with server-side encryption using keys Google manages. That protects the mailbox from disk theft or unauthorized physical access to Google data centers.

End-to-end encryption is a different layer. Gmail supports S/MIME on Google Workspace Enterprise Plus and Education Plus, which encrypts the message body before it leaves the sender’s device. Personal Gmail accounts do not include native S/MIME.

For consumer-grade Gmail users who need to send an encrypted message once in a while, the practical options are Confidential Mode, which sets an expiration and a passcode but does not encrypt the body, or a browser extension that layers PGP over the compose window.

are emails encrypted in article illustration one

Microsoft 365 encryption depends on the license tier

Are Microsoft emails encrypted? Internal messages between two users on the same Microsoft 365 tenant stay on Microsoft’s network and are encrypted the entire way. External messages use opportunistic TLS.

Purview Message Encryption, which was previously called Office 365 Message Encryption, is Microsoft’s message-level product. It encrypts the body and attachments and delivers external recipients a portal link. Recipients sign in with a Microsoft or Google account, or with a one-time passcode.

Purview requires Business Premium, Microsoft 365 E3, or higher. Business Basic and Business Standard do not include it. Practices on lower tiers either need to upgrade the entire tenant or send outbound clinical mail through a dedicated encrypted service.

Azure Rights Management sits behind Purview and handles the actual key management. If a tenant has never activated Azure Rights Management, the Encrypt button in the Outlook ribbon does not appear even on the correct license.

Internal Office 365 traffic never leaves Microsoft infrastructure

Are internal Office 365 emails encrypted? Yes, at every layer. Internal email between two users on the same tenant traverses Microsoft’s private network and never touches the public internet.

The traffic between Exchange Online servers is TLS-protected. The mailboxes themselves are encrypted at rest with BitLocker at the storage level and additional service-level encryption in the message database.

Cross-tenant email is a different case. A message from one Microsoft 365 tenant to another still uses Microsoft infrastructure end to end, but it is treated as external and subject to standard transport encryption rules.

Administrators can enforce Modern Authentication, disable legacy protocols like POP and IMAP, and turn on Customer Key to hold their own encryption keys. Those steps harden the tenant but do not change the underlying encryption layers already in place.

[mh_example]

DocuSign notifications are not encrypted documents

Are DocuSign emails encrypted? The notification email itself is an ordinary message sent over TLS. It contains a link, a sender name, and a subject line, and none of that content is encrypted end to end.

The signed document lives inside the DocuSign platform, not in the email. When the signer clicks the link, they authenticate to DocuSign and view the document over HTTPS. The document itself is protected by DocuSign’s platform encryption and access controls.

The gap this creates is that anyone with mailbox access to the recipient can click the link and, if additional authentication is not enforced, sign the document. DocuSign offers signer authentication options like SMS codes, knowledge-based questions, and ID verification. Those are separate from the email.

Providers like Adobe Sign, Dropbox Sign, and PandaDoc all follow the same pattern. The document is protected in the platform, and the notification is a routine email.

Are emails automatically encrypted or does the sender configure it

Are emails automatically encrypted? Transport encryption is automatic when both servers support it. Message-level encryption is not automatic on any consumer email service.

The sender has to take an action. On Outlook 365, that action is clicking the Encrypt button on the message ribbon. On Gmail Enterprise, S/MIME messages are marked automatically if certificates are installed on both sides.

Some services automate the encryption trigger based on content. Data loss prevention rules can inspect outbound mail for patterns like credit card numbers, Social Security numbers, or clinical terms, then apply encryption when a rule matches.

For healthcare senders who need every message with protected health information to be encrypted without depending on user behavior, the practical approach is a gateway service that encrypts by default. Mailhippo works this way, applying encryption to every outbound message from the connected account rather than relying on a user to remember the correct button.

are emails encrypted in article illustration two

End-to-end encryption requires S/MIME, PGP, or a portal service

Three technologies deliver true end-to-end email encryption today: S/MIME, PGP, and portal-based services. Each protects the message body from the sender’s device to the recipient’s inbox or portal.

S/MIME uses X.509 certificates issued by a certificate authority. Each user has a personal certificate, and the sender needs the recipient’s public key to encrypt a message to them. Certificate management is the hardest part of running S/MIME at scale.

PGP uses a similar public-private key pair model but operates through a web of trust rather than a central authority. It is common in developer and privacy-focused circles but rare in mainstream business email.

Portal services like Purview Message Encryption and Mailhippo skip the certificate problem by delivering messages through a browser-based portal. The recipient does not need to manage keys, and the sender only needs an account.

HIPAA requires encryption when it is reasonable and appropriate

The HIPAA Security Rule lists encryption as an addressable specification for transmitting electronic protected health information. Addressable means the covered entity must implement it if it is reasonable and appropriate, or document why it is not.

In practice, HHS treats email encryption as the default expectation for any transmission of PHI outside a covered entity’s internal network. The 2013 Omnibus Rule reinforced that position by tying breach notification safe harbor to encryption of the data involved.

The HHS guidance on the Security Rule and NIST Special Publication 800-52 Rev. 2 both point to TLS 1.2 or higher for transport and AES-128 or AES-256 for content encryption. Meeting those baselines matters more than the specific product chosen.

Practices that route external clinical email through a service with a signed business associate agreement satisfy the encryption requirement and the vendor accountability requirement at the same time. Emails that carry hipaa phishing emails patterns still need employee training on top of encryption.

[mh_protip]

Free and consumer options do not include a BAA

ProtonMail sends encrypted messages to other ProtonMail users automatically. Messages to outside recipients go through a password-protected portal that the recipient opens in a browser.

Outlook.com supports Microsoft’s free encryption for consumer accounts through the same Purview infrastructure used by business tenants. The recipient experience is identical to the paid version.

Free S/MIME certificates are available from providers like Actalis for personal use. Setting them up requires installing the certificate in the operating system’s certificate store and pairing it with each mail client.

None of the free options include a business associate agreement. For a healthcare practice, that rules them out for anything involving protected health information. If a topic covers are there free tools for encrypting emails, the compliance angle is where free services fall short. Compliance requires a paid service that will sign a BAA and accept vendor liability.

Steps to confirm your email is being encrypted correctly

Gmail shows a small padlock next to the sender address on received mail. A closed padlock means TLS was used on the last hop, an open one means it was available but not enforced, and no padlock means the message arrived over plain SMTP.

Outlook shows a shield icon on S/MIME-signed or encrypted messages. A green check inside the shield means the signature validated. A red X or a missing shield means the message was not S/MIME protected.

Portal messages arrive as a link rather than an inline body. Recipients who see a Read the message button and a sender-branded landing page are receiving a message-level encrypted message.

For senders who want to confirm their outbound TLS posture, tools like the NIST SP 800-52 Rev. 2 guidelines outline the correct cipher and version baseline, and free tests like CheckTLS or the Google Postmaster Tools show the negotiated TLS status per destination domain.

What to configure for a healthcare or compliance-heavy practice

Start with a written policy that defines what qualifies as protected health information and which outbound messages need encryption. Staff cannot apply a rule they do not know exists.

Configure MTA-STS and DANE on the practice domain to prevent TLS downgrade attacks on outbound mail. Publish DMARC at reject or quarantine to stop spoofed messages from reaching patients.

Choose one encryption path and stick with it. Options include Microsoft 365 Business Premium plus Purview, Google Workspace Enterprise plus S/MIME, or a gateway service like Mailhippo that layers encryption over the existing Gmail or Outlook account without a license upgrade.

Practices that want a broader marketing and website foundation to match the security posture often work with a specialist agency. Firms that focus on healthcare marketing services understand how encryption, patient acquisition, and HIPAA-safe intake forms fit together, and how a compliant healthcare website security setup supports the practice’s digital communications.

  • Verify TLS 1.2 or higher on outbound and inbound mail flow.
  • Enable MTA-STS and DANE on the practice domain.
  • Enforce Modern Authentication and disable legacy IMAP and POP.
  • Route external PHI-bearing mail through an encrypted service with a signed BAA.
  • Train clinical and administrative staff on when encryption is required.

Answering the core question, are emails encrypted, comes down to which layer and which sender. Transport encryption is close to universal between major providers. Message-level protection is the sender’s responsibility, and it is what compliance rules actually require.

[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

How to Send Encrypted Email in Gmail

how to send encrypted email gmail guide featured image

[mh_key_takeaways]

Gmail handles more than 1.8 billion active accounts, and a large share of business email in North America runs through Workspace. Every one of those messages travels over TLS by default when the receiving server supports it. TLS is not the same as message-level encryption.

Learning how to send encrypted email in Gmail means picking the right method for the recipient and the sensitivity of the content. Gmail offers three options built in: TLS transport encryption, Confidential Mode, and S/MIME on Enterprise plans.

For healthcare organizations and any team handling regulated data, native Gmail options often fall short of HIPAA requirements. This guide walks through each method and when to use it.

Gmail Uses TLS for Every Message by Default

Every Gmail message leaves Google servers over Transport Layer Security whenever the receiving mail server supports it. TLS encrypts the connection between the two servers. Nobody sitting on the network path in between can read the message.

The padlock icon in the top-right corner of an open Gmail message shows the transport status. A gray padlock means TLS is active. A red padlock means the recipient server does not support TLS and the message will travel unencrypted.

TLS protects the connection, not the stored copy. Once the message lands in the Sent folder or the recipient inbox, TLS no longer applies. Google can read the message content on its servers, and so can the recipient mail provider.

According to Google documentation, TLS is opportunistic. If a recipient server does not accept encrypted connections, Gmail sends the message in plaintext by default. That behavior alone disqualifies TLS as a standalone compliance method for protected health information.

Confidential Mode Adds Access Controls but Not End-to-End Encryption

Gmail Confidential Mode is available on every personal Gmail account and every Workspace edition. To use it, click Compose, then click the padlock and clock icon at the bottom of the compose window. A menu appears with an expiration date and an optional SMS passcode.

Confidential Mode disables forwarding, copying, printing, and downloading for the recipient. When the expiration date passes, the message becomes unreadable. Senders can revoke access before expiration from the Sent folder.

The mode does not use end-to-end encryption. Google can read the message content. Screenshots defeat the copy and print restrictions because the recipient still sees the message on screen. SMS passcodes rely on phone carrier security, which SIM-swap attacks routinely bypass.

Confidential Mode suits casual privacy needs such as sending a temporary access code or a document link that should expire. It does not meet HIPAA transmission standards, and Google does not extend its business associate agreement to cover Confidential Mode as a compliant PHI transmission method.

how to send encrypted email gmail in article illustration one

S/MIME Hosted Encryption Requires Workspace Enterprise

S/MIME is the built-in Gmail option for true message-level encryption. It is available only on Google Workspace Enterprise Plus, Education Standard, and Education Plus editions. Workspace Business tiers do not include it.

Enabling S/MIME starts in the Admin console. Navigate to Apps, then Google Workspace, then Gmail, then User settings. Toggle S/MIME encryption for sending and receiving. Save the change and wait up to 24 hours for it to propagate.

Each user then uploads a personal S/MIME certificate under Gmail settings, Accounts and Import, Upload your public certificate. The certificate must come from a trusted certificate authority. Both sender and recipient need valid certificates.

When the setup is complete, the padlock icon in a compose window turns green for messages that will send with S/MIME encryption. If the recipient does not have a valid certificate installed, the padlock stays gray and the message sends over TLS only.

Confidential Mode Setup Takes Under a Minute

Open Gmail and click Compose. Fill in the recipient, subject, and body as usual. At the bottom of the compose window, find the icon that looks like a padlock with a clock overlay and click it.

Select an expiration date from the dropdown. Options range from one day to five years. Choose whether to require an SMS passcode. If SMS is selected, enter the recipient phone number in the field that appears.

Click Save. Send the message. The recipient receives an email with a link to view the message. If SMS was enabled, they receive a text with a passcode to enter before the message loads.

  • External Gmail recipients see the message inline, gated by expiration.
  • Non-Gmail recipients click through to a Google-hosted page.
  • Sender can revoke access at any time from the Sent folder by clicking Remove Access.

[mh_example]

S/MIME Certificates Need Renewal and User-Level Provisioning

S/MIME certificates expire, typically after one to three years depending on the issuing authority. Renewals require administrator action for every user account. Certificates issued to a departing employee should be revoked in the Admin console to prevent decryption of prior messages.

Certificate authorities include DigiCert, Sectigo, GlobalSign, and IdenTrust. Costs range from around $20 per user per year for basic identity validation to over $100 per user per year for extended validation with organization details.

For encrypted send to work, the recipient also needs a valid certificate from a trusted authority. External correspondents who do not use S/MIME cannot receive encrypted messages this way. Gmail falls back to TLS transport encryption for those recipients.

This is why S/MIME suits internal exchanges between staff at the same organization or between organizations that have coordinated certificate deployment. It does not suit sending sensitive content to patients or external vendors who do not manage their own certificates.

HIPAA Coverage in Google Workspace Has Boundaries

Google offers a business associate agreement to Workspace customers on Business Standard, Business Plus, and all Enterprise editions. The BAA covers Gmail, Calendar, Drive, Meet, and other core services. Personal Gmail accounts are not covered.

The BAA covers the transmission of PHI through Gmail when standard TLS encryption is in effect between servers. It does not cover Confidential Mode as a distinct HIPAA-safe transmission method. Practices assuming Confidential Mode is HIPAA-compliant are working from a mistaken reading of the BAA.

Because TLS is opportunistic and falls back to plaintext when the recipient server does not support it, Workspace admins cannot guarantee encrypted delivery to every recipient without additional controls. That gap is what drives many healthcare organizations to add a HIPAA-focused encrypted email service.

Additional HIPAA safeguards include audit logging of message access, secure archive retention for six years, and enforced encryption on any message flagged with PHI. Native Gmail provides some of these; complete coverage typically involves a purpose-built service.

how to send encrypted email gmail in article illustration two

Third-Party Services Layer HIPAA Compliance Over Gmail

Purpose-built HIPAA-compliant email services integrate with Gmail through a browser plug-in, a Gmail add-on, or SMTP relay. The sender composes and sends from Gmail without changing workflow. The service handles encryption, delivery fallback, and audit trail.

Mailhippo works this way. It sends over TLS when the recipient server supports it, falls back to a secure portal link when TLS is unavailable, includes a signed BAA in the base plan, and requires no certificate management for senders or recipients. Practices on standard Gmail or Workspace Business use it to close the HIPAA gap without switching platforms.

The recipient experience is a single click. They receive a notification email with a link, click it, authenticate with a passcode, and read the message in a browser. No account creation, no software install, no key management.

For healthcare organizations that also handle web presence and patient acquisition, coordinating email security with the broader tech stack matters. Firms offering healthcare marketing services often deploy encrypted email and HIPAA-compliant website design together.

Recipient Experience Differs Across Each Method

TLS is invisible to the recipient when it works. The message arrives in the inbox looking like any other email. No click-through, no passcode, no external portal. Nothing signals that transport encryption was applied.

Confidential Mode delivers a notification email with a View the email button. The recipient clicks and, if SMS was enabled, enters a passcode from a text message. They read the message in a Google-hosted view with copy, forward, print, and download disabled.

S/MIME delivers a locked message icon in a supported email client. Outlook, Apple Mail, and Gmail render the message inline once the recipient certificate decrypts it. In an unsupported client, the recipient sees garbled ciphertext or an attachment they cannot open.

Portal-based services deliver a notification with a link. The recipient clicks, authenticates with a one-time code, and reads in a browser. This suits patients and external contacts who do not manage certificates but expect a low-friction click.

[mh_protip]

Common Errors When Sending Encrypted Email in Gmail

The red padlock is the most frequent warning. It means the recipient mail server does not support TLS. For non-sensitive content, the message still sends. For PHI or other regulated data, do not send when the padlock is red without a portal fallback.

S/MIME send failures often trace to a missing recipient certificate. Gmail shows a gray padlock instead of green, and the message sends over TLS. To force S/MIME, both parties must have valid certificates uploaded and the Workspace admin must have enabled the feature at the domain level.

Confidential Mode messages sometimes fail to render for recipients on strict email security gateways. The notification email arrives, but the click-through link is stripped or blocked by the recipient inbound filter. Test with the specific recipient before relying on Confidential Mode for time-sensitive delivery.

According to HIPAA Journal, the most common compliance failure is sending PHI to an external address without confirming the transmission was encrypted end to end. Assume nothing about transport; verify the method for every sensitive message.

Choose the Method by Recipient and Content Sensitivity

Match the encryption method to the message. Casual internal notes to colleagues who use Gmail can rely on TLS. Time-limited access to a document link or a temporary credential fits Confidential Mode. Regulated content going to an external recipient needs message-level encryption or portal delivery.

  • Internal team messages, no regulated content: TLS is sufficient.
  • Temporary access codes to trusted external recipients: Confidential Mode.
  • Regulated PHI, PII, or financial data to any external recipient: S/MIME or a HIPAA-compliant service.
  • Recipients on unknown email systems: portal-based delivery with fallback.

For healthcare providers, portal-based services with a BAA are the most reliable path. They handle recipients across all mail providers, provide audit logs, and remove certificate management. Setup takes minutes rather than the administrator overhead S/MIME requires.

Related reading covers how to send encrypted email across platforms, how to send an encrypted email from Outlook, and how to send encrypted email using Gmail for Workspace teams. For teams building patient-facing infrastructure, resources on healthcare website security features pair well with encrypted email deployment.

Verify Encryption for Every Sensitive Message

Before hitting Send on any message with regulated content, check the padlock icon. Green means S/MIME. Gray means TLS. Red means unencrypted, and the message should not go without a portal fallback.

For Workspace administrators, the Admin console provides an Email Log Search that shows the encryption status of every outbound and inbound message. Use it to audit compliance for a defined period, especially before signing off on a HIPAA risk assessment.

According to NIST Special Publication 800-45, verified end-to-end encryption or a portal-based delivery method is required for messages carrying sensitive personally identifiable information across public networks. Assumed TLS is not the same as verified TLS.

The final rule is straightforward. Do not send regulated content over Gmail unless you have picked and verified a method that meets the transmission standard. Pick S/MIME for internal certified users, or add a HIPAA-compliant service for everyone else.

[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