MTA-STS vs DANE: Choosing How to Enforce TLS for Inbound Email

MTA-STS and DANE solve the same problem from opposite directions. By default, SMTP encryption with STARTTLS is opportunistic: a sending mail server will use TLS if offered, but it will silently fall back to plaintext if the handshake fails or an attacker strips the STARTTLS offer. Both MTA-STS and DANE close that gap by letting a receiving domain declare, in a way senders can verify, that inbound mail must use valid TLS. The difference is the trust anchor. MTA-STS leans on the web PKI and an HTTPS-hosted policy file; DANE pins certificates or keys directly in DNS and depends on DNSSEC. This guide compares the two so you can pick the right one, or run both.

What each protocol actually does

MTA-STS (RFC 8461)

MTA-STS has two moving parts. First, a DNS discovery record tells senders a policy exists:

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20261013T090000"

Second, senders fetch a policy file over HTTPS from a fixed location on a subdomain:

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800

The id in the TXT record is a version tag. When you change the policy, you bump the id so senders know to refetch. The policy is validated using the public web PKI: the certificate on mta-sts.example.com must be publicly trusted, and the MX hostnames the sender connects to must present certificates valid for a name listed in the mx: set. The mode field is the lever: testing reports failures but still delivers, while enforce refuses to deliver if TLS cannot be validated.

DANE (RFC 7672)

DANE uses a single record type, TLSA, published per MX host under the SMTP port and protocol. There is no HTTPS file. The TLSA record pins the server certificate or, more commonly, its public key:

_25._tcp.mx1.example.com.  IN  TLSA  3 1 1 \
  (d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971)

The three numbers are usage, selector, and matching type. For SMTP the recommended combination is 3 1 1: usage 3 (DANE-EE, pin the end-entity certificate itself), selector 1 (match the SubjectPublicKeyInfo, so the pin survives certificate renewal as long as the key is reused), and matching type 1 (SHA-256 hash). The critical prerequisite is DNSSEC. A DANE-aware sender resolves your MX and TLSA records with DNSSEC validation; conforming senders ignore any TLSA record that is not covered by a valid DNSSEC chain. Without a signed zone, DANE is invisible.

Verify a TLSA record the same way senders find it:

$ dig +dnssec TLSA _25._tcp.mx1.example.com +short
3 1 1 D2ABDE240D7CD3EE6B4B28C54DF034B97983A1D16E8A410E4561CB106618E971

Side-by-side comparison

Deployment prerequisites

The practical deciding factor is often what you already have. Each protocol asks for something different from your infrastructure.

• MTA-STS needs a web host. You must serve a static file over HTTPS on mta-sts.yourdomain with a publicly trusted certificate. That is easy for most teams, which is why big providers adopted MTA-STS quickly. You do not need to touch DNSSEC.
• DANE needs DNSSEC end to end. Your registrar and DNS host must support signing, you must publish a DS record in the parent zone, and the chain must validate. If your DNS platform or TLD does not support DNSSEC, DANE is not an option until that changes.

Failure modes and tradeoffs

The security models differ most in how they fail. MTA-STS is trust-on-first-use: a sender that has never seen your policy, and cannot fetch it (for example the HTTPS host is down), may fall back to opportunistic TLS. An attacker who can block the policy fetch on the very first contact can sidestep enforcement. Once a sender has cached your policy for the max_age window, that window is protected, but the initial fetch and expiry create gaps.

DANE has no first-use gap because the TLSA pin is verified on every connection through DNSSEC. The flip side is that DANE is fail-closed and brittle to operational mistakes: if your DNSSEC signatures expire, your DS record is wrong, or your TLSA hash does not match the live certificate, DANE-aware senders will refuse to deliver mail rather than fall back. A rushed certificate change that does not update the TLSA record can stop inbound mail from DANE senders. This is why selector 1 (pin the public key) is preferred, since reusing the key across renewals keeps the pin valid.

Sender support

Support shapes real-world coverage. Large mailbox providers including Google and Microsoft honor MTA-STS, so a published MTA-STS policy protects a large share of your inbound mail. DANE has long been championed in parts of Europe and by providers that have invested in DNSSEC, and Microsoft has rolled out inbound and outbound SMTP DANE. Neither is universal, so publishing one does not force every sender to use it; senders that support neither simply fall back to opportunistic TLS.

Which should you choose?

These two are not mutually exclusive, and the strongest posture is to run both. MTA-STS covers the large PKI-based providers; DANE covers the DNSSEC-validating ones. A sender uses whichever it supports. Whichever you deploy, turn on TLS-RPT so you get visibility into what is actually happening:

_smtp._tls.example.com.  IN  TXT  \
  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

TLS-RPT delivers daily aggregate reports of successful and failed TLS sessions, which is how you catch a broken DANE pin or an unreachable MTA-STS policy before it quietly costs you mail. Start MTA-STS in testing mode, watch the reports, and only move to enforce once they are clean. Introduce DANE only after DNSSEC is proven stable.

Before you flip either policy to enforcement, confirm your records resolve the same way everywhere with the Valla DNS propagation checker, and browse the Valla DNS learning hub for our companion guides on MTA-STS and TLS-RPT setup, DNSSEC, and reading your DMARC and TLS reports.