Inputs
Example
_25._tcp.mail.example.com -> 3 1 1 <sha256> plus secure DNSSEC context and live certificate comparison.
DANE Validator
Validate DANE service owner names, TLSA RRsets, DNSSEC context, and implemented DANE-EE live comparisons.
Use it to validate TLSA records together with the DNSSEC context required for DANE.
Judging whether DANE actually protects a service
DANE answers a question classic PKI cannot: is the certificate this server just presented the one its operator intended, as stated in DNS under DNSSEC protection? For SMTP transport this matters structurally, because port-25 TLS is opportunistic by default — a downgrade attacker between two MTAs can simply strip STARTTLS unless the sending side has an independent reason to insist on TLS with a specific key. A DNSSEC-signed TLSA record is that reason, and sending MTAs configured for DANE enforce it hard.
Enforcement cuts both ways: a wrong TLSA record does not degrade gracefully, it makes DANE-validating senders refuse delivery. This validator therefore judges a deployment the way a validating sender would, as a whole: the service owner name must be formed from the actual MX host, the TLSA parameter combination must be coherent, the DNSSEC context must authenticate the answer, and — on request — the live certificate must actually match the published association data. Any single miss breaks the entire promise.
Evaluating a deployment end to end
Evaluate in the order a sender validates. First the owner name: for mail, TLSA lives at _25._tcp under the MX hostname — the host receiving connections, not the recipient domain. Then the parameter sanity: certificate-usage, selector, and matching type must form an operationally sensible combination, with DANE-EE over SPKI with SHA-256 (3 1 1) as the widely deployed default. Then the DNSSEC verdict, because an unsigned TLSA answer is decorative: without authentication, an attacker who can spoof DNS can substitute records, which is exactly the attack DANE exists to close.
Finish with the live comparison against the presented certificate, and read a mismatch operationally: the classic incident is a certificate renewal that changed the public key while the TLSA record kept the old digest — from the outside indistinguishable from an attack, and validating senders treat it as one. For a rollover, publish the next association alongside the current one at least two relevant TLSA TTLs before the credential change, allow publication and cache propagation, switch and verify every endpoint, then retire the old record only after the old credential is nowhere in use.
Evaluation scope and its boundaries
Pasted TLSA records stay in the browser; live checks use the guarded same-origin endpoint for public hosts on permitted ports. The validator assesses one service binding at a time. Within each exact usage, selector, and matching-type group, any current association may match, permitting an old/new rollover; a clean cross-client result requires every supported published group to match. Mixed digest groups are not a universal OR. This host-level check does not authenticate the recipient domain's MX RRset or alias-routing chain. DANE-TA usage 2 is reported unsupported because this path does not build the full chain to the selected trust anchor and validate the SMTP reference identity. It does not audit sending-MTA policy, trust-store configuration, or monitoring, and it does not build records.
Frequently asked questions
Which name carries the TLSA record for mail?
The MX hostname, not the recipient domain: _25._tcp.mail.example.com when mail for example.com is received by mail.example.com. Records published under the bare domain are a common and completely ineffective misplacement.
Why is TLSA without validated DNSSEC worthless?
Because the record's whole role is to be the trustworthy statement of the expected key. Unsigned, it can be spoofed by the same attacker DANE is meant to stop — a sender that cannot authenticate the answer rightly ignores it.
What breaks most DANE deployments in practice?
Renewals. The certificate or key changes, the TLSA record does not, and DANE-validating senders start refusing mail. Choosing SPKI-based association (selector 1) and keeping the key pair across renewals makes routine renewals a non-event.
Should I evaluate 2 x x records differently from 3 x x?
Yes. Usage 3 (DANE-EE) pins the end-entity credential itself; self-signed, WebPKI name, and expiry state do not negate a matching DNSSEC-secure association. Usage 2 (DANE-TA) requires the full chain, association to the selected trust anchor, and SMTP reference-identity validation. This validator reports usage 2 unsupported until all of those checks are available.
Does DANE protect my users' browsers?
Effectively no. Mainstream browsers validate the web PKI, not TLSA. DANE's production habitat is MTA-to-MTA SMTP, where a meaningful share of validating senders enforce it and delivery genuinely depends on the records being right.
How does DANE relate to MTA-STS?
Same threat, different trust roots: DANE anchors in DNSSEC, MTA-STS in HTTPS and the web PKI, and each covers senders the other cannot. Well-run mail domains publish both; this page judges only the DANE half.