DNS trust, part 2 of 3 · Reviewed October 24, 2026
DNSSEC lets a validating resolver check whether DNS data is authentic. DANE takes the next step: an application can use authenticated DNS information to decide which TLS certificate or key should identify a service. The practical question is whether the application actually performs that check.
For mail administrators, that question has a concrete answer in SMTP DANE. For website owners, publishing a record alone should never be treated as proof that visitors’ browsers now authenticate the site through DANE.
What a TLSA record describes
DANE stands for DNS-based Authentication of Named Entities. Its TLSA record associates a service with certificate information. The record’s name includes a port and transport: _25._tcp.mail.example.com illustrates an SMTP service on TCP port 25. This is an example name, not a live deployment.
Three numeric fields explain how to interpret the remaining data:
- Certificate usage: whether the association constrains conventional certificate-authority validation or establishes a DNSSEC-backed trust relationship.
- Selector: whether to examine the complete certificate or its SubjectPublicKeyInfo, the structure containing the public key and algorithm information.
- Matching type: whether to compare the selected data directly or compare its cryptographic hash.
For example, 3 1 1 means DANE end-entity authentication, public-key information, and SHA-256. It does not mean “TLS version 3” or a security score. These fields are defined in RFC 6698, with later operational clarifications in RFC 7671.
For the underlying handshake and certificate concepts, start with SysSeder’s TLS guide.
Why mail transport is a useful application
An email address does not directly identify the next server connection. Sending servers discover mail destinations through MX records and negotiate transport security with the receiving server. Basic opportunistic STARTTLS can be vulnerable to an attacker suppressing the announcement that TLS is available.
SMTP DANE uses DNSSEC-authenticated information to discover the destination and establish an enforceable TLS authentication requirement. When applicable usable TLSA records are securely obtained, a supporting sender must satisfy the DANE requirements rather than silently treating an authentication failure as permission to deliver in cleartext. The detailed decision rules are in RFC 7672.
This protects a transport hop between mail servers. It does not encrypt a message end to end for its human recipient, determine whether the message is honest, or validate the visible From address. Those are separate questions. Part 3 of this series examines SPF, DKIM and DMARC.
Deployment is real, but direction matters
Microsoft’s current documentation describes outbound SMTP DANE as enabled by default for Exchange Online and used when a destination advertises support. It separately documents setup and prerequisites for inbound SMTP DANE. That distinction matters: checking other organizations’ records when sending mail is different from publishing and maintaining the information they need when sending to you. See Microsoft’s SMTP DANE guidance.
A third-party mail gateway adds another boundary. Identify which system receives internet mail and which system forwards it internally before assuming a setting protects the whole route. Ask the provider which hops it validates, who controls the relevant DNS records, and how failures appear in delivery reports.
Do not transfer SMTP assumptions to browsers
A TLSA record does not install a trust anchor in a browser or switch its certificate verifier to a different authentication model. DANE needs a participating client and an appropriate application profile.
Chrome’s published documentation describes its certificate verifier, root store, and locally managed trust decisions. That is the documented browser trust machinery website operators must account for; an SMTP deployment is not evidence that a website’s certificate will be accepted. Check the exact client and platform rather than relying on blanket claims about every browser. Read the Chrome Root Store FAQ.
Keep DNS and certificates in step
Certificate renewal and key rotation become coordinated operational changes. If the server presents a new key while resolvers still cache an association with the old one, authentication can fail and mail can be deferred. RFC 7671 describes publishing overlapping associations ahead of a rollover and allowing caches to age before changing the service.
Before a change, record the active certificate, TLSA parameters, DNSSEC validation result and cache lifetimes. Afterward, check the actual service handshake and delivery behavior, not just whether a TLSA lookup returns text. A readable record establishes presence; successful authenticated matching establishes considerably more.
For preliminary DNS configuration evidence, the SysSeder DNS Inspector can help you inspect public records and resolver indications. It does not audit DANE or TLSA matching, so it cannot establish that a mail-server handshake satisfies DANE.