DANE/TLSA Record Checker

Query the TLSA records published by a domain's mail servers (MX hosts) against multiple public DNS resolvers to check whether DANE certificate pinning is configured.

Diagnosing certificate validation by DANE (TLSA records)

DANE is the arrangement by which the certificate a mail server presents is **validated against a TLSA record placed in DNS.** This tool queries the TLSA records published by a domain's MX hosts against several public resolvers and reports whether they are configured.

**The premise that must never be left out here is that DANE stands only on DNSSEC.** What guarantees that a TLSA record has not been tampered with is DNSSEC itself, so **placing TLSA records on a domain without DNSSEC enabled amounts to no protection at all.** This is the chief difference from MTA-STS: where MTA-STS places its trust in web certificates, **DANE places it in DNSSEC.** The other point demanding care in operation is certificate renewal, since **replacing a server's certificate without updating the TLSA record at the same time makes validation fail and stops mail arriving.** The order required is to add the new fingerprint first, switch over, and only then remove the old one.

How to use it

  1. Enter the domain Give the domain alone, in the form `example.com`.
  2. Look at the result for each MX host **TLSA records sit at `_25._tcp.hostname` for each MX host.**
  3. Confirm whether DNSSEC is in place **Without DNSSEC, a TLSA record affords no protection.**
  4. Plan the procedure for certificate renewal **Let the old and new fingerprints coexist for a time before switching over.**

Tips for getting more out of it

  • TLSA records don't live under the plain domain name — they're published under a special name, `_25._tcp.{mx host}`. That's why looking up TLSA on the bare domain never finds anything.
  • "DANE not configured" is not an error. DANE is an additional layer of mail encryption defense, and most mail servers still don't use it.
  • DANE is only trustworthy if the domain's TLSA record itself is protected by a DNSSEC signature chain. Even if a TLSA record is found, pair this with the sister "DNSSEC Checker" tool to confirm the domain has DNSSEC enabled.
  • When a domain has multiple MX hosts, this tool checks up to 3 hosts, starting with the lowest preference number (highest priority).
  • If resolvers disagree, the record may have just been updated and caches haven't caught up yet. Wait a while and check again.

Where it comes in useful

Inspecting your own mail servers

You can find the discrepancy where a TLSA record was thought to be in place but is absent from the MX host.

Checking before renewing a certificate

**Getting the order wrong stops mail, which makes checking beforehand well worth the trouble.**

Weighing DANE against MTA-STS

**Choose by where you would rather place trust, in DNSSEC or in web certificates; both may be adopted together.**

Learning how far a correspondent has gone

You can see whether they use DANE at all.

DANE terms

TLSA record
**The record placing the fingerprint of a certificate or public key into DNS.** It sits at a name such as `_25._tcp.mail.example.com`.
DNSSEC
**The premise of DANE.** Without it the TLSA record could itself be tampered with, and no protection stands.
Usage field
The first number in a TLSA record, stating whether it refers to the certificate itself or to a certificate authority.
DANE-EE
The approach registering the fingerprint of the server certificate itself. **It allows validation without depending on any authority.**
Rollover
The work of replacing a certificate and its TLSA record. **Add the new fingerprint first and remove the old one afterwards.**
Opportunistic TLS
The older, optional approach of encrypting where the other side supports it. **DANE and MTA-STS raise this to a requirement.**

Frequently Asked Questions

"DANE not configured" by itself is not dangerous — the large majority of mail servers still operate without it. That said, enabling it is worth considering as a defense against STARTTLS man-in-the-middle attacks if you have the option.

Both aim to enforce TLS encryption for mail transport, but they root their trust differently: MTA-STS relies on a certificate authority's validation chain, while DANE relies on the DNSSEC signature chain. If you already have DNSSEC enabled, DANE is a natural fit; otherwise, MTA-STS is the more practical starting point. The two can also be used together.

Usage specifies the validation model (whether CA validation is still required, or the certificate itself is pinned directly), Selector specifies whether the full certificate or just its public key is hashed, and Matching Type specifies the hash algorithm (such as SHA-256 or SHA-512). Different combinations support different operational patterns.

For complete protection, every MX host that might be chosen as a delivery target should have a TLSA record. If only some hosts have one, mail delivered to a host without a record isn't protected.

This tool only checks a surface-level state: whether a TLSA record is published. It doesn't verify that the certificate association data actually matches the server's real certificate, so pair it with a specialized tool if you need a rigorous check.
Tool-kun

Side Note — Protecting mail encryption with certificates, not just "don't eavesdrop"

Email encryption over SMTP (STARTTLS) has long had a weakness. Most mail servers use opportunistic TLS — falling back to plaintext if the other side doesn't support encryption — which opened the door to "STRIPTLS attacks," where a man-in-the-middle attacker silently strips the STARTTLS command so the connection downgrades to plaintext without either side noticing.

DANE (DNS-based Authentication of Named Entities, RFC 6698) answers this by publishing TLSA records in DNS. By pinning a mail server's certificate (or its public key hash) in DNS ahead of time, a sending server can verify that the host it connects to is actually presenting the expected certificate. Unlike ordinary SSL/TLS certificate validation, DANE doesn't rely on a certificate authority's trust chain at all — it trusts only the DNSSEC signature chain.

DANE's weakness is that it only works if the domain itself is signed with DNSSEC. Without DNSSEC, nothing prevents the TLSA record from being tampered with in transit, which makes DANE's guarantee meaningless. That's why DANE adoption tracks DNSSEC adoption closely, and it has seen earlier uptake among some European registries (such as .nl and .cz).

Read related trivia

Browse all trivia

People who viewed this tool also viewed

Email Address Validator

Instantly check whether an email address matches a practical RFC 5322-style format, and verify whether its domain can actually receive mail (MX record lookup). Free tool for form validation and mailing list cleanup.

SPF/DKIM/DMARC Record Checker

Look up SPF, DMARC, and DKIM records for any domain in real time and diagnose your anti-spoofing email authentication setup.

DNS Record Type Reference Guide

A reference covering the DNS record types you need for running mail and websites — A, MX, TXT, SPF, DKIM, DMARC and more — with purpose, syntax examples, and gotchas for each.

DNS Propagation Checker (Free) - Check DNS Records Worldwide

Free tool to query a domain's DNS records against multiple public resolvers around the world (Google, Cloudflare, and more) at once, so you can instantly see whether a nameserver or record change has propagated globally.

DNSSEC Checker

Query a domain's DNSKEY record against multiple public DNS resolvers (Google, Cloudflare, and more) to check whether its DNSSEC signature chain validates correctly.

MTA-STS Policy Checker

Fetches a domain's _mta-sts TXT record and mta-sts.txt policy file to diagnose whether MTA-STS (mandatory TLS encryption for inbound mail) is configured correctly.