Skip to content

Home Topics Email Security Management Email encryption

Email Security Management · Email encryption

Email encryption examples: what good and bad look like

Short answer

A good email encryption implementation follows these steps: Enforce TLS 1.2+ on inbound and outbound connections; Publish MTA-STS to prevent downgrade attacks. A bad one typically assuming 'encrypted' in Gmail means end to end; it usually means TLS in transit.

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

What good looks like#

  • Done: Enforce TLS 1.2+ on inbound and outbound connections.
  • Done: Publish MTA-STS to prevent downgrade attacks.
  • Done: For regulated content, use S/MIME or a secure-message portal with recipient authentication.
  • Done: Log and report TLS failures via TLS-RPT.

What bad looks like#

  • Seen in audits: Assuming 'encrypted' in Gmail means end to end; it usually means TLS in transit.
  • Seen in audits: Deploying S/MIME without a certificate lifecycle plan.

How to move from bad to good#

Work through the good list in order and re-verify after each change. Most teams find one or two items from the bad list already present; fixing those usually produces the largest improvement.

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.

Keep reading on Email encryption