The one-sentence version#
Email encryption protects messages in transit (TLS between servers, enforced by MTA-STS or DANE) and at rest or end to end (S/MIME, PGP, or portal-based encryption).
Why you should care#
Regulated data (health, financial, personal) requires protection in transit at minimum, and increasingly proof of it.
The mental model#
Think of email encryption as a contract between you and the mailbox providers receiving your mail. You publish or configure something they can check; they check it on every message; the result feeds their decision about where your message lands. Everything below is about making that check pass consistently.
Your first setup, step by step#
- Enforce TLS 1.2+ on inbound and outbound connections.
- Publish MTA-STS to prevent downgrade attacks.
- For regulated content, use S/MIME or a secure-message portal with recipient authentication.
- Log and report TLS failures via TLS-RPT.
Words you will see#
- Mailbox provider: Gmail, Microsoft, Yahoo, Apple, and the corporate gateways that decide where mail lands.
- Authentication: proof that a message is from who it says it is (SPF, DKIM, DMARC).
- Reputation: the provider's running score of your domain and IP.
- Placement: whether a message reaches the inbox, spam, or is rejected.
Common mistakes#
- Assuming 'encrypted' in Gmail means end to end; it usually means TLS in transit.
- Deploying S/MIME without a certificate lifecycle plan.
Frequently asked questions#
Is Gmail encrypted?
Gmail uses TLS in transit and encryption at rest. End-to-end encryption requires S/MIME (Workspace Enterprise) or client-side encryption.