ReaperCloud

DANE / TLSA

DANE pins your mail server's certificate in DNS, so a sender can tell the real host from a substituted one. It rests entirely on DNSSEC — without a signed zone, a TLSA record protects nothing at all.

Mail hosts 1
TLSA records 2
DNSSEC NOT signed
Certificate matches 1 of 1

Errors

Looking good

mx.ietf.org

_25._tcp.mx.ietf.org

UsageSelectorMatchingAssociation
3 — DANE-EE (domain-issued certificate) 1 — SubjectPublicKeyInfo 1 — SHA-256 e3008a5c0bc1e088455ec997da389d31d2b379f76727bcb6594316f6058e6190
3 — DANE-EE (domain-issued certificate) 1 — SubjectPublicKeyInfo 1 — SHA-256 292481eee04f9f5ce0dc1728488dee2510053af6d62f4e7cdef8c82d811a5ae9

The certificate served on port 25 matches one of these records.

HOW TO READ THIS

What each part is for

DNSSEC is not optional

DANE's whole guarantee is that the TLSA record cannot be tampered with in transit. In an unsigned zone, an attacker who can substitute your certificate can equally delete the record that would have caught them — and a sender that finds no record simply proceeds without DANE. A TLSA record without DNSSEC is decoration.

Usage 2 and 3 only

RFC 7672 requires mail servers to ignore usages 0 and 1. They depend on Web PKI validation of a hostname the sender reached by MX lookup rather than by URL, which it cannot check. Publishing one has no effect.

Selector 1 survives renewal

Selector 0 pins the certificate, so every renewal breaks it. Selector 1 pins the public key, so a renewal that reuses the key needs no DNS change. That difference is the most common cause of DANE outages.

DANE or MTA-STS

Both stop STARTTLS being stripped. DANE needs DNSSEC and is checked per host; MTA-STS needs an HTTPS endpoint and is published per domain. Running both is fine and reasonably common — a sender uses whichever it supports.