Both mechanisms tell a sender “require TLS to this domain, and expect this identity”. They differ entirely in where that statement is anchored, and every practical difference between them follows from that one choice.
The split
| MTA-STS | DANE | |
|---|---|---|
| Policy lives in | An HTTPS-served file | DNS, as TLSA records |
| Authenticated by | The web PKI — the HTTPS certificate on the policy host | DNSSEC — the chain from the root |
| Prerequisite | A web server and a valid certificate | A signed zone, and signed parent delegation |
| Failure mode | Fails open if the policy cannot be fetched at first contact | Fails closed — a validating sender will not deliver |
| Policy caching | Explicit, via max_age | Ordinary DNS TTL |
| Who implements it as a sender | Google, Microsoft, and a growing set | Largely European providers and the technically inclined |
Why there are two
DANE came first and is the cleaner design: the domain that owns the name asserts the certificate for it, with no third party involved. Its cost is DNSSEC, which large providers were unwilling or unable to adopt.
(no answer) 2371 13 2 B1AE88AFF068DDEC3F7FF662F47D65...
That single fact explains the existence of MTA-STS. Google could not deploy DANE for gmail.com without first signing the zone, so a mechanism was designed that borrows the web PKI instead — a trust infrastructure every large operator already runs.
Fails open against fails closed
MTA-STS is trust-on-first-use. A sender with no cached policy that cannot reach the policy host delivers anyway, because refusing would let anyone block your mail by blocking an HTTPS request. DANE has no such compromise: a validating sender that cannot verify the TLSA record does not deliver.
Stronger and weaker, in both directions
DANE’s stricter failure behaviour is a security advantage and an availability liability — a DNSSEC mistake stops your inbound mail rather than degrading it. MTA-STS’s tolerance is the reverse. Neither is simply better, and a domain that can do both usually should.