DANE TLSA Validation Report
Report online DANE TLSA validation for SMTP, HTTPS, and custom TLS services with MX routes, AD checks, parser notes, digest matching, and exports.DANE TLSA report
| Owner route | TLSA evidence | Verdict | Copy |
|---|---|---|---|
|
{{ row.endpoint }}
{{ row.route }}
{{ row.ownerName }}
{{ row.addresses }}
|
{{ row.tlsa }}
{{ row.dnssec }}
{{ row.lookup }}
|
{{ row.verdict }}
{{ row.note }}
|
| Owner | Usage | Selector | Match type | Association data | TTL | Verdict | Copy |
|---|---|---|---|---|---|---|---|
| {{ row.ownerName }} | {{ row.usage }} | {{ row.selector }} | {{ row.matching }} | {{ row.association }} |
{{ row.ttl }} |
{{ row.verdict }}
{{ row.note }}
|
| Check | Status | Notes | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.status }} | {{ row.note }} |
| Owner | Resolver | DNSSEC read | Lookup ms | Notes | Copy |
|---|---|---|---|---|---|
| {{ row.ownerName }} | {{ row.resolverLabel }} | {{ row.statusText }}; AD {{ row.adText }}; {{ row.answerCount }} answers; {{ row.usableCount }} usable | {{ row.lookup }} |
{{ row.verdict }}
{{ row.note }}
|
1. The web tool provided is for general informational purposes only and should not be considered as professional advice.
2. We do not guarantee the accuracy, completeness, or reliability of the tool.
3. The use of this tool is at your own risk, and we are not liable for any damages or losses resulting from its use.
4. We reserve the right to modify or discontinue the tool without prior notice.
5. By embedding the tool, you agree to indemnify us from any claims arising from its use.
6. We may use Google Analytics or similar tools for data collection and analysis.
7. Please review this disclaimer periodically, as we may update it without notice.
If you do not agree with any part of this disclaimer, please refrain from embedding the tool on your website.
Introduction
DANE TLSA records bind TLS service names to certificate or public-key material through DNSSEC. For mail delivery, DANE can let SMTP clients authenticate a destination MX host without relying only on the public CA system.
The owner name is built from service port, transport, and host, such as _25._tcp.mail.example.com. SMTP domain checks add one extra step: resolve MX records first, then build TLSA owner names for the selected mail exchangers.
A useful DANE report has to show the route, the TLSA records, the DNSSEC AD signal, parsing issues, profile fit, and optional digest comparison against known certificate material.
Technical Details
TLSA RDATA contains four parts: certificate usage, selector, matching type, and association data. Usages 0 and 1 remain tied to PKIX validation. Usages 2 and 3 are DANE trust-anchor and DANE end-entity modes. Selectors choose the full certificate or SubjectPublicKeyInfo, and matching types choose exact data, SHA-256, or SHA-512.
| TLSA owner | _port._transport.host |
| SMTP MX profile | resolve MX, then query each MX host owner |
| DANE-TA(2) | trust-anchor association |
| DANE-EE(3) | end-entity association |
| Digest comparison | only comparable when selector and matching type match the selected digest mode |
The report queries public DNS-over-HTTPS resolvers, parses MX, A, AAAA, CNAME, and TLSA answers, and evaluates record shape. SMTP delivery profiles are stricter about usage 2 and 3 because RFC 7672 focuses on DANE for SMTP. The optional observed digest can check SPKI SHA-256, SPKI SHA-512, certificate SHA-256, or certificate SHA-512 against matching TLSA rows.
Everyday Use & Decision Guide
Use SMTP MX route when checking inbound mail for a domain. Use a direct service profile for submission, IMAPS, HTTPS, or a custom host and port. Enable resolver comparison when diagnosing propagation, DNSSEC, or cache differences.
- Use Owner Route to confirm which host names were checked.
- Use TLSA Ledger to inspect usage, selector, matching type, association preview, and row status.
- Use Validation Checks for stop or review notes.
- Use Resolver AD to compare answer counts, usable records, and AD state across resolvers.
- Use digest comparison only when you already have a trustworthy digest from another certificate inventory or TLS scanner.
A pass in this report is DNS evidence, not a full TLS handshake. It does not retrieve the live certificate chain from the endpoint.
Step-by-Step Guide
- Enter a mail domain, hostname, URL, or email address. The tool reduces it to the domain or host.
- Select the service profile, port, and transport.
- Choose resolver behavior, CD=1 handling, and optional observed digest mode.
- Build the report and review route, TLSA, validation, resolver, and JSON tabs.
- Export CSV, DOCX, or JSON evidence for a DNSSEC or mail-security change record.
Interpreting Results
Stop means the report found a blocking problem such as missing endpoint addresses, no TLSA records, unusable RDATA, or missing AD when AD is required for confidence.
Review means the record may be usable but has caveats, such as full-certificate matching that changes on every certificate renewal or a PKIX-bound usage that still depends on public CA validation.
Pass means the parsed TLSA record is coherent for the selected profile and resolver evidence. Confirm live service behavior separately before declaring the deployment complete.
Worked Examples
Inbound SMTP domain. Enter example.com with SMTP MX route. The route tab lists MX hosts and generated _25._tcp owner names before the TLSA ledger evaluates each RRset.
HTTPS host. Enter https://www.example.com and choose HTTPS. The target is reduced to the host, and the owner becomes _443._tcp.www.example.com.
Digest mismatch. Paste an SPKI SHA-256 digest and select the matching mode. Rows with selector 1 and matching type 1 become comparable, and the notes identify match or mismatch.
FAQ
Does this perform a TLS connection to the service?
No. It checks DNS route and TLSA publication through public resolvers. Use a TLS scanner or OpenSSL command for live certificate retrieval.
Why does SMTP mode resolve MX first?
DANE for SMTP authenticates the selected mail exchanger hosts. The TLSA owner is built from each MX host, not directly from the bare domain.
What does AD false mean?
The resolver response did not report authenticated DNSSEC data. For DANE, that should slow down trust decisions.
Why are some TLSA records marked review instead of stop?
Some combinations are valid but operationally sensitive, such as full certificate associations that need updates at every certificate rotation.
Glossary
- TLSA
- DNS record type that publishes a TLS certificate association.
- DANE-EE
- End-entity certificate usage 3.
- DANE-TA
- Trust-anchor certificate usage 2.
- AD flag
- Resolver signal that DNSSEC validation succeeded for the answer.
References
- RFC 6698: DANE TLSA, RFC Editor.
- RFC 7671: DANE Operational Guidance, IETF.
- RFC 7672: SMTP Security via DANE TLS, IETF.
- IANA DNS Parameters, IANA.