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.
Frequently asked questions
How do I check a TLSA record?
Enter your domain. The checker looks up TLSA records at _25._tcp.<mailhost>, verifies the chain is signed with DNSSEC (mandatory for DANE), and decodes the usage, selector, and matching-type fields so you can confirm the record matches your mail server's certificate per RFC 6698.
Does DANE require DNSSEC?
Yes. DANE's trust comes entirely from DNSSEC — without a valid signed chain, TLSA records can be stripped or forged and give no protection. The checker reports DNSSEC status first; if your zone isn't signed, DANE cannot be deployed until you enable DNSSEC at your DNS provider.
What does TLSA 3 1 1 mean?
The three numbers are usage, selector, and matching type. 3 (DANE-EE) matches the server's own certificate; 1 selects the public key (SubjectPublicKeyInfo); 1 is a SHA-256 hash. 3 1 1 is the recommended combination for SMTP DANE.
Does DANE protect inbound or outbound email?
TLSA records published at your MX hosts (_25._tcp.<mailhost>) protect inbound mail — they let sending servers verify your certificate before delivery, per RFC 7672. Protecting your outbound mail instead depends on each recipient publishing DANE and your provider validating it. This checker inspects the inbound TLSA records on your own MX.
Get the full picture with DMARCguard
Continuous monitoring, aggregate report parsing, and actionable insights for all your email authentication protocols.
Start Free