Mail to chuckmckinnon.com sat in the queue for days with "Error fetching TLSA record: DNSSEC validation failed". Its MX, mail.usefulinsight.com, is on Cloudflare, and behind Hetzner's resolvers _25._tcp.mail.usefulinsight.com answers TLSA with a signed CNAME to the zone apex, which has no TLSA record. That is the second hickory 0.26.3 bug #72 works around: it checks the denial against the name first asked for, not the CNAME's target, and calls a valid answer bogus. #72 put MX and address lookups through validated_lookup but left the TLSA lookup calling hickory directly. It goes through validated_lookup now: a signed CNAME is followed, the denial at the target validates, and the result is "no TLSA record", so delivery goes ahead without DANE as it should. A TLSA record that rechecks as insecure is treated as no policy, since DANE needs a signed one. Cloudflare's own resolver answers that name with a compact denial at the name itself, which hickory already accepts, so the new ignored test takes a resolver from INBUXA_TEST_DNS_TCP. Run against 185.12.64.2 over an SSH bridge from host1, hickory alone fails with "DNSSEC validation failed", as in production, and validated_lookup returns a non-bogus denial. smtp lib tests pass; check --all-targets is clean.