DANE / TLSA Checker

🛡 Deliverability & security

Check a domain’s SMTP DANE records (TLSA) and whether they’re DNSSEC-validated.

No sign-up required Runs on our own infrastructure Also available via API
Try:

Runs on our diagnostic API. We don’t attach your input to an account for these free tools; short-lived rate-limit/security logs may exist, and requests are rate-limited per IP.

SMTP’s dirty secret is that its encryption is optional and unauthenticated. STARTTLS is opportunistic: if the TLS negotiation is stripped or the certificate is bogus, most sending servers shrug and deliver in cleartext anyway rather than bounce the mail. DANE closes that gap. It publishes, in DNS, a cryptographic fingerprint of the certificate your mail server is supposed to present — so a sender can verify it’s talking to the real server over real TLS, and refuse to deliver if it isn’t. The catch is that it only works if the DNS answer itself can be trusted, which is why DANE is inseparable from DNSSEC.

What a TLSA record is

DANE for SMTP lives in a TLSA record at _25._tcp.<mx-host> — note that it’s published per MX host, not on the domain itself. The mechanism is defined in RFC 6698, with the SMTP-specific rules in RFC 7672. Each record has three numeric fields plus the fingerprint:

  • Usage — how to interpret the association. For SMTP the useful values are 2 (DANE-TA, trust anchor: pin your CA) and 3 (DANE-EE, end entity: pin the leaf certificate directly). 3 is the most common because it doesn’t depend on a public CA at all.
  • Selector — whether the fingerprint covers the full certificate (0) or just its public key (1). Pinning the key (1) lets you renew the cert without changing the TLSA record, as long as you keep the key.
  • Matching type — how the data is presented: full (0), SHA-256 (1), or SHA-512 (2). SHA-256 is standard.

This tool decodes all three fields for every MX host and tells you what the record is actually pinning.

DANE requires DNSSEC — no exceptions

A TLSA record is only meaningful if the sender can trust that the DNS answer wasn’t forged. That trust comes entirely from DNSSEC. Without a valid signed chain, a sending server treats the TLSA record as absent and falls back to opportunistic TLS — so an unsigned TLSA record buys you nothing. Worse, a broken or mismatched signed record can cause DANE-aware senders to refuse delivery, turning a security feature into an outage. Always confirm the zone validates with the DNSSEC Checker before and after publishing TLSA records. This tool flags whether the records it found are actually DNSSEC-validated, not just present.

DANE vs MTA-STS — and why coverage matters

DANE and MTA-STS solve the same problem — stopping TLS downgrade on inbound SMTP — but anchor trust differently: DANE in DNSSEC, MTA-STS in the web PKI plus an HTTPS-hosted policy. Many well-run domains publish both, since sender support differs. If you go with DANE, publish a TLSA record for every MX host, including backups and lower-priority records; a sender may try any of them, and one uncovered host reopens the downgrade path. To confirm the underlying TLS actually negotiates, pair this with the SMTP Test and the broader Email Health Check.

Frequently asked questions

Why does DANE require DNSSEC?
DANE puts a cert fingerprint in DNS; a sender can only trust it if the answer is provably unforged, which is what DNSSEC signs. Without a valid chain, senders ignore the TLSA record. Check it with the DNSSEC Checker.
Where are TLSA records published for email?
Per MX host, at _25._tcp.<mx-host> — not on the domain. Publish one for every MX a sender might use, backups included, or an uncovered host reopens the gap.
What do the usage, selector and matching-type fields mean?
Usage = what you pin (2 = CA, 3 = leaf cert). Selector = full cert (0) or public key (1). Matching type = hash (1 = SHA-256). A typical SMTP record is 3 1 1.
Should I use DANE or MTA-STS?
Same threat, different anchors — DANE trusts DNSSEC, MTA-STS trusts the web PKI. If you run DNSSEC, DANE fits; otherwise MTA-STS is easier. Publishing both maximises coverage.