A TLSA (Transport Layer Security Authentication) record is used to associate a TLS/SSL server certificate or public key with the domain name where the record is found. It forms the foundation of a security protocol called DANE (DNS-based Authentication of Named Entities).
Check your TLSA certificate hashes and ensure your secure routing is configured correctly.
Traditionally, browsers and mail servers rely on hundreds of public Certificate Authorities (CAs) to verify SSL certificates. If even one of these CAs is hacked or compromised, an attacker could issue a fake, but "valid", certificate for your domain and intercept your traffic (a Man-in-the-Middle attack).
TLSA fixes this by "pinning" your certificate in your DNS. When a client connects to your server, it checks the DNS for the TLSA record. If the certificate presented by the server doesn't match the cryptographic hash published in your TLSA record, the connection is instantly aborted, even if the certificate was signed by a trusted CA.
Unlike standard records, TLSA records are attached to a specific port and protocol. To check the HTTPS certificate for www.example.com, you must query: _443._tcp.www.example.com. To check the secure SMTP email certificate, you would query _25._tcp.mail.example.com.
No. This is a critical rule. Because TLSA relies on DNS to verify the authenticity of an SSL certificate, the DNS response itself must be mathematically proven to be untampered. If your domain does not have DNSSEC enabled, clients will completely ignore your TLSA records.
SMTP (the protocol used to send emails) historically falls back to unencrypted plain text if a secure connection fails. By publishing a TLSA record for your mail server (along with an MX Record), you enforce mandatory TLS encryption. If an attacker tries to downgrade the connection to plain text, the receiving server will refuse to send the email.
If your TLSA record is configured to match the exact certificate (Usage 3), renewing your SSL certificate will change its hash. If you don't update your TLSA record to match the new hash before you switch the certificates on your server, DANE validators will reject connections to your site. A common best practice is to publish the new TLSA record alongside the old one a few days before the rollover.