How it works
DANE (RFC 6698, with RFC 7672 covering SMTP) publishes a server's expected key in DNS instead of relying on certificate authorities alone. For mail, the TLSA record lives at _25._tcp under the MX host name, for example _25._tcp.mail.example.com, and applies to port 25.
A typical record reads 3 1 1 followed by 64 hex characters. The first number is the usage: 3 (DANE-EE) means “exactly this key”, 2 (DANE-TA) means "a certificate from this issuing authority". The second picks the public key (1) rather than the full certificate (0), the third the hash, here SHA-256 (1). Usages 0 and 1 are not meant for SMTP.
DANE only works with DNSSEC; without a signature the TLSA record could be forged just as easily as the connection. A validating sender such as Posteo or mailbox.org looks up the TLSA record, connects via STARTTLS and delivers only if the certificate matches. Unlike MTA-STS, DANE needs no web server and protects even the very first connection.
Why it matters
When the TLSA record no longer matches the certificate, DANE-validating senders refuse to deliver rather than falling back to plain text. The usual trigger is a certificate renewal with a new key, without first publishing a TLSA record for that key. Since other senders keep delivering, the problem often goes unnoticed for days.
A TLSA record without a DNSSEC signature, on the other hand, protects nothing; senders ignore it. And a broken DNSSEC chain makes the TLSA lookup fail with SERVFAIL, which also stops validating senders from delivering.
How to prevent it
- Enable DNSSEC for the mail server's zone before publishing TLSA records, and monitor the signatures.
- Use only usage 3 or 2 for mail servers, typically 3 1 1 with the SHA-256 hash of the public key.
- Keep the key when renewing (with certbot, for example, via --reuse-key), or publish an additional TLSA record for the new key at least two TTL periods before the switch.
- Maintain a TLSA record for every MX host; with hosted mail, check whether the provider supports DANE itself.
- Publish a TLS-RPT record alongside DANE so senders can report failures.
How DomainWarn detects it
The DANE check looks up the TLSA record at _25._tcp for every MX host and verifies that it is DNSSEC-signed, parses correctly and uses a usage that works for SMTP (2 or 3). If port 25 is enabled for the probe servers, it also fetches the certificate via STARTTLS and compares it with the TLSA records; otherwise it checks format and signing only.
If no TLSA record matches the certificate, that is critical and immediately opens a “DANE: TLSA does not match certificate” incident. Unsigned, unreadable, unusable or unverifiable records and SERVFAIL on the lookup open “DANE broken” after two runs. No TLSA record at all is just a notice; if the mail server sits in a zone without DNSSEC, as with Microsoft 365, DomainWarn explains that DANE does not apply there.
Newly enabled DANE and changed or removed TLSA records are reported as changes. The check runs once a day.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.