DANE Record Checker
Look up TLSA records for DANE on a mail host.
Enter a domain to check whether its inbound mail servers publish DANE records. DANE pins a server's TLS certificate in DNS using TLSA records, so a sender can verify the certificate without trusting the public certificate authorities. We read the live records straight from DNS over an encrypted connection. Nothing is stored.
This tool looks up the TLSA records that DANE (DNS-Based Authentication of Named Entities) uses to bind a mail host's TLS certificate to DNS. For SMTP, TLSA records are published at _25._tcp.<mailhost> (port 25, TCP) for each host named in your MX records. A sending server that supports DANE fetches these records and refuses to deliver unless the receiving host presents a certificate that matches, defeating downgrade and man-in-the-middle attacks.
How a TLSA record is structured
Each TLSA record has four parts: a usage field (for SMTP, 3 DANE-EE or 2 DANE-TA are used; PKIX usages 0 and 1 are not appropriate for SMTP), a selector (0 full certificate or 1 just the public key, with 1 recommended), a matching type (1 for SHA-256, almost always; 0 means the full data with no hash), and the hex certificate association data itself. The tool parses these and shows whether the record is syntactically valid.
The critical requirement and common faults
DANE is only trustworthy when the zone is protected by DNSSEC; without a valid signature chain the TLSA records can be forged, and conforming senders will ignore them. The most common problems are a missing DNSSEC signature, a TLSA hash that no longer matches the host's current certificate after a renewal, the wrong port name, or records on the domain rather than on each MX host. When you rotate certificates, publish the new TLSA record before deploying the certificate and remove the old one afterwards. DANE and MTA-STS can run together for defence in depth; see also TLS-RPT to monitor both.
Frequently asked questions
Where are SMTP TLSA records published?
For inbound mail they go at _25._tcp.<mailhost>, where the mail host is each name returned by your MX records, not the parent domain itself. The _25 refers to SMTP port 25 and _tcp to the transport.
Does DANE require DNSSEC?
Yes, and this is non-negotiable. TLSA records are only meaningful when the zone is signed with DNSSEC, because the security guarantee comes from the signed DNS chain. Without a valid signature, DANE-aware senders treat the records as if they were absent.
What do the three numbers before the hash mean?
They are usage, selector and matching type. For SMTP, usage is typically 3 (DANE-EE) or 2 (DANE-TA), selector 1 (public key) is recommended, and matching type 1 means the data is a SHA-256 hash. So a common record is 3 1 1 followed by the hash.
Why did my mail start failing after a certificate renewal?
If you renewed the certificate but did not update the TLSA record, the published hash no longer matches the presented certificate and DANE validation fails. Publish the new TLSA record before deploying the new certificate, allow DNS to propagate, then remove the old record.
Should I use DANE or MTA-STS?
They address the same downgrade threat by different roots of trust: DANE uses DNSSEC, MTA-STS uses the web PKI and HTTPS. If your zone is DNSSEC-signed you can run both for redundancy; if not, MTA-STS is the practical option. Either way, enable TLS-RPT to monitor results.
Which selector and matching type should I choose?
Selector 1 (the subject public key) is preferred because it survives certificate reissues that keep the same key, and matching type 1 (SHA-256) is the standard choice. Avoid matching type 0 (full data, no hash) for SMTP as it bloats the record.