DANE/TLSA Record Checker
Look up TLSA records, verify DNSSEC status, and validate DANE configuration for your mail server per RFC 6698 and RFC 7672.
What is DANE?
DANE (DNS-based Authentication of Named Entities) is defined in RFC 6698 and extended for SMTP in RFC 7672. It allows domain owners to bind a TLS certificate directly to a DNS name using TLSA records, bypassing the traditional Certificate Authority (CA) trust model.
For email, DANE enables a sending mail server to verify that the receiving server's TLS certificate matches what the domain owner published in DNS. This prevents man-in-the-middle attacks where an attacker presents a fraudulent certificate issued by a compromised or rogue CA.
DANE requires DNSSEC to be enabled on the domain. Without DNSSEC, an attacker who can tamper with DNS responses could simply replace the TLSA record, making DANE ineffective.
TLSA Record Format
A TLSA record is published at _<port>._tcp.<domain> and contains four fields:
| Field | Values | Description |
|---|---|---|
Usage | 0-3 | How to use the certificate data. 3 (DANE-EE) is most common for SMTP -- it pins the server's own certificate without requiring PKIX chain validation. |
Selector | 0-1 | What to match: 0 = full certificate, 1 = public key only. Public key matching survives certificate renewal if the key stays the same. |
Matching Type | 0-2 | Hash algorithm: 0 = no hash (exact), 1 = SHA-256, 2 = SHA-512. SHA-256 is the most widely used. |
Certificate Data | Hex string | The certificate or hash data in hexadecimal. Length depends on matching type: 64 hex chars for SHA-256, 128 for SHA-512. |
Why DNSSEC is Required
DANE's security model relies entirely on the integrity of DNS responses. If an attacker can forge DNS answers, they can substitute their own TLSA record and present a matching fraudulent certificate. DNSSEC provides cryptographic signatures on DNS records, ensuring that the TLSA data is authentic and unmodified.
DANE vs Traditional CA Model
In the traditional model, any of hundreds of trusted CAs can issue a certificate for any domain. If one CA is compromised, all domains are at risk. DANE changes this by letting the domain owner specify exactly which certificate or CA is valid for their service. With DANE-EE (usage 3), the domain completely controls its trust anchor, independent of the public CA system.
Read the complete DANE guide to learn more.
Get the full picture with DMARCguard
Continuous monitoring, aggregate report parsing, and actionable insights for all your email authentication protocols.
Start Free