DANE / TLSA Checker
Enter a domain to check DANE for SMTP (RFC 7672): we resolve every MX host and look up its TLSA records at _25._tcp.<mx>. Under DNSSEC, TLSA lets senders pin your receiving server's certificate and refuse a downgrade — but every MX must be covered, or the uncovered one is a downgrade path.
Reviewed by the SysGlass team · Updated July 21, 2026
What it checks
- Every MX host for the domain
- Whether each MX publishes TLSA records at _25._tcp.<host>
- Full vs partial coverage across all MX hosts
How to read the result
- OK = all MX hosts publish TLSA — senders can pin TLS and refuse downgrade.
- Warn (partial) = some MX have TLSA and some don't; senders can downgrade via the uncovered MX.
- Warn (none) = no DANE; inbound TLS can be silently downgraded. Needs DNSSEC to deploy.
Frequently asked questions
What is DANE for SMTP?
DANE publishes TLSA records that pin your MX server's certificate (or key) in DNS. Under DNSSEC, a sending MTA uses them to require the exact certificate and refuse plaintext or a swapped cert — preventing downgrade attacks.
Does DANE require DNSSEC?
Yes. TLSA records are only trustworthy when the zone is DNSSEC-signed; without DNSSEC, senders ignore them. Check DNSSEC first, then deploy TLSA.
Why does partial coverage matter?
SMTP tries each MX. If one MX lacks a TLSA record, a sender (or attacker steering to that MX) can deliver without DANE protection — so every MX host must publish TLSA.
DANE or MTA-STS — which should I use?
They solve the same downgrade problem differently: DANE uses DNSSEC, MTA-STS uses the Web PKI. Many domains deploy both for the widest sender coverage.