Email

DANE / TLSA Checker

TLSA Records

Check DANE deployment

Enter a domain name to validate its DANE deployment — TLSA records, DNSSEC chain, and live certificate match for every MX host.
Looks up TLSA records at _25._tcp.<mx-host> for every MX of the domain. Port 25 with tcp is the standard for SMTP DANE.

DNS Resolver

Most domains return the same records on every resolver — the choice matters during DNS propagation, or when a filtering resolver blocks a domain.

No domain checked yet

Enter a domain above and click Check DANE to validate its TLSA records.

Tool features

Complete DANE validation — DNS, DNSSEC, and the live certificate
4 checks

TLSA Lookup

Queries _port._proto TLSA records for every MX host

DNSSEC Verified

Confirms records are authenticated — required for DANE

Live Cert Match

Fetches the real certificate and matches every hash

Actionable Verdict

Clear deployed / mismatch / missing result per host

What is DANE & how it works

How TLSA records pin certificates for SMTP TLS

DANE (DNS-Based Authentication of Named Entities) lets a domain pin the exact certificate its mail servers should present, published as a TLSA record in DNS and protected by DNSSEC. It stops an attacker from stripping SMTP TLS or swapping in a fraudulent certificate — a real risk with opportunistic mail encryption.

For each MX host, a TLSA record at _25._tcp.<mx-host> carries a hash of the server's certificate or public key. This checker looks up those records for every MX, confirms the zone is DNSSEC-signed, fetches the live certificate, and verifies each hash actually matches.

TLSA record
The DNS record pinning a server’s cert/key, e.g. a "3 1 1" SHA-256 hash.
DNSSEC
Required for DANE — senders ignore TLSA records that aren’t authenticated.
Usage 3 1 1
The recommended TLSA form: pin the end-entity key as a SHA-256 hash.

How to use this tool

Validate a domain's DANE deployment in four steps
1
Enter a domain
Type a domain, e.g. example.com — TLSA is checked for each of its MX hosts.
2
Set port & protocol
Leave port 25 / tcp for standard SMTP DANE, or adjust for another service, and pick a resolver if needed.
3
Run the check
Click Check DANE to look up TLSA records, verify DNSSEC, and fetch the live certificate.
4
Review per-host results
See each MX host’s TLSA records, whether the hash matches the live cert, and the recommendation.

Learn more

Guides & explainers related to this tool

Guide

How to Enable DNSSEC

DANE's prerequisite: sign your zone and publish DS records at the registrar.

Article

What Is DNSSEC?

How the DNS chain of trust works and why DANE depends on it.

Article

What Is MTA-STS?

The HTTPS-based alternative to DANE for enforcing SMTP TLS.

Related tools

Keep debugging with tools from the same suite
4 tools
DANE / TLSA Generator
Generate DANE TLSA records from a PEM certificate with real SPKI hashing computed locally in the browser
DNSSEC Validator
Validate DNSSEC (DNS Security Extensions) configuration, check DNSKEY, DS, and RRSIG records
MTA-STS & TLS-RPT Checker
Check a domain MTA-STS policy and TLS-RPT record, validating DNS records and the live HTTPS policy file
MX Lookup
Find mail exchange (MX) records for email server configuration and priority

Frequently asked questions

Common questions about DANE
5 Q&A

DANE (DNS-Based Authentication of Named Entities) uses DNSSEC-signed TLSA records to tell clients exactly which certificate or key a server should present, preventing TLS downgrade and certificate-substitution attacks.

A TLSA record is a DNS record that pins a server’s certificate or public key. It has three parameters — usage, selector and matching type — plus the hash, e.g. "3 1 1" pins the end-entity public key as a SHA-256 hash.

Yes. TLSA records are only trustworthy when authenticated by DNSSEC. If the zone is not signed, validating senders ignore the TLSA records entirely, so DANE provides no protection.

The most common cause is certificate rotation without updating the TLSA record. Republish the hash of the new key (or use a rollover scheme with both old and new records during the change) so validating senders can still deliver.

Port 25 over tcp is the standard for inbound SMTP with STARTTLS, so TLSA records live at _25._tcp.. Other services (e.g. submission on 587) use their own port in the TLSA name.