DANE (TLSA) for the mail servers

DANE for SMTP (RFC 7672) lets a domain publish, in DNS, which certificate its mail servers present. The record is a TLSA record at _25._tcp. followed by the MX hostname — _25._tcp.mail.example.com — and it lives in the zone of the MX host, which for a hosted mailbox is the provider's zone rather than yours. This check reads that record from the zone's own authoritative server, asks a validating resolver whether it is DNSSEC-secure, and compares it with the certificate the server presented when the SMTP probe negotiated STARTTLS.

A sender that enforces DANE — Postfix with DANE enabled, Exchange Online, and a large share of European providers — looks the record up before connecting. If the record validates, TLS to that host becomes mandatory and authenticated: the sender requires STARTTLS and requires the certificate to match. A mismatch is not a downgrade to plaintext, it is a refusal to deliver. The message is deferred and eventually bounces, which is why a mismatch is graded as a failure.

DNSSEC is not optional here. A sender only trusts a TLSA record that validates as secure (RFC 7672 §2.2), so a record in an unsigned zone — or in a signed zone with no chain of trust from the root, such as a missing DS at the registry — is silently ignored. That is graded as a warning: nothing bounces, but the record does nothing either. The check reports both what the authoritative server returned (whether a signature came with the answer) and whether a validating resolver accepted it.

Only two of the four certificate usages apply to SMTP. Usage 3 (DANE-EE) names the server's own certificate or public key; usage 2 (DANE-TA) names a trust anchor the server must include in the chain it sends. Usages 0 and 1 rely on public CAs, which SMTP has no agreed list of, so RFC 7672 §3.1.3 makes them unusable — a host whose records are all of that kind is treated as having no usable TLSA. Matching is by SHA-256 or SHA-512 digest of the whole certificate (selector 0) or of its public key (selector 1); the rarely used exact-match type 0 is compared through the SHA-256 of both sides.

The probe has to see a certificate before anything can be compared, and outbound port 25 is blocked on many networks, ours included at times. A record that could not be compared is reported as not measured, never as a failure.

If you publish TLSA, publish 3 1 1 — DANE-EE, public key, SHA-256. It pins the key rather than the certificate, so routine renewals that keep the key need no DNS change at all, and it does not depend on any CA.

Rotate keys in two steps. Publish a TLSA record for the new key alongside the old one, wait at least two TTLs, then switch the server to the new key, and only then remove the old record. A record set that always contains the key in use is the whole discipline; ACME clients that generate a fresh key on every renewal break it, so configure yours to reuse the key or to pre-generate the next one.

Make sure the zone holding the MX hostname is signed and its DS is published at the registry, then check it from outside with a validating resolver. A TLSA record in an unsigned zone is safe but useless.

If the MX belongs to a mail provider, the TLSA record, the zone and the certificate are all theirs. A failure here is theirs to fix — and worth reporting to them, because it is bouncing mail from every DANE sender.