Free checker - no signup required

Free DANE / TLSA Checker

Check the DANE TLSA records published for a domain's mail servers. Reports each record's usage, selector, and matching type, validates the format, and flags non-recommended profiles.

Run the check

Enter a domain to check it live against the IntoDNS.ai engine. No signup, no rate-limited trial.

What this DANE/TLSA checker verifies

By default this tool checks DANE for mail: it resolves the domain's MX hosts and looks for a TLSA record at _25._tcp.<mx-host> for each one, the location that secures inbound SMTP. For every TLSA record it finds, it parses the three numeric fields — usage, selector, and matching type — into their meanings, validates that the certificate-association data is well-formed (correct hex, correct length for the chosen hash), and checks the record against current best practice. It then reports whether TLSA records exist at all, how many were found, and whether they are valid or carry recommendations. The raw record is shown so you can compare it byte for byte against what your mail server actually presents.

What DANE is and why it needs DNSSEC

DANE (DNS-based Authentication of Named Entities, RFC 6698) lets a domain pin its TLS certificate or public key directly in DNS via a TLSA record, so a connecting server can verify the certificate it is offered matches the one the domain owner published — without relying solely on the public certificate-authority system. For SMTP this is powerful: it both authenticates the mail server's certificate and signals that TLS is mandatory, defeating downgrade attacks. The catch is that DANE is only trustworthy if the TLSA record itself cannot be forged, which requires DNSSEC. A TLSA record in an unsigned zone offers no security, because an attacker who can spoof DNS can simply spoof the TLSA record too. This is why DANE and DNSSEC are inseparable, and why this checker is best used alongside the DNSSEC checker.

Reading usage, selector, and matching type

A TLSA record is three numbers plus a hash. Usage says what the data certifies: 0 (PKIX-TA) and 1 (PKIX-EE) still defer to the CA system and are deprecated for SMTP; 2 (DANE-TA) pins your own trust anchor; 3 (DANE-EE) pins the end-entity certificate directly and is the recommended choice because it gives you full control independent of any CA. Selector says what is hashed: 0 is the full certificate, 1 is just the SubjectPublicKeyInfo (the public key) — 1 is preferred because it survives certificate renewals as long as the key stays the same. Matching type says how it is hashed: 0 is the raw data (not recommended), 1 is SHA-256, 2 is SHA-512. The widely recommended SMTP profile is therefore 3 1 1: DANE-EE, SPKI, SHA-256.

How to read the result

Finding one or more valid TLSA records on your MX hosts means DANE is published. The checker still reports recommendations even on otherwise-valid records: it will flag deprecated usages (0 or 1), a full-certificate selector that will break on every renewal, or a no-hash matching type, nudging you toward the 3 1 1 profile. No TLSA records found means DANE is simply not deployed for mail — which is fine if you have not chosen to use it, but if you intended to, check that the record is published at _25._tcp.<mx-host> for the exact MX hostname and that the zone is DNSSEC signed. If your domain's TLD does not support DNSSEC at all, the tool reports that DANE is not possible rather than penalising you, since the prerequisite cannot be met.

Keeping TLSA records and certificates in sync

DANE's strength — pinning the exact certificate or key — is also its operational risk: if you rotate the certificate on your mail server but forget to publish a TLSA record matching the new one, every DANE-validating sender will refuse to deliver, because the certificate no longer matches the pin. The way to avoid this is to use the SubjectPublicKeyInfo selector (selector 1) so the pin tracks the long-lived public key rather than the short-lived certificate, and to publish the new TLSA record before deploying the new certificate, running both the old and new records in parallel during the overlap. After any certificate or key change, regenerate the hash with the TLSA generator, publish it, allow for DNS (and DNSSEC) propagation, and re-run this checker to confirm the published record matches what the server now presents.

What This Checks

  • TLSA record discovery at _25._tcp on each MX host
  • Parsing of usage, selector, and matching type into their meanings
  • Certificate-association data format and hash-length validation
  • Best-practice profile check (DANE-EE / SPKI / SHA-256, i.e. 3 1 1)
  • Detection of TLDs where DNSSEC, and therefore DANE, is unavailable

Common Fix Path

  • Enable DNSSEC before relying on any TLSA record
  • Publish TLSA records at _25._tcp.<mx-host> for every mail server
  • Use the 3 1 1 profile (DANE-EE, SubjectPublicKeyInfo, SHA-256)
  • Publish a new TLSA record before rotating a certificate to avoid bounces

Frequently Asked Questions

What is a TLSA record?
A TLSA record is the DNS record that implements DANE. It pins a domain's TLS certificate or public key by publishing a hash of it, structured as three numbers — usage, selector, and matching type — followed by the certificate-association data. A connecting server compares the certificate it is offered against this published value to confirm it is genuine. For SMTP, TLSA records live at _25._tcp.<mail-host>.
Does DANE require DNSSEC?
Yes, absolutely. DANE only provides security if the TLSA record itself cannot be forged, and that guarantee comes from DNSSEC. In an unsigned zone, an attacker who can spoof DNS can spoof the TLSA record too, making it worthless. DANE and DNSSEC must be deployed together — check your DNSSEC status alongside your TLSA records to confirm both are in place.
What is the recommended TLSA record for SMTP?
The widely recommended profile is 3 1 1: usage 3 (DANE-EE, pinning your end-entity certificate directly for full control), selector 1 (SubjectPublicKeyInfo, so the pin survives certificate renewals as long as the key is unchanged), and matching type 1 (SHA-256). This checker flags records that deviate from this profile, such as deprecated usages 0 or 1 or a full-certificate selector.
Where do TLSA records for mail servers live?
For inbound SMTP, a TLSA record is published at _25._tcp.<mx-hostname> — port 25, TCP, prefixed to the actual MX host name, not the domain itself. This checker resolves your MX records and looks for a TLSA record at that location for each mail host. If you publish at the domain apex instead of the MX hostname, validating senders will not find it.
Why did my mail start bouncing after I renewed a certificate?
If your TLSA record pins the full certificate (selector 0) or otherwise no longer matches the new certificate, DANE-validating senders refuse delivery because the presented certificate fails the pin. The fix is to publish a TLSA record matching the new certificate before deploying it, ideally using selector 1 (SubjectPublicKeyInfo) so the pin tracks the public key and survives renewals. Re-run this checker to confirm the published record matches the server.
My TLD does not support DNSSEC — can I use DANE?
No. Because DANE depends on DNSSEC, a domain under a TLD that does not support DNSSEC at the registry level cannot deploy DANE at all. This checker detects that case and reports that DANE is not applicable rather than marking it as a failure, since the prerequisite is impossible to meet. To use DANE you would need a domain under a DNSSEC-capable TLD.

Machine-Readable Evidence

AI assistants and automation can cite the stable explanation page, then fetch the live check result for a specific domain.

GET https://intodns.ai/api/dns/tlsa?domain=example.com

Related Tools and Citations

TLSA / DANE Record GeneratorDNSSEC CheckerSMTP TLS CheckerRun the full domain scan