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.
Errors
- TLSA records published, but the zone is not signedThis configuration provides no protection at all. DANE rests entirely on DNSSEC: an attacker who can substitute a certificate can also remove these records, and a sender that sees no TLSA record just carries on without DANE. Sign the zone, or use MTA-STS instead.
mail2.ietf.org
_25._tcp.mail2.ietf.org
| Usage | Selector | Matching | Association |
|---|---|---|---|
| 3 — DANE-EE (domain-issued certificate) | 1 — SubjectPublicKeyInfo | 1 — SHA-256 | b8da5ea1e9349576111409d702eca7aed53f635790ec82dba22cbeeab9f53fa6 |
Could not check the live certificate: STARTTLS was not offered or was refused. The records above are still shown as published.
HOW TO READ THIS
What each part is forDNSSEC 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.