How do you verify DANE/TLSA for a mail server?

What a TLSA record actually pins

A TLSA record, defined in RFC 6698, lets a domain publish — in DNS — exactly which certificate or public key a given server is supposed to present, instead of leaving trust entirely up to whichever certificate authority issued the one a client happens to receive. For mail specifically, RFC 7672 defines how a sending SMTP server uses this to upgrade opportunistic STARTTLS into something an attacker on the network path can’t silently strip or downgrade — see does your mail server actually enforce STARTTLS? for why opportunistic STARTTLS needs a mechanism like this at all.

The record name itself encodes the service it protects: _port._protocol.hostname, so a TLSA record for SMTP on the standard port looks like _25._tcp.mail.example.com. That naming convention is why a TLSA record is specific to one service and port on a host, not a blanket statement about every service the hostname runs.

The four fields

A TLSA record’s data has four parts, read in order:

1. Certificate Usage — which trust model applies: 0 (PKIX-TA) and 1 (PKIX-EE) still require the certificate to chain to a public CA, just pinning which CA or which exact certificate within that chain; 2 (DANE-TA) and 3 (DANE-EE) don’t require a public CA at all, pinning a custom trust anchor or the end-entity certificate directly. RFC 7671’s operational guidance recommends 3 (DANE-EE) for new deployments — pin the actual server certificate, independent of any CA.
2. Selector — whether the match is against 0 (the full certificate) or 1 (only its SubjectPublicKeyInfo, the public key and its algorithm). Selector 1 is generally preferred because it survives a certificate renewal that reuses the same key pair, which 0 wouldn’t.
3. Matching Type — 0 (the full data, rarely used), 1 (a SHA-256 hash), or 2 (a SHA-512 hash) of whatever the selector pointed at.
4. Certificate Association Data — the actual hash value to compare against.

RFC 7671’s recommended combination for most new deployments is usage 3, selector 1, matching type 1 — pin the certificate’s public key, by SHA-256, directly, with no CA dependency at all.

Why it’s worthless without DNSSEC

A TLSA record is only as trustworthy as the DNS answer carrying it. If an attacker can intercept or spoof DNS responses — the same capability needed to redirect mail delivery in the first place — they could forge a matching fake TLSA record alongside a forged certificate, defeating the entire mechanism. This is why RFC 7671 requires DNSSEC to validate successfully for a TLSA record to count at all; a client that can’t validate the signature chain, or finds no signature, is required to ignore the record and fall back to ordinary opportunistic TLS rather than trust an unverifiable pin. See DNSSEC: what it actually protects for what that validation chain actually covers and the most common ways it breaks.

Checking one today

1. Query the TLSA record. AdminKit’s live DNS lookup tool doesn’t resolve the TLSA type yet — it currently covers A, AAAA, MX, TXT, NS, CAA, PTR, SOA and CNAME — so check it directly with a command-line resolver: dig _25._tcp.mail.example.com TLSA. An empty answer means no TLSA record is published for that service and port, which is the common case; DANE adoption on the receiving side of SMTP is still far from universal.
2. Confirm the zone is DNSSEC-signed. A TLSA record published in an unsigned zone provides no real protection, for the reason above — see DNSSEC: what it actually protects for how to tell whether a zone is actually signed and validating, not just that a record happens to exist.
3. Confirm the pinned certificate matches what the server actually presents. Run AdminKit’s live SSL/TLS check against the mail host to see the certificate it serves in a real handshake — see how to read a TLS/SSL certificate check result for the fields it reports — then compare that certificate’s public key hash by hand against the TLSA record’s Certificate Association Data. A mismatch means either the TLSA record is stale after a certificate renewal, or something more concerning is serving a different certificate than the domain published.

DANE and MTA-STS aren’t competitors

MTA-STS (RFC 8461) protects against the same STARTTLS-stripping downgrade using a web-hosted policy file instead of a DNSSEC-signed DNS record, which makes it easier to deploy but dependent on separate web hosting and its own CA-issued certificate. DANE needs no web policy but only works at all once a zone is DNSSEC-signed — a prerequisite plenty of domains still haven’t met. Running both means a sending server that supports either mechanism gets downgrade protection; neither one alone covers every sending server on the internet, since support for each is still growing independently.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.