They are not alternatives in the usual sense. They protect against the same attack, are honoured by largely different senders, and coexist without conflict — so the real question is which you can operate, not which is better.
Who honours which
| Implemented as a sender by | |
|---|---|
| MTA-STS | Google, Microsoft, and most large commercial providers |
| DANE | Several European providers, academic and technical operators, and most self-hosted Postfix |
The overlap is small, which is the strongest argument for publishing both: each covers a population the other does not. A sender that understands both applies both, and they do not conflict — the policies say the same thing by different means.
Deciding
Is the zone containing your MX hosts DNSSEC-signed?
no -> MTA-STS. DANE is not available to you.
yes -> continue
Do you already operate DNSSEC confidently — key rollovers,
monitoring, a tested recovery for a broken chain?
no -> MTA-STS first. Add DANE when DNSSEC is boring.
yes -> both.
Do you have a web server and certificate automation?
no -> the policy host is the work. DANE alone is
defensible if DNSSEC is solid.
yes -> both.Running both
- Keep the host lists consistent. An MX host in your MTA-STS policy with no TLSA record fails for DANE senders; a host with TLSA absent from the policy fails for MTA-STS senders. The two lists must be maintained together.
- TLS-RPT reports on both. The policy type field distinguishes them, so one reporting channel covers the pair.
- Changes get the stricter of the two waits. A DNS TTL for TLSA,
max_agefor MTA-STS. Lead with whichever is longer.
Neither protects your outbound mail
Both are statements a receiving domain makes about itself, honoured by senders. They do nothing about how your outbound mail is transported — that depends on whether your own MTA implements them as a sender, which is a configuration question on your mail server and has nothing to do with what you publish.