tls.dane.unsigned

DANE/TLSA Records Lack Resolver-Attested DNSSEC

What we check

We query TLSA records for each MX hostname and inspect the upstream resolver's AD (Authenticated Data) bit. The AD bit indicates that the resolver validated the DNSSEC chain for this response. Without it, the TLSA data cannot be trusted as DNSSEC-authenticated.

What this finding means

TLSA records exist for the MX hostname, but the DNS response does not carry DNSSEC authentication. Either the domain's zone is not DNSSEC-signed, the signing chain is broken, or the resolver does not perform DNSSEC validation.

DANE senders ignore unsigned TLSA records entirely (RFC 7671 §4.1) — the records are treated as if they do not exist, and the connection falls back to opportunistic TLS.

Why it matters

DANE is inactive. The TLSA records have no effect without DNSSEC. Publishing them without signing the zone creates a false sense of security.
No delivery impact. Unlike a DANE mismatch, unsigned TLSA records do not break delivery — DANE senders simply ignore them and proceed with opportunistic TLS.
Fix the zone, not the records. The TLSA records themselves may be correct; the missing piece is DNSSEC on the zone.

How to fix

Enable DNSSEC on the domain's DNS zone through your DNS provider or registrar.

Verify the DNSSEC chain:

dig +dnssec TLSA _25._tcp.mail.example.com
# Look for the AD flag in the response header

After DNSSEC is active, re-verify that the TLSA records match the live certificate — they are now enforceable.

How it's graded

Unsigned TLSA records are an informational finding with no grading penalty. The records are effectively dormant without DNSSEC. See Grading Methodology for the full scoring model.

Evidence example

$ dig +dnssec TLSA _25._tcp.mail.example.com
;; flags: qr rd ra; QUERY: 1, ANSWER: 1
                     ^^ no AD flag — response is not DNSSEC-validated
TLSA records present but not DNSSEC-authenticated — DANE senders will ignore them