KoltrixDANE vs MTA-STS for inbound mail: the trade-offs
Both stop STARTTLS downgrades, with different trust models. Compare DANE's DNSSEC dependency with MTA-STS's web PKI approach and decide what to deploy.
On this page(9 sections)
DANE and MTA-STS solve the same problem: making sure a server delivering mail to your domain uses TLS with a certificate it can actually verify. They do it with different trust models, and those trust models decide which one is practical for you.
The shared problem
SMTP between servers uses STARTTLS opportunistically. A sending server connects to your MX host, sees whether TLS is offered, and upgrades if it can. If TLS is not offered, or the certificate looks wrong, it usually delivers anyway in plain text, because rejecting would break mail to the many servers with imperfect TLS.
That leaves two gaps:
- STARTTLS stripping. An attacker on the path removes the STARTTLS capability from the server's response, forcing plain text.
- No certificate validation. Even when TLS is used, the sender often accepts any certificate, so an attacker who redirects the connection can present their own.
Both DANE and MTA-STS let a receiving domain declare "TLS is required here, and this is how to verify my server." Senders that support the mechanism then refuse to deliver over a connection that does not meet the declaration.
How DANE works
DANE (DNS-based Authentication of Named Entities) for SMTP is defined in RFC 7672, building on the TLSA record from RFC 6698. The receiving domain publishes TLSA records for each MX host, describing which certificate or public key that host will present:
_25._tcp.mx1.example.com. TLSA 3 1 1 0f3a4c...e91bThe three numbers mean:
- 3: usage "DANE-EE", match the server's own certificate (not a CA).
- 1: selector, match the public key rather than the full certificate.
- 1: matching type, a SHA-256 hash.
A sending server that supports DANE looks up the TLSA record, and if it finds one, it requires TLS and checks that the presented certificate matches the record. The certificate does not have to come from a public certificate authority; the DNS record itself is the trust anchor.
The catch is DNSSEC. DANE only works if the DNS answers are authenticated, otherwise an attacker could forge the TLSA record. Both the domain hosting your MX records and the MX hostnames' zone must be DNSSEC-signed, and senders only apply DANE when they get DNSSEC-validated answers.
How MTA-STS works
MTA-STS, defined in RFC 8461, avoids DNSSEC by using the web PKI. The receiving domain publishes:
- A TXT record at
_mta-sts.example.comannouncing a policy and its version ID. - A policy file served over HTTPS at
https://mta-sts.example.com/.well-known/mta-sts.txt, listing allowed MX hosts and a mode.
A sending server that supports MTA-STS fetches the policy over HTTPS, validating the web server's certificate as browsers do. It caches the policy for the max_age you set. When delivering, it requires TLS to a listed MX host with a certificate that is publicly trusted and matches the hostname.
The weak point is the first contact. A sender that has never fetched your policy can be tricked by an attacker who blocks the DNS lookup or the HTTPS fetch, so it never learns that a policy exists. This is often called the trust-on-first-use limitation. Long max_age values reduce the window after the first successful fetch.
Side by side
| Aspect | DANE | MTA-STS |
|---|---|---|
| Trust anchor | DNSSEC | Public web certificate authorities |
| Requires DNSSEC | Yes, for the MX zone and the domain | No |
| MX certificate | Any certificate matching the TLSA record | Must be publicly trusted and match the MX hostname |
| First-contact protection | Yes, when DNSSEC validates | No; relies on caching after first fetch |
| Extra infrastructure | TLSA records, DNSSEC signing | HTTPS host for the policy file |
| Main operational risk | TLSA records out of sync with certificates; DNSSEC failures | Policy out of sync with MX list; expired certificates |
| Reporting | TLS-RPT (RFC 8460) | TLS-RPT (RFC 8460) |
Sender support
What matters in practice is which senders honor each mechanism. Support has grown for both, but unevenly across mail operators. Some large mailbox providers have announced support for MTA-STS, some for DANE, and some for both. Open source mail servers such as Postfix have long supported DANE validation for outbound mail when configured with a DNSSEC-validating resolver.
Because support differs by sender, publishing both is common among operators who can, and TLS-RPT reports will tell you which policy type each reporting sender applied.
Operational trade-offs
DANE's hard parts
- DNSSEC must be solid. A DNSSEC misconfiguration can make your domain unresolvable for validating resolvers, which affects far more than email.
- Certificate rollovers need TLSA planning. If you match the full certificate and your certificate renews automatically every few months, the TLSA record must change too. Matching the public key (selector 1) and reusing the key across renewals, or publishing TLSA records for both the current and next key before rolling over, avoids outages.
- Hosted mail complicates things. If your MX hosts belong to a mailbox provider, the TLSA records live in the provider's zone and DNSSEC is in their hands. You can only use DANE if they support it.
MTA-STS's hard parts
- MX list maintenance. Changing MX hosts without updating the policy causes senders to refuse delivery in enforce mode.
- Web hosting dependency. The policy host needs a valid certificate and must not redirect, and it is easy to break during unrelated website work.
- First-contact weakness. Accepted as a known limitation.
Which should you deploy?
A practical decision path:
- Using a hosted mailbox provider without DNSSEC support on their MX zone? MTA-STS is your realistic option. You control the policy; they control the certificates, which are typically publicly trusted already.
- Running your own MX hosts with DNSSEC already deployed and well managed? DANE is attractive, and adding MTA-STS alongside it covers senders that only support one.
- No DNSSEC and no appetite to deploy it? MTA-STS.
- Either way: publish a TLS-RPT record first so you can see failures.
Checklist
- Confirm every MX host offers STARTTLS with a valid certificate.
- Publish TLS-RPT before enforcing anything.
- For MTA-STS: host the policy, publish
_mta-sts, start in testing mode. - For DANE: confirm DNSSEC on the domain and the MX zone, publish TLSA records, and plan certificate rollovers around them.
- Monitor reports and certificate expiry continuously.
Bottom line
DANE anchors trust in DNSSEC and protects even the first connection; MTA-STS anchors trust in web certificates and is far easier to deploy without DNSSEC. Most organizations on hosted mail should start with MTA-STS and TLS-RPT. Teams running their own MX hosts with mature DNSSEC can add DANE, and publishing both covers the widest range of senders.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
