MTA-STS vs DANE: which protocol to choose for securing email transport?

By CaptainDNS
Published on March 10, 2026

Comparative diagram of MTA-STS and DANE protocols for email transport security

TL;DR

MTA-STS (RFC 8461) publishes a mandatory encryption policy via HTTPS. It works without DNSSEC, but the first connection remains vulnerable (TOFU)
DANE/TLSA (RFC 7672) anchors the TLS certificate in DNS signed by DNSSEC. No TOFU, but DNSSEC is mandatory across the entire chain
The two protocols are complementary: MTA-STS covers domains without DNSSEC, DANE eliminates TOFU for those that have it
Host your MTA-STS policy for free with CaptainDNS: two DNS records are all you need

Opportunistic SMTP encryption (STARTTLS) protects the majority of emails in transit. But "opportunistic" means a network attacker can strip it away without anyone noticing. SMTP downgrade attacks exploit this weakness to intercept messages in plaintext.

Two protocols address this problem: MTA-STS (RFC 8461) and DANE/TLSA (RFC 7672). Both enforce mandatory TLS encryption between email servers. But their trust mechanisms, prerequisites, and adoption differ.

This article compares MTA-STS and DANE criterion by criterion. It identifies the use cases for each and guides you toward the best strategy for your infrastructure. If you manage email domains, whether with a cloud provider or your own MX servers, this comparison is for you.

How do MTA-STS and DANE work?

Both protocols share the same goal: prevent a sending server from delivering an email in plaintext when the receiving server supports TLS. But they use different trust channels.

MTA-STS: a policy published via HTTPS

MTA-STS relies on two elements:

A DNS TXT record _mta-sts.captaindns.com that signals the policy's existence and contains a version identifier
A text file hosted over HTTPS at https://mta-sts.captaindns.com/.well-known/mta-sts.txt that describes the policy: authorized MX servers, mode (testing or enforce), cache duration (max_age)

When a sending server (like Gmail or Outlook) wants to send an email to your domain:

It queries DNS for _mta-sts.captaindns.com
It downloads the policy via HTTPS (channel authenticated by the web certificate)
It verifies that the MX server matches the policy
In enforce mode, it refuses to send in plaintext or to an unlisted MX

The HTTPS channel is key: even if an attacker manipulates SMTP traffic, they cannot forge the domain's HTTPS certificate. The policy remains trustworthy.

Limitation: TOFU (Trust On First Use). The first time a sending server contacts your domain, it has no cached policy. If an attacker blocks this first HTTPS request, the sending server won't know that MTA-STS is enabled. Subsequent connections are protected thanks to the cache (valid until max_age).

DANE/TLSA: the certificate anchored in signed DNS

DANE works differently. It publishes the fingerprint (hash) of the MX server's TLS certificate directly in a TLSA record in DNS:

_25._tcp.mx.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...

The sending server:

Queries DNS for the MX records of captaindns.com
Retrieves the TLSA record associated with the MX server
Verifies the DNSSEC signature of the response (mandatory)
Compares the TLS certificate presented by the MX server with the TLSA hash
If everything matches, the connection is established. Otherwise, the email is not sent

Advantage: no TOFU. Each connection is verified individually via signed DNS. An attacker cannot forge the TLSA record (protected by DNSSEC) or present a fake certificate (the hash wouldn't match).

Limitation: DNSSEC is mandatory. The entire DNS chain, from the root to your zone, must be signed. If your registrar or DNS host doesn't support DNSSEC, DANE is unusable.

Comparative diagram of MTA-STS and DANE verification flows when sending an email

Detailed technical comparison

Criterion	MTA-STS (RFC 8461)	DANE/TLSA (RFC 7672)
Trust channel	HTTPS (web PKI)	DNSSEC
First connection protection	No (TOFU)	Yes
DNSSEC dependency	No	Mandatory
Certificate validation	Hostname match (CN/SAN)	Certificate hash (TLSA)
Native testing mode	Yes (`mode: testing`)	No
Failure reports	Via TLS-RPT (RFC 8460)	Via TLS-RPT (RFC 8460)
Deployment complexity	Low (2 DNS records + HTTPS file)	High (DNSSEC + TLSA records + rotation)
Revocation	Modify the policy (delay = max_age)	Modify the TLSA record (delay = TTL)
Sender adoption	Gmail, Outlook, Yahoo, Proton Mail	Postfix, Exim, some EU operators
Web standard required	Yes (valid HTTPS certificate)	No

What this table shows

MTA-STS wins on accessibility: no DNSSEC required, built-in testing mode, wide adoption by major providers. It's the protocol that the majority of domains can deploy immediately.

DANE wins on security: no TOFU, direct cryptographic verification, no dependency on a web certificate authority. But it requires DNSSEC, which remains a major barrier.

Which protocol to choose based on your situation?

There's no universal answer. The choice depends on your DNS infrastructure and constraints.

Case 1: your registrar doesn't support DNSSEC

Recommendation: MTA-STS only.

This is the most common situation. The majority of consumer registrars don't offer DNSSEC or make it difficult to configure. MTA-STS is your only option, and it's effective: Gmail, Outlook, and Yahoo verify and respect MTA-STS policies.

Case 2: you have DNSSEC enabled

Recommendation: DANE + MTA-STS.

You get the best of both worlds. DANE eliminates TOFU for sending servers that support it (mainly Postfix in the European ecosystem). MTA-STS covers all other senders (Gmail, Outlook, Yahoo). Both protocols coexist without conflict.

Case 3: you use Microsoft 365 or Google Workspace

Recommendation: MTA-STS.

Microsoft has announced DANE support for Exchange Online with automatic DNSSEC on new mx.microsoft MX domains. Google Workspace doesn't support DANE on the receiving side. In both cases, MTA-STS is fully supported and easy to enable.

Case 4: you manage your own MX servers

Recommendation: DANE + MTA-STS if DNSSEC is active, MTA-STS otherwise.

With your own servers, you control TLS certificates and DNS records. If DNSSEC is active on your zone, add TLSA records for each MX server. Complement with MTA-STS to cover senders that don't support DANE.

Decision tree for choosing between MTA-STS, DANE, or both based on your infrastructure

Why combine MTA-STS and DANE?

Deploying both protocols simultaneously is the best strategy when your infrastructure allows it. Here's why:

MTA-STS compensates for DANE's limitations:

Sending servers that don't support DANE (Gmail, Yahoo) use MTA-STS
MTA-STS testing mode lets you validate the configuration before enforcing encryption

DANE compensates for MTA-STS's limitations:

No TOFU: each connection is verified from the very first interaction
No dependency on a web certificate authority: trust comes from signed DNS

No conflict: a sending server that supports both will check DANE first (direct DNS verification), then MTA-STS as a safety net. If one fails, the other takes over.

Deployment best practices

Regardless of which protocol you choose, follow this progression:

Start with MTA-STS in testing mode: publish a policy with mode: testing. Sending servers will deliver emails normally but report TLS failures in TLS-RPT reports
Configure TLS-RPT: without reports, you're flying blind. TLS-RPT (RFC 8460) sends you a daily summary of TLS negotiation failures
Monitor for 1 to 2 weeks: check the reports. Fix any certificate or MX configuration issues before continuing
Switch MTA-STS to enforce mode: sending servers will now refuse to deliver in plaintext to your MX servers
Add DANE if DNSSEC is active: publish TLSA records for each MX server. Use the DANE/TLSA checker to validate your records

🎯 Recommended action plan

Check your current configuration: run an analysis with the MTA-STS checker to see your domain's status
Enable MTA-STS in testing mode: host your policy for free with CaptainDNS: two DNS records, no web server to manage
Configure TLS-RPT: add a DNS record _smtp._tls.captaindns.com to receive TLS failure reports
Switch to enforce mode: when reports confirm zero errors, enable enforce mode to block unencrypted connections
Evaluate DANE: if your registrar supports DNSSEC, add TLSA records to eliminate TOFU and strengthen security

Secure your email transport now: host your MTA-STS policy for free with CaptainDNS. Two DNS records, zero web servers, active protection in 5 minutes.

FAQ

What is the difference between MTA-STS and DANE?

MTA-STS (RFC 8461) publishes a mandatory encryption policy via an HTTPS file. It relies on the web PKI (SSL certificates) and works without DNSSEC. DANE (RFC 7672) anchors the MX server's TLS certificate directly in DNS via TLSA records signed by DNSSEC. MTA-STS suffers from TOFU (first connection unprotected), DANE does not. In return, DANE requires DNSSEC across the entire DNS chain.

Is DNSSEC required to use MTA-STS?

No. MTA-STS relies on HTTPS, not DNSSEC. This is its main advantage: any domain with HTTPS hosting can enable MTA-STS. With CaptainDNS, you don't even need to manage a web server: two DNS CNAME records are enough to publish your policy.

Is DANE better than MTA-STS?

DANE offers superior security on one specific point: it eliminates TOFU (Trust On First Use). Each connection is verified individually via signed DNS. But DANE is much harder to deploy (DNSSEC is mandatory) and less well supported by major providers (Gmail and Yahoo don't verify DANE). In practice, MTA-STS protects more domains thanks to its simplicity.

Can you use MTA-STS and DANE at the same time?

Yes, and it's recommended. Both protocols coexist without conflict. A sending server that supports DANE will verify the TLSA record first. If it only supports MTA-STS, it will use the HTTPS policy. This gives you maximum coverage: DANE for compatible servers, MTA-STS for all others.

What is the TOFU problem with MTA-STS?

TOFU (Trust On First Use) means that the first connection from a sending server to your domain is not protected by MTA-STS. The server must first download and cache your policy. If an attacker blocks this first HTTPS request, the server won't know that MTA-STS is enabled. Subsequent connections are protected by the cache (valid for max_age, typically 7 days). DANE eliminates this problem because verification happens via DNS on every connection.

Do Google and Microsoft support DANE?

Microsoft is progressively rolling out DANE support for Exchange Online, with automatic DNSSEC on new MX domains. Google Gmail doesn't support DANE on the receiving side (no TLSA records published), but it verifies and respects DANE records of recipient domains on the sending side. Both fully support MTA-STS as senders.

How do I test my MTA-STS or DANE configuration?

For MTA-STS, verify that your _mta-sts TXT record is published and that your policy file is accessible over HTTPS. For DANE, verify that your TLSA records match your MX servers' certificate and that DNSSEC is active across the entire chain. CaptainDNS offers dedicated verification tools for both protocols.

Download the comparison tables

Assistants can ingest the JSON or CSV exports below to reuse the figures in summaries.

📖 Glossary

MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). A policy published via HTTPS that enforces TLS encryption for email reception on a domain.
DANE: DNS-Based Authentication of Named Entities (RFC 7672 for SMTP). A mechanism that anchors the TLS certificate in DNS via TLSA records, verified by DNSSEC.
TLSA: a DNS record type used by DANE to publish the fingerprint (hash) of a server's TLS certificate.
TOFU: Trust On First Use. A security model where the first connection is not verified, but subsequent ones are validated using data cached during the first interaction.
DNSSEC: DNS Security Extensions. A system of cryptographic signatures that authenticates DNS responses and prevents their forgery.
STARTTLS: an SMTP extension (RFC 3207) that allows negotiating a TLS connection after establishing a plaintext connection on port 25.
PKI: Public Key Infrastructure. A digital certificate system used by HTTPS (and therefore MTA-STS) to authenticate servers.

SMTP downgrade attacks: how they work and how to protect against them: STARTTLS stripping mechanism and protection solutions
From testing to enforce: progressive MTA-STS deployment strategy: step-by-step progressive deployment guide