MTA-STS and DANE exist to solve the same weakness: SMTP's TLS is opportunistic, so an attacker positioned on the network path can strip the STARTTLS offer and force mail to be delivered in plaintext, with neither end the wiser. Both mechanisms let a receiving domain declare "my mail must arrive over authenticated TLS, and here is how to be sure you are really talking to me." Where they differ — profoundly — is in what they anchor that promise to. Understanding that difference is what tells you whether to deploy one, the other, or both.
How MTA-STS enforces TLS
MTA-STS anchors its promise in the Web PKI — the same certificate authorities and HTTPS trust that browsers use. A sender discovers the policy through a DNS TXT record at _mta-sts.yourdomain, then fetches a policy file over HTTPS from https://mta-sts.yourdomain/.well-known/mta-sts.txt. That file lists the permitted mx hosts, a mode of testing or enforce, and a max_age. Under enforce, the sender will only deliver if it can open TLS to a listed MX whose certificate is valid, unexpired, publicly-rooted and matches the MX hostname.
The trust chain here runs through HTTPS: the sender trusts the policy because it was served over a valid certificate for the mta-sts host, and it trusts the MX because that host presents a valid CA-issued certificate. DNS itself is not required to be secure — MTA-STS was deliberately designed to work without DNSSEC, which is much of why it is easy to deploy. The cost of that design is a caching-based trust-on-first-use property: a sender caches your policy for up to max_age, and there is a narrow first-contact window, before any policy is cached, in which an attacker who can also block the HTTPS fetch could suppress the policy.
How DANE enforces TLS
DANE (DNS-Based Authentication of Named Entities) anchors its promise in DNSSEC instead. The receiving domain publishes a TLSA record — for SMTP, at _25._tcp.mx-hostname — that contains a cryptographic commitment to the MX's certificate or public key. A sending MTA looks up the MX, then looks up the TLSA record, and requires TLS whose certificate matches the TLSA data. Because the whole lookup is protected by DNSSEC, the sender can trust that the TLSA record — and therefore the requirement to use TLS at all — genuinely came from the domain owner and was not stripped or forged in transit.
The consequence is a different, arguably stronger, trust model. DANE does not depend on the Web PKI at all: a domain can pin its own certificate, including a self-signed or privately-issued one, because trust comes from DNSSEC rather than from a public CA. There is also no trust-on-first-use gap — every connection is validated against a signed record, so there is no cached-policy window to exploit. The price is a hard prerequisite: DANE is meaningless without DNSSEC. If your zone is not signed, you cannot deploy DANE, and DNSSEC is a non-trivial operational commitment with its own key-management and failure modes.
The trust models side by side
The clean way to hold the distinction: MTA-STS trusts certificate authorities plus a cached policy; DANE trusts a DNSSEC-signed record. MTA-STS is easy to adopt because it rides on infrastructure almost everyone already has — public certificates and HTTPS — but it inherits the Web PKI's trust assumptions and has the first-contact caching caveat. DANE removes both of those by moving the anchor into signed DNS, but it demands that you run DNSSEC correctly, because a broken signature does not fail open — it can stop mail.
They also differ in how a sender supports them, and this matters practically. Some large senders honour MTA-STS; some honour DANE; the overlap is imperfect. Which of your correspondents will actually enforce TLS to you depends on which mechanism they implement, not only on which you publish.
When to use which
If your zone is not DNSSEC-signed and you want protection quickly, MTA-STS is the pragmatic choice: no zone signing, no new failure modes in DNS, and it is understood by several of the largest senders. It is the lower-risk, faster path and, for many domains, entirely sufficient. Begin in testing, watch TLS-RPT, and move to enforce — the process in testing vs enforce.
If you already run DNSSEC, or are willing to, DANE gives you a cryptographically stronger guarantee with no trust-on-first-use gap and no dependence on external CAs, and it is enforced by a different (and in some regions large) set of senders. The barrier is operational maturity: you must be confident in your DNSSEC operations, because certificate rotation now has to be coordinated with TLSA-record rotation, and a mismatch means deliverability failure.
Why big providers publish both
The largest mail operators — the ones handling mail for millions of domains — commonly publish both MTA-STS and DANE. The reason is straightforward once you see that support is fragmented across the sending world: no single mechanism is honoured by every sender. Publishing both maximises the set of senders that will enforce TLS to you. A sender that speaks DANE and can validate DNSSEC gets the stronger, gap-free guarantee; a sender that only implements MTA-STS still gets meaningful protection from downgrade. There is no conflict in running both simultaneously — they are independent records that a given sender evaluates according to what it supports, and where a sender happens to support both, some deployments treat the DNSSEC-anchored DANE result as the more authoritative.
For most organisations the honest answer to "do you need both?" is: you need at least one, and MTA-STS is the one to start with unless DNSSEC is already part of your world. Add DANE when you have DNSSEC running reliably and want to reach the senders who prefer it and to close the first-contact gap. And regardless of which you deploy, publish TLS-RPT (v=TLSRPTv1 at _smtp._tls) — it reports on both MTA-STS and DANE outcomes, so it is the one record that gives you visibility whichever path you take. See what TLS-RPT tells you for reading those reports, verify the underlying handshakes with STARTTLS Studio, and use DNS Studio for the wider mail-security picture.