⚓ DANE / TLSA Validator

How this DANE / TLSA checker works

DANE (RFC 6698) pins your mail server's TLS certificate directly in DNS. A sending server then verifies the handshake against that pin instead of trusting the public CA system on its own. For SMTP (RFC 7672) the pin lives in a TLSA record at _25._tcp.<mx-hostname>. Type a domain above and the tool resolves every MX host, fetches each TLSA record, and decodes it.

A typical SMTP TLSA record looks like this:

_25._tcp.mail.example.com  TLSA  3 1 1 <sha256-hash>

What do the three numbers mean?

Usage says what is being pinned. For SMTP, the right answer is 3 (DANE-EE), which pins your own end-entity certificate. Selector picks the full certificate (0) or just the SubjectPublicKeyInfo (1). Selector 1 survives a certificate renewal as long as the key stays put. Matching type says how the data is stored. 1 is a SHA-256 hash, which is the operational norm. For the full field breakdown, see the TLSA record reference.

The checker flags combinations that look wrong for SMTP. A CA-anchored usage (0 or 2) where DANE-EE (3) is expected is usually a copy-paste from a TLSA generator written for HTTPS.

DANE without DNSSEC does nothing

An unsigned TLSA record can be forged in transit, so sending servers ignore it and fall back to opportunistic STARTTLS. The checker confirms each TLSA answer came back with the resolver's AD (Authenticated Data) bit set, which is how you know a validating resolver actually checked the chain. If the bit is missing, the record is cosmetic. Postfix, Exim and Halon will not trust it for delivery.

What to do: if your zone is not signed yet, sort that out first. The DNSSEC checker walks the chain of trust and shows exactly where it breaks.

Why we ask three resolvers

A slow resolver or a stale answer can flip a verdict on its own. So the tool queries Google, Cloudflare and Quad9 in parallel and checks they agree on both the record set and the AD bit. A TLSA record that resolves on Google but not on Cloudflare will half-break delivery in the real world, so disagreement is surfaced as a finding rather than quietly hidden. The checker also normalises RFC 3597 generic-format answers (Cloudflare often returns TLSA in \# hex form, Google in presentation form) so the agreement test compares the same bytes either way.

DANE and MTA-STS, not DANE or MTA-STS

DANE and MTA-STS solve the same downgrade problem through different trust roots. DANE anchors in DNSSEC. MTA-STS rides on the WebPKI. Google and Microsoft honour MTA-STS. Postfix-heavy and academic networks prefer DANE. Run both and neither half of the internet falls back to plaintext. The TLS-RPT checker closes the loop, feeding you reports when senders cannot negotiate a safe channel.

What the grade is based on

The A to F grade combines several inputs: TLSA present on every MX, AD bit set, usage and matching-type sanity, resolver agreement, DNSSEC posture upstream, and a cross-check against MTA-STS on the same domain. The signal chips below the verdict show each input on its own, so you can see which one moved the grade.

Where to go next

DANE is one of three transport-security layers worth running together. See the MTA-STS checker for the WebPKI-anchored equivalent, the TLS-RPT checker for the reporting channel, and the DNSSEC checker for the chain DANE depends on. To see what the rest of the authentication stack looks like, the full domain checker covers SPF, DKIM and DMARC in one pass. DANE leans entirely on the chain DNSSEC provides, so if that part is hazy, What on earth is DNSSEC, and should your business care? explains why it matters here.