DANE TLSA Validation Report

Target:

Use example.com for SMTP MX, mail.example.com for direct SMTP, or https://www.example.com for HTTPS.

Service profile:

Pick SMTP MX for inbound mail; direct profiles use the target host with the selected port.

Port and transport:

Use profile defaults such as 25/TCP, 587/TCP, 993/TCP, or set custom TLS/DTLS details.

This browser-side report validates owner-name construction, TLSA field syntax, resolver AD evidence, and optional pasted certificate digests. It does not perform a live SMTP, IMAPS, or HTTPS certificate handshake from the browser.

Observed digest mode:

Keep off unless you have an SPKI or full-certificate SHA-256/SHA-512 hex digest.

Observed digest:

Paste {{ observedDigestPlaceholder.toLowerCase() }}; spaces, colons, and dashes are ignored.

Resolver:

Use one resolver view for the main evidence; comparison can add Cloudflare vs Google AD checks.

Compare resolvers:

Turn on when investigating propagation, DNSSEC validation, or resolver cache differences.

Checking disabled:

Use for diagnostics; AD-based confidence is treated as advisory when CD is enabled.

Owner route	TLSA evidence	Verdict	Copy
{{ row.endpoint }} {{ row.route }} `{{ row.ownerName }}` {{ row.addresses }}	{{ row.tlsa }} {{ row.dnssec }} {{ row.lookup }}	{{ row.verdict }} {{ row.note }}

No DANE route readiness rows are available for this report.

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 }}

No TLSA records were returned for the selected owner names.

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 }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A TLS certificate usually proves identity through the public certificate-authority system. DANE adds a DNSSEC-backed path for publishing which certificate or public key a service should present, using a TLSA record tied to the service name. That makes DNS publication, DNSSEC validation, and certificate matching part of one trust decision instead of three checks that can disagree.

The practical appeal is strongest where automated systems connect without a person watching certificate prompts. Mail transfer between domains is the classic case: one server discovers a recipient domain's MX hosts, starts TLS if the peer supports it, and needs a way to reject a forged or downgraded endpoint. DANE can turn that opportunistic TLS step into authenticated TLS when the DNSSEC chain is valid and the TLSA data matches the certificate material.

TLSA records are compact, but each field changes the meaning of the result. A record is not just a certificate hash in DNS. It says which certificate association model is being used, which certificate bytes are selected, how those bytes are represented, and what association data must match. A syntactically valid record can still be operationally weak when the wrong owner name is queried, DNSSEC authentication is absent, or rollover planning leaves only one usable association.

Certificate usage: Chooses whether the association depends on PKIX validation, a DANE trust anchor, or the end-entity certificate itself.
Selector: Chooses the full certificate or the SubjectPublicKeyInfo public-key structure.
Matching type: Chooses exact bytes, SHA-256, or SHA-512 for the association data.
Owner name: Combines the service port, transport, and host, such as _443._tcp.www.example.com.

Common DANE TLSA validation contexts
Context	Owner-name concern	Trust concern
Inbound SMTP	Follow MX records before building `_25._tcp` names for each exchanger.	SMTP DANE normally depends on DANE-TA(2) or DANE-EE(3) records and authenticated DNSSEC answers.
Direct mail or web service	Build the owner name from the selected host, port, and transport without MX expansion.	PKIX-bound usages may still rely on normal certificate-path validation.
Certificate rollover	Check that the published association matches the service that will present the new certificate.	Overlapping usable TLSA associations reduce the chance of breaking clients during renewal.

DANE TLSA route from service name through DNSSEC authenticated TLSA data to certificate matching

Two mistakes cause many false readings. The first is querying the wrong owner name, often by checking a mail domain directly when inbound SMTP should follow MX records first. The second is treating a visible TLSA answer as trusted even when DNSSEC authentication is missing or checking was deliberately disabled.

A good DANE review separates publication from proof. DNS can show that a service has TLSA records, but a complete deployment also needs secure DNSSEC validation, usable TLSA parameters, addressable endpoints, coordinated certificate rollover, and a separate live certificate check when the actual served certificate matters.

How to Use This Tool:

Start by choosing the service path. The selected profile controls whether the report follows MX records first or builds one TLSA owner name directly from the target host, port, and transport.

Enter a domain, hostname, URL, or email-style address in Target. The report normalizes it to a DNS hostname before lookup.
Choose Service profile. Use SMTP MX route for inbound mail domains, SMTP host for one relay hostname, or a direct profile such as Submission, IMAPS, HTTPS, or Custom TLS/DTLS service.
Confirm Port and transport. Profile defaults include 25/TCP for SMTP MX, 587/TCP for mail submission, 993/TCP for IMAPS, and 443/TCP for HTTPS.
Leave Observed digest mode set to No digest comparison unless you already computed a certificate or SPKI digest. If you enable it, paste the matching SHA-256 or SHA-512 hex digest in Observed digest.
Open Advanced when you need a resolver choice, Cloudflare and Google comparison, or a Checking disabled diagnostic run.
Select Build report. Check Owner Route first, then read TLSA Ledger, Validation Checks, DANE Route Readiness, and Resolver AD when resolver comparison is enabled.

If validation stops before the lookup, check that the target is a hostname, the port is an integer from 1 to 65535, the transport is one of the listed choices, and any pasted digest has 64 hex characters for SHA-256 or 128 hex characters for SHA-512 after spaces, colons, and dashes are removed.

Interpreting Results:

Read Validation Checks before acting on individual records. Pass means the checked condition is coherent for the selected profile. Review means the report found data but confidence is limited by rollover, resolver, profile, or comparison caveats. Stop marks a condition that prevents DANE readiness for that part of the route.

Owner Route confirms the lookup path. For SMTP MX, a null MX stops the route because the domain advertises that it does not accept mail. A missing A or AAAA answer stops endpoint readiness even when a TLSA owner name can be built.

TLSA Ledger is the record-level audit. PKIX-TA(0) and PKIX-EE(1) records can be meaningful for some TLS uses, but the SMTP profiles treat them as incompatible with RFC 7672-style SMTP DANE. Exact matching is also flagged for review because certificate renewal can break it unless the selected certificate bytes remain unchanged.

Do not treat a high DANE Route Readiness score as proof that the live service is serving the expected certificate. Use the score to find DNS publication, DNSSEC, digest, and owner-name issues, then confirm the actual TLS certificate path with a separate live connection check.

Technical Details:

TLSA owner names are service-specific. The port label and transport label are prepended to the base service host, so port 25 over TCP at mx1.example.net becomes _25._tcp.mx1.example.net. Direct TLS services use the entered host after normalization. SMTP MX checks first resolve MX records, sort and deduplicate mail exchangers by preference and name, and then build one owner name per exchanger.

DNSSEC status controls whether a TLSA RRset can carry DANE trust value. The AD flag means the selected recursive resolver reported authenticated data. The CD flag requests checking-disabled behavior, so CD-enabled results are diagnostic evidence rather than normal resolver-validated trust evidence.

Rule Core:

DANE TLSA field and validation rules
Area	Accepted or preferred condition	Review or stop condition
Owner route	A direct host or each MX host produces a `_port._transport.host` owner name.	Null MX, NXDOMAIN, no MX with no implicit address fallback, or no direct owner stops route discovery.
Endpoint addresses	Each endpoint host returns at least one A or AAAA answer.	No address answers stop readiness for that endpoint.
TLSA fields	Usage is 0 to 3, selector is 0 or 1, matching type is 0 to 2, and association data is valid hex.	Unsupported field values, missing association data, odd-length hex, or wrong digest length stop the record.
SMTP DANE profile	SMTP owner names publish usable DANE-TA(2) or DANE-EE(3) records.	PKIX-TA(0) or PKIX-EE(1) records stop SMTP compatibility in the report.
DNSSEC evidence	AD is true for every owner with TLSA records while CD is off.	Missing AD stops or reviews the run; CD-enabled diagnostics are advisory.
Observed digest	At least one comparable TLSA row matches the supplied certificate or SPKI digest.	Comparable rows with no match stop the digest check; no comparable selector and matching type is review.

TLSA Parameter Map:

TLSA parameter meanings
Field	Values used by the report	Why it matters
Certificate usage	0 PKIX-TA, 1 PKIX-EE, 2 DANE-TA, 3 DANE-EE	Decides whether public CA validation remains part of the trust decision or DNSSEC-published DANE data is enough.
Selector	0 full certificate, 1 SubjectPublicKeyInfo	Controls whether matching follows the entire certificate object or the public-key structure.
Matching type	0 exact, 1 SHA-256, 2 SHA-512	Controls whether association data is raw selected material or a digest of it.
Association data	Hex string, with 64 hex characters for SHA-256 and 128 for SHA-512	Supplies the bytes or digest that must match the certificate material selected by the first three fields.

Formula Core:

DANE Route Readiness converts each owner report into a 0 to 100 score for comparison. The score is a report summary, not a DANE standard value.

R_{raw} = A + T + D + U

DANE readiness score components
Component	Points	Condition
`A` address coverage	20	Endpoint host has at least one A or AAAA answer.
`T` TLSA presence	25	Owner name returns one or more TLSA records.
`D` DNSSEC evidence	25 or 10	25 when AD is true; 10 when records exist but CD is enabled or AD is unclear.
`U` usable TLSA records	30 or 20	30 when every record is usable with no review note; 20 when at least one record is usable.

Verdict bounds keep the score from overstating a problem route: Pass is raised to at least 85, Review is clamped from 50 to 84, and Stop is capped at 45. An owner with addresses, TLSA records, AD=true, and all usable records scores 20 + 25 + 25 + 30 = 100.

Accuracy and Privacy Notes:

The report checks DNS publication and optional pasted digest comparison. It does not open an SMTP, IMAPS, HTTPS, or DTLS session, and it does not fetch the certificate currently served by the endpoint.

The target, discovered MX names, derived TLSA owner names, and resolver-comparison owner names are sent to the selected public DNS resolvers.
A pasted observed digest is normalized and compared in the browser against returned TLSA data; it is not needed for the DNS resolver queries.
Resolver AD behavior depends on DNSSEC validation, resolver policy, cache state, and whether Checking disabled was enabled.
Missing TLSA records can mean the service has no DANE deployment, or it can mean the profile, port, transport, or owner name is wrong.

Worked Examples:

A domain such as example.net with two inbound mail exchangers should be checked with SMTP MX route and port 25/TCP. A strong report shows two Owner Route rows, address answers for both endpoints, TLSA records in TLSA Ledger, Resolver AD evidence as Pass, and readiness scores at or above the pass floor.

An HTTPS host such as www.example.net uses the HTTPS profile and port 443/TCP. If TLSA Ledger returns a PKIX-bound usage 1 record with SHA-256 matching, the row can parse while still receiving Review because PKIX-bound DANE still relies on normal certificate-path validation.

A certificate rollover check usually starts with a digest. Select SPKI SHA-256, paste the 64-character digest from the observed certificate's SubjectPublicKeyInfo, and run the report. Observed digest comparison as Pass means at least one comparable selector and matching type row matched; Stop means comparable rows existed but none matched.

A common troubleshooting case is a visible TLSA row with Resolver AD evidence marked Stop. First rerun with the intended resolver and Checking disabled off. If AD is still missing, inspect the DNSSEC chain separately before treating the TLSA answer as DANE trust evidence.

FAQ:

Why does an SMTP MX check create several TLSA owner names?

Inbound SMTP follows MX records before connecting. Each mail exchanger can have its own _25._tcp TLSA owner name, so the report checks every discovered route.

What does AD evidence mean?

AD means the selected resolver reported authenticated DNSSEC data for the TLSA response. Without AD, visible TLSA text is not enough to treat the answer as trusted DANE evidence.

Why does the report reject my digest?

The selected digest mode determines the required length. SHA-256 needs 64 hex characters and SHA-512 needs 128 after separators are removed, and the digest is compared only with TLSA rows that use the same selector and matching type.

Why can a valid TLSA record still show Review?

Review notes appear for deployable but fragile or profile-sensitive choices, such as exact matching, PKIX-bound usage on direct TLS profiles, a single usable record with little rollover cushion, or advisory CD-enabled DNSSEC evidence.

Does this verify the live server certificate?

No. The report checks DNS answers and optional pasted digest comparison. Use a live TLS inspection when you need to prove which certificate the service is presenting right now.

Glossary:

DANE: DNS-Based Authentication of Named Entities, the DNSSEC-backed method for binding TLS certificate associations to service names.
TLSA: The DNS record type that publishes certificate association data for DANE.
DNSSEC: DNS Security Extensions, used here to authenticate the DNS answer that carries TLSA data.
AD: Authenticated Data, the resolver response flag that indicates DNSSEC validation succeeded according to that resolver.
CD: Checking Disabled, a query flag used for diagnostics when the client wants raw data without normal resolver-side validation.
SPKI: SubjectPublicKeyInfo, the certificate public-key structure used by selector 1 TLSA records.

References:

RFC 6698: The DNS-Based Authentication of Named Entities TLS Protocol: TLSA, RFC Editor, August 2012.
RFC 7671: DANE Protocol Updates and Operational Guidance, RFC Editor, October 2015.
RFC 7672: SMTP Security via Opportunistic DANE TLS, RFC Editor, October 2015.
RFC 4035: Protocol Modifications for the DNS Security Extensions, RFC Editor, March 2005.
DNS-Based Authentication of Named Entities Parameters, IANA, last updated 2026-02-05.