[mh_key_takeaways]
An encrypted email is a message that has been scrambled with a cryptographic key so only the intended recipient can read it. The sender applies encryption, the message travels as ciphertext, and the recipient decrypts it back to readable form.
This matters because standard email was designed in the 1980s without built-in encryption. Anyone with access to the network path or the mail server could read the content. Encryption fixes that gap.
Understanding what an encrypted email is starts with two questions. What is being encrypted, and who holds the keys?
Encryption Converts a Message into Unreadable Ciphertext
Encryption takes plaintext, the readable message, and applies a mathematical function called a cipher along with a key. The output is ciphertext, a sequence of bytes that looks like random noise to anyone without the key.
Modern email encryption uses algorithms like AES-256 for symmetric encryption and RSA-2048 or higher for asymmetric encryption. These are the same algorithms that protect online banking, government communications, and enterprise data storage.
The recipient reverses the process. They apply the matching decryption function with the correct key, and the ciphertext becomes readable plaintext again. Without the key, the ciphertext is effectively random data that cannot be reversed by brute force with current computing.
The security of the whole system depends on protecting the key. If an attacker steals the recipient private key, the attacker can decrypt every message sent to that recipient. Key management is why encrypted email deployments require careful setup.
Two Layers of Email Encryption Exist
Email encryption operates at two layers. The transport layer protects the connection between mail servers. The message layer protects the content of the message itself.
Transport encryption uses TLS, the same protocol that protects HTTPS websites. When two mail servers connect, they negotiate a TLS handshake and encrypt the traffic in flight. An observer on the network sees only ciphertext.
Message encryption uses S/MIME, PGP, or a portal-based service. The sender encrypts the message content before it leaves their client. The mail server stores ciphertext. Only the recipient with the matching key can decrypt.
The difference matters for compliance. Transport encryption protects the connection but not the stored copy. Message encryption protects both. For regulated content, message encryption is the standard because it removes the mail server from the trust boundary.
TLS Is the Default Transport Encryption for Modern Email
Every major mail provider, Gmail, Outlook, Yahoo, Apple, and the rest, uses TLS by default. When a sending server contacts a receiving server, it attempts a TLS handshake. If both sides support it, the connection is encrypted.
The user does not enable TLS. The client shows a padlock icon when it is in effect. Gmail shows a gray padlock for TLS, green for S/MIME, red for unencrypted.
TLS has a critical weakness. It is opportunistic. If the receiving server does not support TLS, the sending server delivers the message in plaintext by default. The sender may not see any warning, and the client padlock may still show as green in the Sent folder because the initial hop was encrypted.
This behavior means TLS alone cannot guarantee an encrypted send. For regulated content, opportunistic TLS is not sufficient. According to NIST SP 800-45, verified end-to-end encryption is required for sensitive email.
S/MIME Uses Certificates from a Trusted Authority
S/MIME, or Secure/Multipurpose Internet Mail Extensions, is the built-in message encryption standard for Outlook, Apple Mail, and Gmail on Workspace Enterprise. It uses X.509 certificates issued by a trusted certificate authority.
Each user has a public key certificate that is shared with correspondents and a private key that stays local. When someone sends an encrypted message, they encrypt with the recipient public key. Only the recipient private key can decrypt.
Signing is a separate function that uses the same certificates. A signed message includes a signature computed with the sender private key. Any recipient can verify the signature using the sender public key. This proves the message came from the claimed sender and was not modified in transit.
S/MIME suits organizations that can coordinate certificate deployment across all users. Certificate authorities such as DigiCert, Sectigo, and IdenTrust issue certificates for annual fees between roughly $20 and $100 per user.
[mh_example]
PGP Uses Locally Generated Keys and Personal Trust
PGP, or Pretty Good Privacy, is the open-source alternative to S/MIME. It uses public-private key pairs generated locally by the user. There is no certificate authority. Users trust each other keys directly.
The sender exchanges public keys with the recipient through a side channel, verifies the key fingerprint, and then encrypts messages with the recipient public key. The recipient decrypts with their private key. The private key is protected with a passphrase.
PGP has stronger algorithmic flexibility than S/MIME but a steeper learning curve. Recipients unfamiliar with key exchange will not decrypt a PGP message without setup. Thunderbird, Mailvelope, and GPG Suite provide user interfaces that simplify most of the workflow.
PGP suits technical correspondents, security researchers, journalists working with sources, and internal teams that can standardize on key exchange procedures. It is the wrong tool for reaching general external recipients like patients.
Portal-Based Encrypted Email Removes Recipient Setup
Portal-based services solve the recipient friction problem. The sender writes and sends from their normal client. The service intercepts the message, encrypts it, and delivers over TLS when supported or through a portal link when TLS is unavailable.
Mailhippo works this way. The recipient receives a notification email with a click-to-open link. They enter a one-time passcode sent to their phone or email, and they read the message in a browser. No account creation. No key management. No software install.
For HIPAA, the service includes a signed BAA in the base plan and logs every message access. This is the model most healthcare organizations use because patients and external providers cannot be expected to manage keys or install plug-ins.
The tradeoff is that the encryption happens at the service, not on the sender client. For most healthcare and business contexts, this is acceptable because the service holds a BAA and provides audit logs. For extremely sensitive content, S/MIME with local keys remains the highest-assurance model.
Encrypted Email Is Required for Regulated Content
HIPAA, the US health privacy law, requires encryption in transit for any electronic transmission of protected health information across public networks. The rule is technology-neutral, but auditors expect a verified encryption method with a signed business associate agreement.
GLBA, the financial-services privacy law, imposes similar transmission requirements for customer financial data. PCI DSS covers card data. State privacy laws such as CCPA and NYDFS add their own requirements.
Native TLS in Gmail or Outlook does not automatically meet these standards because of the opportunistic fallback. A HIPAA-compliant service closes the gap by refusing to send in plaintext and delivering through a portal fallback when TLS is unavailable.
For healthcare organizations, this pairs with broader compliance work covered in healthcare website security features and healthcare marketing services.
[mh_protip]
Recipient Experience Varies by Encryption Method
The recipient sees a different experience for each method. TLS is invisible when it works. The message arrives in the inbox looking normal. Nothing signals that transport encryption was applied.
S/MIME shows a lock icon in supported clients. The client decrypts using the recipient certificate and displays the plaintext inline. In an unsupported client, the recipient sees ciphertext or an unopenable attachment.
PGP requires a supported client with the recipient private key installed. Thunderbird, Mailvelope, and GPG Suite decrypt inline. Without the tools, the recipient sees a PGP-formatted block of ciphertext.
Portal-based services deliver a notification email with a click-to-open link. The recipient clicks, authenticates with a one-time passcode, and reads in a browser. This is the lowest-friction path for any recipient without prior setup.
Key Management Is the Practical Security Boundary
The mathematics of modern encryption are resistant to brute force with current computing. AES-256 and RSA-2048 are considered secure through the near future. The practical attack surface is key management, not cipher-breaking.
An attacker who steals a private key can decrypt every message sent to that recipient. Key protection includes strong passphrases on private keys, hardware-backed key storage such as smart cards or hardware security modules, and prompt revocation of keys when a device is lost or an employee leaves.
- Store private keys in hardware-backed storage when possible.
- Use strong passphrases on private key files.
- Revoke certificates and PGP keys promptly on departure or device loss.
- Log and monitor key access for anomalous activity.
For portal-based services, the equivalent controls are account access management, multi-factor authentication, and audit logging. The service holds the encryption keys, so the sender must trust the service and verify the audit trail.
Choose an Encryption Method Based on Recipient and Content
The right encryption method depends on the recipient technical setup and the content sensitivity. Match the method to the practical situation.
- Internal team, no regulated content: TLS is sufficient.
- Internal team, regulated content, certified users: S/MIME.
- Technical external correspondents, high sensitivity: PGP.
- External recipients without technical setup, regulated content, HIPAA scope: portal-based service.
For deeper coverage on specific methods, see the sibling guides what does encrypted email mean, what does it mean to encrypt an email, and what happens when you encrypt an email in Outlook.
The one-line summary is that an encrypted email is a message only the intended recipient can read. The method behind that outcome shapes the setup cost, the compliance posture, and the recipient friction. Choose deliberately.
[mh_faqs]
