# Is my email encrypted in transit? STARTTLS, MTA-STS and DANE explained

URL: https://iblockspam.com/blog/starttls-email-encryption-in-transit
Last updated: 2026-10-09
Published: 2026-10-09
Topic: Email security basics
Author: iBlockSpam Team

> What STARTTLS does for email, why opportunistic TLS can be downgraded, how MTA-STS and DANE enforce it, what Gmail's lock icons mean, and where TLS stops.

## Short answer

STARTTLS upgrades a connection between two mail servers to TLS, so a message can't be read on the wire. By default it is opportunistic: if TLS fails, most servers send in plain text, and an attacker can strip the offer. MTA-STS and DANE make TLS mandatory. TLS protects each hop only; S/MIME or PGP encrypt the message itself.

When you send an email, it usually crosses the internet between at least two mail servers. Whether anyone in between can read it depends on transport encryption, normally STARTTLS. This guide explains what STARTTLS protects, how it can be downgraded, how MTA-STS and DANE close that gap, what Gmail's lock icons mean, and what TLS can't do for you.

## What is STARTTLS?

SMTP, the protocol mail servers use to talk to each other, was designed without encryption. [RFC 3207](https://www.rfc-editor.org/rfc/rfc3207.html), published in 2002, added STARTTLS: a sending server connects in plain text, sees that the receiving server advertises `250 STARTTLS`, and asks to upgrade the same connection to TLS. Everything after that, including the message, travels encrypted.

This guide is about server-to-server delivery: the connection a sending mail server makes to your MX host on port 25.

Microsoft summarizes the scope well: "TLS doesn't encrypt the message, just the connection" ([Microsoft Learn](https://learn.microsoft.com/en-us/purview/exchange-online-uses-tls-to-secure-email-connections)). Once the message arrives, it's stored as the server received it.

## Why is STARTTLS called "opportunistic"?

Because the sender uses TLS when it can and plain text when it can't. Google puts it this way: "SMTP security is optional, and internet standards require that SMTP accept plain text connections," and "if a TLS connection can't be created, servers often send the message anyway" ([Google Workspace Admin Help](https://knowledge.workspace.google.com/admin/gmail/advanced/about-mta-sts-and-tls-reporting)).

That's a deliberate design choice. RFC 3207 says: "A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally." Requiring it would cut off older senders.

Large providers follow the same model by default. Microsoft says Exchange Online "always uses opportunistic TLS," and that unless you configure otherwise, "Exchange sends the message without encryption if the recipient's organization doesn't support TLS encryption."

## What is a STARTTLS downgrade attack?

Opportunistic TLS has two weaknesses an attacker on the network path can use.

### Stripping the STARTTLS offer

The first step of the conversation happens in plain text. RFC 3207 warns: "A man-in-the-middle attack can be launched by deleting the '250 STARTTLS' response from the server." The sender thinks the receiver doesn't support TLS and falls back to plain text, exactly as designed.

### Redirecting to the wrong server

The sender finds your mail server through an MX lookup in DNS. [RFC 7672](https://www.rfc-editor.org/rfc/rfc7672.html) describes pre-DANE opportunistic TLS as "generally vulnerable to DNS forgery and STARTTLS downgrade attacks," and notes that "MX record indirection generally precludes authentication even when TLS is available." In plain terms: a sender using opportunistic TLS doesn't usually check that the certificate belongs to the right server, so an impostor server with any certificate can receive the mail.

| Mode | Encrypted? | Server identity checked? | Falls back to plain text? |
|---|---|---|---|
| No TLS | No | No | n/a |
| Opportunistic STARTTLS | Usually | Usually not | Yes |
| MTA-STS (enforce) | Yes | Yes, against public certificate authorities | No, the sender won't deliver |
| DANE | Yes | Yes, against DNSSEC-signed TLSA records | No, for servers with valid TLSA records |
| Forced TLS connector (one partner) | Yes | Yes, as configured | No |

## How do MTA-STS and DANE enforce TLS?

Both let a receiving domain tell senders "only deliver to me over verified TLS." They differ in how that promise is published and trusted.

### MTA-STS

[RFC 8461](https://www.rfc-editor.org/rfc/rfc8461.html) lets a domain declare that senders "should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate." You publish a `_mta-sts` TXT record and a policy file at `https://mta-sts.<your-domain>/.well-known/mta-sts.txt` listing your MX hosts. It uses ordinary certificate authorities and doesn't need DNSSEC, which RFC 8461 says comes "at a cost of risking malicious downgrades." It also has a testing mode for safe rollout.

Gmail honors it for outgoing mail: Google says messages "comply with MTA-STS when sent to external servers with an MTA-STS policy in enforced mode." Our [MTA-STS and TLS-RPT guide](https://iblockspam.com/blog/mta-sts-tls-rpt-explained) covers the records and rollout step by step.

### DANE for SMTP

RFC 7672 describes "a downgrade-resistant protocol for SMTP transport security" based on TLSA records in DNS. It requires DNSSEC on your zone. The RFC notes that DNSSEC-validated TLSA records "MUST NOT be published for servers that do not support TLS," so senders can treat them as a firm commitment.

Microsoft says outbound SMTP DANE with DNSSEC is "ON by default for all Exchange Online customers," and is used "when the destination domain advertises support for DANE" ([Microsoft Learn](https://learn.microsoft.com/en-us/exchange/security-and-compliance/how-dane-secures-email)).

### Which should you choose?

RFC 8461 says MTA-STS exists for domains where "deploying DNSSEC is undesirable or impractical," and that senders "MUST NOT allow MTA-STS Policy validation to override a failing DANE validation." The RFC's security section also notes that resistance to downgrade attacks on policy discovery "is a feature of DANE, due to its use of DNSSEC." If your DNS host supports DNSSEC and you're comfortable running it, DANE is worth considering. Otherwise, MTA-STS is the practical choice for most small businesses, and the two can be deployed together.

Adoption is still low. In [our October 2026 scan of the Tranco top 1,000 domains](https://iblockspam.com/research/email-security-top-1000), only 5.1% of domains that receive mail published an MTA-STS record.

## What do Gmail's lock icons mean?

Gmail shows the encryption used for each message. According to Google's help pages ([how Gmail encrypts](https://support.google.com/mail/answer/6330403?hl=en) and [check your email security](https://support.google.com/mail/answer/7039474?hl=en)):

| Icon | Google's name | What it means |
|---|---|---|
| Gray lock | Standard encryption | TLS protected the message in transit. "For TLS to work, the email providers for both the sender and recipient must use TLS." |
| Red open lock | No encryption | "The message is unencrypted." Google advises not sending sensitive information and letting the sender know. |
| Green lock | Enhanced encryption | Hosted S/MIME. "Google securely manages a copy of your key." Work or school accounts only. |
| Blue shield | Additional encryption | Client-side encryption, where "your organization holds the only copy of the key." |

To check a received message, open it and select **Show details** next to the recipient. Google also notes you may see a warning even when mail is encrypted, for example if encryption "hasn't worked for a specific email provider in the past."

On a message you received, a red open lock means it reached Gmail without TLS. Google says: "If a sender's email provider doesn't support TLS, the email may not be encrypted." The icon says nothing about whether the message is genuine. For that, check authentication results; our guide to [reading email headers](https://iblockspam.com/blog/how-to-read-email-headers) explains how.

## How do you check whether your mail servers use TLS?

### 1. Look at the Received headers

Each server adds a `Received:` header. [RFC 3848](https://www.rfc-editor.org/rfc/rfc3848.html) defines `with ESMTPS` to mean STARTTLS was "successfully negotiated." `ESMTPSA` also means TLS (plus SMTP authentication). Plain `with ESMTP` usually means that hop wasn't encrypted. Paste the headers into the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer), which runs in your browser, to see every hop.

### 2. Test your MX hosts directly

Find your MX hosts with the [MX Lookup](https://iblockspam.com/tools/mx-lookup), then test one from a machine that can reach port 25:

```
openssl s_client -connect mx1.example.com:25 -starttls smtp -servername mx1.example.com
```

Check that the handshake succeeds, the certificate is valid, and the certificate name matches the MX hostname. A name mismatch doesn't stop opportunistic TLS, but it will break MTA-STS or DANE once you enforce them. If the connection times out, your network may block outbound port 25; try from a server instead.

### 3. Check your policies

Use the [MTA-STS Checker](https://iblockspam.com/tools/mta-sts-checker) to validate your policy record and file, and the [Email Health Check](https://iblockspam.com/tools/email-health-check) for an overall view of MX, authentication and transport security. Add TLS-RPT so senders report TLS failures to you.

### 4. Check your outbound side

Your users' mail is only as protected as your sending servers make it. Confirm your provider or relay uses STARTTLS for outbound mail and validates MTA-STS or DANE where the recipient publishes them.

## Where does TLS stop protecting you?

Be clear with users about what transport encryption doesn't do:

- **It's hop by hop.** RFC 3207 says "SMTP is not an end-to-end mechanism." Each server along the path decrypts, handles and re-sends the message. If any hop falls back to plain text, that hop is exposed.
- **It doesn't protect stored mail.** Messages sit in readable form on the sending and receiving providers' systems.
- **It doesn't survive forwarding.** Microsoft notes that if you forward a TLS-protected message to an organization that doesn't support TLS, "that message isn't necessarily encrypted."
- **It doesn't prove who sent it.** TLS protects the channel. SPF, DKIM and DMARC deal with sender identity; see [SPF vs DKIM vs DMARC](https://iblockspam.com/blog/spf-vs-dkim-vs-dmarc).

### When you need end-to-end encryption

For contracts, health data or anything that must stay private beyond the wire, encrypt the message itself (medical and dental practices can see how this fits HIPAA's transmission security standard on our [healthcare page](https://iblockspam.com/solutions/healthcare)):

- **S/MIME** ([RFC 8551](https://www.rfc-editor.org/rfc/rfc8551.html)) uses certificates and is built into many business mail clients. Gmail offers hosted S/MIME for work and school accounts.
- **OpenPGP** ([RFC 9580](https://www.rfc-editor.org/rfc/rfc9580.html)) uses key pairs you manage yourself.

Both require the recipient to have a compatible key and client, which is why most business mail still relies on TLS alone. Microsoft points to Microsoft Purview Message Encryption or S/MIME when you need to encrypt the message contents.

## Next steps

1. Run your domain through the [Email Health Check](https://iblockspam.com/tools/email-health-check) and test each MX host's certificate.
2. Publish TLS-RPT and MTA-STS in testing mode, then move to enforce once reports are clean. Our [MTA-STS rollout guide](https://iblockspam.com/blog/mta-sts-tls-rpt-explained) has the steps.
3. If your DNS host supports DNSSEC, consider DANE as well.
4. Agree a rule for sensitive data: if it must stay private at rest, use S/MIME, OpenPGP or a secure portal, not plain email. If your MX records point to a filtering gateway, ask the provider whether its MX hosts support STARTTLS with certificates that match their names, since those are the hosts senders connect to. See [how iBlockSpam works](https://iblockspam.com/how-it-works) for how MX-level filtering fits in front of your mailboxes.

Read more [email security basics](https://iblockspam.com/blog/topic/basics).

## Frequently asked questions

### Is email encrypted by default?

Usually in transit, but not guaranteed. Major providers try STARTTLS on every connection, and Gmail says almost all major email services use TLS. But TLS for SMTP is opportunistic by default: if the other server doesn't offer it, or the offer is stripped, most servers deliver the message unencrypted anyway.

### What does the red open padlock in Gmail mean?

Google says a red open lock icon means the message is unencrypted. Gmail's advice is not to send sensitive information in that conversation and to let the sender know. A gray lock means standard TLS encryption in transit, and a green lock means hosted S/MIME, which Google calls enhanced encryption.

### What is the difference between STARTTLS and end-to-end encryption?

STARTTLS encrypts the connection between two servers. Each server along the way can read the message, and it is stored in readable form at the provider. End-to-end encryption, such as S/MIME or OpenPGP, encrypts the message itself so only the recipient's key can open it, wherever it is stored or relayed.

### Should my mail server require TLS for all incoming mail?

Not for a public MX. RFC 3207 says a publicly referenced SMTP server must not require STARTTLS to deliver mail locally, because some senders still don't support it. Instead, publish MTA-STS or DANE so capable senders must use TLS, and use forced-TLS connectors only with specific partners.

### Do MTA-STS and DANE do the same thing?

They have the same goal: stop senders falling back to plain text or an impostor server. MTA-STS uses a policy file on HTTPS and normal certificate authorities, and doesn't need DNSSEC. DANE publishes certificate details in DNS and requires DNSSEC. RFC 8461 says MTA-STS must not override a failing DANE check.

## Sources

- [RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security](https://www.rfc-editor.org/rfc/rfc3207.html)
- [RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)](https://www.rfc-editor.org/rfc/rfc8461.html)
- [RFC 7672: SMTP Security via Opportunistic DANE TLS](https://www.rfc-editor.org/rfc/rfc7672.html)
- [Gmail Help: Learn how Gmail encrypts your emails](https://support.google.com/mail/answer/6330403?hl=en)
- [Gmail Help: Check your email security](https://support.google.com/mail/answer/7039474?hl=en)
- [Microsoft Learn: How Exchange Online uses TLS to secure email connections](https://learn.microsoft.com/en-us/purview/exchange-online-uses-tls-to-secure-email-connections)
- [Microsoft Learn: How SMTP DNS-based Authentication of Named Entities (DANE) works](https://learn.microsoft.com/en-us/exchange/security-and-compliance/how-dane-secures-email)
- [Google Workspace Admin Help: About MTA-STS and TLS reporting](https://knowledge.workspace.google.com/admin/gmail/advanced/about-mta-sts-and-tls-reporting)

## Free tools for this guide

- [MTA-STS Checker](https://iblockspam.com/tools/mta-sts-checker): Fetch and validate your MTA-STS policy, match it to your MX hosts and check TLS-RPT.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.
- [MX Lookup](https://iblockspam.com/tools/mx-lookup): See where your mail is delivered, spot unfiltered backup MX and broken hosts.

---

Source: iBlockSpam, https://iblockspam.com/blog/starttls-email-encryption-in-transit (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt