Most email encryption purchases fail on the recipient side: the product encrypts perfectly, but patients, clients and suppliers cannot or will not open the message, so staff find another way to send it. Email encryption products combine several delivery methods, usually enforced TLS between mail servers, a secure web portal for recipients without keys, and automated S/MIME or OpenPGP for partners who have them, all driven by policy that decides which method to use for each message. In healthcare the demand is driven by the HIPAA Security Rule, where encryption of electronic protected health information in transit is an "addressable" implementation specification at 45 CFR 164.312(e)(2)(ii): you implement it where reasonable and appropriate, or document why an equivalent alternative is used. This vendor-neutral buyer's guide is for messaging, security and compliance teams choosing a gateway, portal or platform-native option. For how S/MIME and OpenPGP work, read the OpenPGP and S/MIME Email Encryption Guide; it is not repeated here.
Key takeaways
- Policy drives everything. The value is in deciding automatically, per message, between enforced TLS, portal delivery and S/MIME, based on recipient, content and classification, so users do not have to choose.
- Start with what your mail platform already includes. The major cloud mail suites offer native message encryption in some licence tiers; a third-party product must justify itself against them.
- Recipient experience decides adoption. Test portal sign-in, replies, attachments and mobile reading with real external recipients before you sign.
- Key custody is the core security question. Know who holds the keys for portal messages, archived copies and S/MIME private keys, and how they are recovered.
- Enforced TLS is the cheapest win. MTA-STS (RFC 8461) and TLS reporting (RFC 8460) protect the bulk of partner mail without any recipient action.
Define requirements
- Regulatory drivers: HIPAA transmission security (45 CFR 164.312(e)), GDPR Article 32 security of processing, PCI DSS requirements for cardholder data over open networks, and any contractual or sector rules; record which ones require message-level protection rather than transport encryption.
- Recipient population: consumers and patients (portal or TLS), business partners with mature mail systems (enforced TLS), and partners already using S/MIME or OpenPGP certificates.
- Mail platform: a cloud mail suite, on-premises mail servers or a mixed estate, and whether you already route outbound mail through a secure email gateway.
- Triggers: user-initiated (button or subject keyword), classification labels, DLP detection of health, financial or personal data, or recipient domain.
- Retention and eDiscovery: encrypted messages must still be searchable, journaled and retained. See the Email Archiving and Journaling Guide.
- Key custody and residency: whether keys must be customer-managed, held in an HSM, or kept in a particular jurisdiction.
Capability areas
| Delivery method | How it works | Best for | Watch for |
|---|---|---|---|
| Policy-based enforced TLS | Gateway refuses to deliver to named domains unless TLS with a valid certificate is negotiated; MTA-STS lets receiving domains publish the same requirement | High-volume partner mail, other healthcare providers, insurers | Protects transit only; message sits unencrypted in the recipient mailbox |
| Portal (pull) delivery | Recipient receives a notification and reads the message in a web portal after authenticating | Consumers, patients, one-off recipients | Sign-in friction, phishing look-alikes of the notification, portal availability |
| Push encryption | Encrypted message or attachment delivered to the inbox and opened with a password or a sign-in | Recipients who need offline copies | Password distribution, attachment handling on mobile |
| S/MIME automation | Gateway or service signs and encrypts using certificates it manages, and harvests partner certificates | Regulated partners, government, legal | Certificate lifecycle, private key custody and escrow |
| OpenPGP automation | Same principle with OpenPGP keys | Technical partners and some public sector communities | Key discovery and validation |
| Platform-native rights protection | Mail platform encrypts and applies usage restrictions (for example do not forward) | Organisations standardised on one suite | Licence tier, behaviour for external recipients |
Native options to benchmark: cloud mail suites typically offer two native patterns. The first is rights-management based message encryption, applied by users or by mail flow rules, where external recipients on other services receive a wrapper message and read the content in a portal; premium tiers often add branding, automatic policies, portal expiry and revocation, which usually apply only to recipients reading through the portal. The second is hosted S/MIME, where the provider stores the organisation's private keys and can require signing or encryption for outgoing mail or specific content, or client-side encryption, where private keys stay in an external key service the organisation controls. Both are usually limited to certain licence tiers, so check current edition requirements in your provider's documentation, as they change.
Evaluation criteria
| Criterion | What good looks like | How to test it | Suggested weight |
|---|---|---|---|
| Policy engine | Encrypts automatically on DLP match, label or domain, picks the delivery method per recipient, with fallback rules | Send test messages containing health and card data to five recipient types | [25%] |
| Recipient experience | Portal works on mobile, supports replies and large attachments, sign-in without creating yet another password where possible | Ask ten real external users to open and reply | [20%] |
| Key custody and recovery | Customer-managed keys or HSM-backed keys, documented recovery, separation of admin duties | Review key architecture; simulate a key recovery | [15%] |
| TLS enforcement and reporting | Per-domain enforced TLS, MTA-STS and TLS-RPT support, visibility of downgrade failures | Configure enforced TLS to a test domain with an expired certificate | [15%] |
| Archiving and compliance evidence | Encrypted mail journaled in searchable form; audit trail of who opened what and when | Search the archive for a portal message; export its access log | [15%] |
| Administration and integration | Works with your mail platform and gateway without breaking DKIM or routing; logs to SIEM | Check DMARC results on encrypted messages | [10%] |
Weights in brackets are illustrative; a clinic sending mostly to patients will weight recipient experience higher, a firm exchanging with regulators will weight S/MIME and evidence higher.
Questions to ask vendors
- Which delivery methods do you support, and how does the policy engine choose between them for a given message and recipient?
- Who holds the keys for portal messages, can we hold them in our own KMS or HSM, and can your staff decrypt our messages?
- How do portal recipients authenticate, and how do you stop attackers sending convincing copies of your notification emails?
- Can we revoke or expire a message after sending, and does that work for recipients on any mail system?
- How are S/MIME certificates issued, renewed, escrowed and revoked for our users, and how do you discover partner certificates?
- How are encrypted messages journaled, retained and searched for eDiscovery?
- Does your gateway processing change message content in a way that breaks DKIM signatures or DMARC alignment?
- Will you sign a HIPAA business associate agreement or equivalent data processing terms, and where are portal data and keys hosted?
- What happens to unread portal messages and stored replies when the contract ends?
Red flags
- "Encryption" that is only opportunistic TLS, with no way to enforce it or see when it fails.
- Reliance on users remembering a subject-line keyword, with no DLP or label-based triggers.
- Portal passwords sent in the same email as the encrypted message.
- No documented key custody model, or keys held by the vendor with no customer control.
- Encrypted mail that cannot be journaled or searched, pushing compliance teams to keep separate unencrypted copies.
- Notification emails that are hard to tell apart from phishing and are not covered by your DMARC policy.
Proof of concept
- Baseline: publish MTA-STS in testing mode with a TLS-RPT address for your own domain and review a week of reports to see which partners fail TLS.
- Benchmark native: configure your mail platform's built-in encryption for one policy and record what it cannot do.
- Configure policies: build three rules in the candidate product: enforced TLS to named partners, portal for DLP matches to consumers, and S/MIME for one partner.
- Test recipients: send to the main cloud mail suites, a consumer webmail account, a mobile device and an S/MIME partner; record open, reply and attachment results.
- Test compliance: find each test message in the archive, export the access audit trail and revoke one portal message.
- Test failure: point enforced TLS at a domain with an invalid certificate and confirm the message is held or rerouted, not sent in clear.
- Score and clean up: score against the criteria, then remove test connectors, keys and certificates.
After rollout, track the share of outbound sensitive mail delivered by an encrypted method, portal open rates, TLS failure counts from TLS-RPT, and user-reported delivery complaints. For gateway selection beyond encryption, see the Email Security Buyer's Guide.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: OpenPGP and S/MIME Email Encryption Guide · Email Security Buyer's Guide · Email Archiving and Journaling Guide