If someone wants to send e-mail to user@example.net, they first look up the MX records of example.net. Say, for example, that the MX record for example.net contains the mail server “mailserver.example.com”. (Note the different domain name.) The e-mail sender then looks up the TLSA records of the DNS name “_25._tcp.mailserver.example.com”. The TLSA records contain hashes of keys. The communication to the mail server must support TLS, and must use one of the keys which are listed by the TLSA records, otherwise the communication is regarded as insecure or under attack, and is considered to have failed, similar to if a server cannot be reached.

Also, for DANE to work, both the MX lookup and the TLSA lookups must support DNSSEC! Note well that this means that, in this example, both the domains “example.net” and “example.com” must be signed by DNSSEC for DANE to work.

One wrinkle is that if you use ACME to renew your certificates, you have to add a step in your process so that every time a new certificate is generated, the TLSA records in the DNS are also updated. Note also that DNS TTL values make it so that you should not use a new certificate until it’s guaranteed that everybody has had a chance to see the new TLSA record corresponting to that certificate in the DNS. The normal method for dealing with this is to always have two TLSA records, one for the certificate which you are using, and one for a new certificate which you are not using yet, and make sure that the times are set so that you don’t use the new certificate until the TTL has expired for the resource record set which did not have the TLSA record for that new certificate.

EDIT: Actually, read the response from user “mjl-”; it has more detail, and is obviously from a person which has more practical experience.