How this DANE / TLSA checker works
DANE (DNS-based Authentication of Named Entities) lets you pin your mail server's TLS certificate directly in DNS, so a sending server can verify the certificate without relying solely on the public CA system. For SMTP, the pin lives in a TLSA record published at _25._tcp.<mx-hostname> (RFC 7672). It works alongside MTA-STS and TLS-RPT to protect inbound mail in transit.
Enter a domain below. The checker resolves its MX hosts, fetches the TLSA record for each, and decodes the three TLSA parameters: certificate usage (for SMTP, 3 / DANE-EE is recommended), selector (full certificate or SubjectPublicKeyInfo), and matching type (SHA-256 is the operational norm). For a field-by-field reference, see the TLSA record reference.
DANE only works if the TLSA record is DNSSEC-signed. An unsigned record can be forged, so sending mail servers ignore it. This tool confirms the TLSA answer was returned with the resolver's AD (Authenticated Data) bit set. If you have not enabled DNSSEC yet, validate your chain of trust first with the DNSSEC checker.
DANE / TLSA Validator
Validate the TLSA records on your mail servers and confirm they are DNSSEC-signed.
Try an example: ietf.org · nlnetlabs.nl · debian.org · posteo.de
Validation results
Frequently Asked Questions
Common questions about DANE, TLSA records, and SMTP transport security.
What is DANE, and how is it different from MTA-STS?
Both force a sending server to use TLS when it delivers mail to you, but they trust different things. MTA-STS publishes a policy over HTTPS and leans on the public certificate authority system. DANE publishes a TLSA record in DNS that pins your certificate or its public key directly, and it leans on DNSSEC instead of the CA system. Many operators run both: MTA-STS for the wide base of senders that support it, and DANE for senders (Postfix, for example) that prefer DNSSEC-based pinning.
Why does DANE need DNSSEC?
A TLSA record tells a sender which certificate to expect. If an attacker could rewrite that record in transit, they could point it at their own certificate and defeat the whole point. DNSSEC signs the record so the sender can confirm it really came from you. Without DNSSEC the record carries no weight, and sending servers ignore it. That is why this tool checks the AD (Authenticated Data) bit on the answer, not just whether a TLSA record exists.
Where do DANE records live for email?
For SMTP, the TLSA record sits at _25._tcp.<mx-hostname>, one per mail server, where 25 is the SMTP port. So if your MX is mail.example.com, the record name is _25._tcp.mail.example.com. This tool resolves your MX hosts first and then checks the TLSA record on each one.
What do the three numbers in a TLSA record mean?
A TLSA record reads usage selector matching-type data, for example 3 1 1 <hash>. Usage says what is being pinned: for SMTP, 3 (DANE-EE, your own certificate) is the usual choice. Selector says whether you pinned the full certificate (0) or just its public key (1). Matching type says how the data is stored: 1 is a SHA-256 hash, which is the common choice because it survives a certificate renewal as long as the key stays the same. The tool flags combinations that are unusual for SMTP so you can spot a misconfiguration.
My TLSA records are there but show as not DNSSEC-signed. What now?
It means the zone holding the TLSA record is not signed, so the records do nothing. Enable DNSSEC for the domain at your DNS host and registrar, confirm the chain with the DNSSEC checker, then run this DANE check again. Only once the AD bit comes back set will sending servers trust the pin.
Need help setting up DANE or DNSSEC?
This tool is provided by OSH.co.za, specialists in email deliverability. For a full picture of your domain's mail setup, run the domain checker, which covers SPF, DKIM, DMARC, MX, MTA-STS, and more.