Email Encryption in Transit: TLS, MTA-STS & DANE Explained (2026)

Why Email Encryption in Transit Matters

When you send an email, it travels through multiple servers before reaching the recipient. By default, SMTP (Simple Mail Transfer Protocol) transmits messages in plaintext — meaning anyone who can intercept the traffic between mail servers can read the contents. This includes ISPs, government agencies, and attackers performing man-in-the-middle attacks on public networks.

Transport Layer Security (TLS) solves this by encrypting the connection between mail servers, ensuring that email content cannot be read in transit. However, the way TLS is implemented in email has significant weaknesses that more modern standards like MTA-STS and DANE address.

SMTP and Opportunistic TLS

SMTP was created in 1982 without any encryption. The STARTTLS extension, introduced later, added the ability to upgrade an SMTP connection to TLS. Here is how it works:

1. The sending server connects to the receiving server on port 25.
2. The receiving server advertises STARTTLS support in its EHLO response.
3. The sending server issues the STARTTLS command.
4. Both servers negotiate a TLS handshake and the connection becomes encrypted.
5. The email is transmitted over the encrypted channel.

This is called opportunistic TLS because the sending server will attempt TLS if available, but will fall back to plaintext if the receiving server does not support it or if the TLS negotiation fails. This "best effort" approach means encryption is not guaranteed.

STARTTLS Downgrade Attacks

The opportunistic nature of STARTTLS creates a serious vulnerability: downgrade attacks. An attacker positioned between two mail servers (man-in-the-middle) can:

• Strip the STARTTLS command from the receiving server's EHLO response, making it appear that TLS is not supported. The sending server then transmits the email in plaintext.
• Cause the TLS handshake to fail by injecting errors, forcing the sending server to fall back to unencrypted SMTP.
• Present a fraudulent certificate — since most SMTP servers do not validate certificates by default, the attacker can intercept and decrypt the traffic.

These attacks are not theoretical. Research has shown that STARTTLS stripping occurs on a meaningful percentage of email traffic in certain regions. This is why opportunistic TLS alone is not sufficient for sensitive email communication.

MTA-STS: Enforcing TLS for Email

MTA-STS (Mail Transfer Agent Strict Transport Security) is a mechanism that allows a domain to declare that it supports TLS and that sending servers should refuse to deliver email if a secure connection cannot be established. It eliminates the fallback-to-plaintext weakness of opportunistic TLS.

MTA-STS works through two components:

1. A DNS TXT record at _mta-sts.yourdomain.com that signals MTA-STS support and includes a version ID for cache busting.
2. An HTTPS-hosted policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt that specifies the policy mode (enforce, testing, or none), the valid MX hostnames, and a max age for caching.

When a sending server encounters an MTA-STS policy in enforce mode, it will only deliver email over a TLS connection with a valid certificate. If TLS fails, the email is not delivered at all — preventing downgrade attacks. You can verify your MTA-STS configuration with our MTA-STS Checker.

DANE and TLSA Records

DANE (DNS-Based Authentication of Named Entities) is an alternative to MTA-STS that uses DNSSEC to bind TLS certificates to DNS records. Instead of relying on certificate authorities, DANE publishes TLSA records in DNS that specify exactly which certificate (or CA) a mail server should present.

A TLSA record is published at a specific DNS name based on the port and protocol, for example: _25._tcp.mail.yourdomain.com. The record contains a hash of the expected certificate or public key. When a sending server connects and sees a TLSA record (via DNSSEC-validated DNS), it verifies that the certificate presented matches the TLSA record.

DANE has a key advantage: it does not depend on the web PKI (certificate authority system). However, it requires DNSSEC to be enabled for the domain, which limits its adoption. Many large email providers support DANE when DNSSEC is available.

TLSRPT: TLS Reporting

TLSRPT (SMTP TLS Reporting) is a companion standard to MTA-STS and DANE. It allows sending mail servers to report back to domain owners about TLS connection successes and failures when delivering email to their domain.

TLSRPT is configured by publishing a DNS TXT record at _smtp._tls.yourdomain.com that specifies where to send reports (via email or HTTPS). The reports are JSON-formatted and include information about:

• Total successful TLS connections to your mail servers.
• Failed TLS negotiations and the specific error types (certificate expired, hostname mismatch, STARTTLS not supported).
• MTA-STS policy validation failures.
• DANE TLSA validation failures.

TLSRPT is essential for monitoring your MTA-STS or DANE deployment. Without it, you have no visibility into whether sending servers are successfully connecting over TLS or encountering errors.

How to Check Your Email Encryption Setup

Verifying your email encryption configuration involves checking several components. Use our free tools to audit your setup:

• MTA-STS Checker — Verify your MTA-STS DNS record and HTTPS policy file, including mode, MX hostnames, and max age.
• SSL Checker — Check the SSL/TLS certificate on your mail server and web server for validity, expiration, and chain issues.
• Domain Health Check — Get a comprehensive overview of your domain's email and DNS security configuration, including TLS status.

MTA-STS vs DANE: Which Should You Use?

Both MTA-STS and DANE solve the same problem — preventing TLS downgrade attacks — but they take different approaches:

• MTA-STS uses HTTPS to host the policy and does not require DNSSEC. It is easier to deploy and works with any domain. However, it relies on the web PKI and has a TOFU (trust on first use) model.
• DANE uses DNSSEC and TLSA records for certificate pinning. It provides stronger cryptographic guarantees but requires DNSSEC, which many domains do not have enabled.

For most organizations, MTA-STS is the practical choice because it does not require DNSSEC. If your domain already has DNSSEC enabled, consider deploying DANE as well for defense in depth. Both standards can coexist — sending servers that support DANE will use it, while others fall back to MTA-STS.