The dependency that decides availability

A TLSA record is only trustworthy if it cannot be forged, and the only thing that stops it being forged is DNSSEC. Without a validated chain, an attacker who can answer DNS can simply supply their own TLSA record — so a sender that cannot validate must ignore DANE entirely.

Checking availability

Two queries settle whether DANE is even possible for a domain. A DS record at the parent, and the ad flag from a validating resolver:

2371 13 2 B1AE88AFF068DDEC3F7FF662F47D65...

(no answer)

gmail.com is not signed. No amount of publishing TLSA records under Google’s MX hosts would make DANE work for it, because nothing would let a sender trust those records. That is the fact behind Google building MTA-STS instead.

Both zones, not just yours

The TLSA record lives under the MX hostname, so the zone that must be signed is the one containing the MX host — which is frequently not yours.

example.com   MX  10  mx.provider.example

The TLSA record is at _25._tcp.mx.provider.example
   -> provider.example must be signed
   -> example.com being signed is irrelevant to this

If your MX points at a provider, DANE is their decision,
not yours.

• A domain hosted on a provider that does not sign cannot have DANE, whatever it does to its own zone.
• This is why DANE adoption tracks provider choice rather than domain-owner effort.
• It is also why the providers that do support it advertise it — it is a differentiator they control and you cannot.

The cost of the dependency

DNSSEC failures are hard failures. An expired signature, a rolled key whose DS was not updated, or a misconfigured NSEC chain makes the zone unresolvable to validating resolvers — and DANE turns that from “some lookups fail” into “mail is not delivered”. The security is real and so is the operational demand.