DANE / TLSA Lookup
Look up TLSA records for a domain's mail hosts, decode certificate usage, selector and matching type, check the live certificate against them and confirm the zone is DNSSEC-signed.
About DANE / TLSA Lookup
The DANE / TLSA Lookup fetches the TLSA records that bind a service's certificate to its DNS name and explains what each one actually asserts. Enter a domain and a port and it resolves the MX hosts, or the domain itself when there are none, queries _<port>._tcp.<host> for each of them, and decodes the three numeric fields into plain language. On implicit-TLS ports it goes further: it retrieves the live certificate, recomputes the association data, and tells you whether the published records still match what the server presents.
DANE, profiled for SMTP by RFC 7672, replaces the public CA trust decision with an assertion you publish yourself in DNS and authenticate with DNSSEC. That last clause is the whole point. If the zone is unsigned, an on-path attacker simply strips the TLSA records, the sender sees a domain with no DANE, and delivery falls back to opportunistic TLS. The other common failure is renewal: rotate a key or certificate without updating the TLSA record and DANE-validating senders, including large German and Dutch providers, refuse to deliver at all.
DNSSEC status is judged by looking for a DS record in the parent zone rather than by trusting the AD flag on a resolver's answer, since that flag only reflects what the resolver in front of you chose to validate; the DS query runs through our own European resolver. Certificate verification is limited to implicit-TLS ports, 443, 465 and 993, because port 25 negotiates STARTTLS, so on 25 the records are decoded and reported without a live comparison. Matching type 0, which puts a whole certificate in DNS, is flagged in favour of SHA-256.
How to use it
- 1Enter the domain you want to inspect, for example ietf.org.
- 2Choose the port: 25 for SMTP between mail servers, 465 for SMTPS, 993 for IMAPS, 443 for HTTPS.
- 3Select Check DANE and read the DNSSEC badge first, because without a DS record nothing below it offers protection.
- 4For each host, check the number of TLSA records and, on implicit-TLS ports, whether the certificate matches.
- 5Read the decoded usage, selector and matching type of every record, along with the query name used.
- 6Act on the issues list, such as hosts publishing no TLSA records or a certificate that matches none of them.
Common use cases
- -Confirming TLSA records still match after renewing or rekeying an MX certificate.
- -Troubleshooting mail rejected by DANE-validating senders such as large German and Dutch providers.
- -Verifying a zone is DNSSEC-signed before relying on DANE for anything.
- -Auditing every MX host in a delegation for consistent DANE deployment rather than partial coverage.
- -Planning a mail platform migration by comparing published TLSA records against the new certificates.
Frequently asked questions
- Does DANE work without DNSSEC?
- No. DANE puts its trust assertion in DNS, so the only thing stopping an attacker deleting or forging the TLSA records is a DNSSEC signature chain. With no DS record in the parent zone, a sender cannot tell an absent TLSA record from a stripped one and treats the connection as ordinary opportunistic TLS. Signing the zone is a prerequisite for DANE, not an optional improvement.
- What is the difference between DANE-EE and PKIX-EE?
- Both constrain the server's own certificate, but PKIX-EE (usage 1) additionally requires that certificate to chain to a publicly trusted CA, while DANE-EE (usage 3) does not: the TLSA record is itself the trust anchor, and RFC 7672 does not require SMTP validators to check the hostname or the expiry date. DANE-EE with selector 1 is the usual choice for mail servers.
- Which TLSA selector and matching type should I use?
- Selector 1 with matching type 1, that is a SHA-256 digest of the SubjectPublicKeyInfo. Because it commits to the public key rather than to the whole certificate, the record stays valid across any renewal that reuses the key pair, which removes the most common way DANE breaks. Matching type 0 publishes the entire certificate in DNS and produces oversized answers, so it is flagged here.
- Why does my certificate no longer match my TLSA record?
- Almost always because the certificate was renewed with a fresh key while the TLSA record still carries the old digest. Publish the new record before the changeover, keep both records live until the old one has expired from every sender's cache, then remove it. Using selector 1 and reusing the key pair across routine reissues avoids the problem entirely.