DANE TLSA Binds TLS Service Keys Through DNSSEC

Wed, 23 Sep 2026 00:00:00 +0000

DANE TLSA Binds TLS Service Keys Through DNSSEC

TLS normally authenticates a server through certificate validation rules defined by the application and its trust model. DANE adds a DNS-based binding: a TLSA resource record associates a service endpoint with certificate or public-key material, while DNSSEC supplies authenticated DNS data for that association.

The boundary is strict. A TLSA RRset that is insecure or has an indeterminate DNSSEC state cannot serve as an authenticated DANE association. DANE therefore depends on DNSSEC validation rather than treating ordinary DNS transport as sufficient evidence.

TLS-RPT Exposes SMTP TLS Failures as Aggregate Reports

Wed, 23 Sep 2026 00:00:00 +0000

SMTP transport security has an observability problem. A recipient domain can publish an MTA-STS policy or DANE TLSA records, yet many failures occur on remote sending systems: certificate validation can fail, an MX host can become unreachable, STARTTLS negotiation can break, or a published transport policy can be invalid. The recipient needs telemetry from those senders to distinguish a working deployment from a policy that silently blocks delivery.

SMTP TLS Reporting, commonly called TLS-RPT, defines that telemetry channel in RFC 8460. A recipient domain publishes a DNS TXT record that names one or more report destinations. Participating sending systems then produce aggregate reports describing successful policy-compliant TLS sessions and failures encountered while delivering mail to that domain.

DANE on Nalar

DANE TLSA Binds TLS Service Keys Through DNSSEC

DANE TLSA Binds TLS Service Keys Through DNSSEC

TLS-RPT Exposes SMTP TLS Failures as Aggregate Reports