Why is DNSSEC mandatory for DANE?

A TLSA record without DNSSEC can be forged in transit; an attacker could remove or replace it and thereby defeat the protection. Only a DNSSEC-validated TLSA record is trustworthy, which is why the AD flag of the response is checked.

What do the three numbers in a TLSA record mean?

Usage (for SMTP only 2 = DANE-TA, own CA, or 3 = DANE-EE, server directly), Selector (0 = whole certificate, 1 = public key only) and Matching-Type (0 = full value, 1 = SHA-256, 2 = SHA-512).

How do I create a TLSA record for SMTP?

The common form is 3 1 1: Usage 3, Selector 1 (public key), Matching-Type 1 (SHA-256). Take the SHA-256 hash of the SubjectPublicKeyInfo from the server certificate and publish it as a record under _25._tcp. with a TTL. The zone must be DNSSEC-signed.

How do I rotate the certificate without a delivery outage?

Before the switch, publish the TLSA record of the new key in addition, so the old and the new record apply in parallel. After the switch and once the TTL has expired, remove the old record. With Selector 1 and an unchanged key this is not needed at all.

Why is DANE not part of the Domain Check?

DANE is still not widely deployed and requires DNSSEC. In the combined check it would only report 'not set up' for most domains. Anyone who uses it checks it specifically here.

MTA-STS or DANE, which should I use?

Both enforce TLS for incoming mail. DANE is stronger (bound to DNS instead of the Web PKI) but requires DNSSEC in your own zone. MTA-STS works without DNSSEC but needs an HTTPS endpoint. Publishing both covers both sender types.

DANE Check

Check the TLSA records of the MX hosts: DNSSEC, Usage/Selector/Matching, coverage.

DANE binds the TLS certificate of a domain's mail servers directly to DNS through TLSA records. For SMTP they sit under _25._tcp.<mx-host> and state which key or certificate the target server must present. A sending server that supports DANE then accepts no unencrypted and no wrongly certified connection any more, without needing an external certification authority. The trust anchor is DNSSEC.

What this tool checks

For every MX host of the domain it queries the TLSA records under _25._tcp.<mx-host> and evaluates the AD flag of the response, that is whether the zone is DNSSEC-validated. It checks the three fields of each record per RFC 7672: Usage (for SMTP only 2 or 3), Selector and Matching-Type with the byte count that matches the hash length. It also checks whether all MX hosts are covered; only partial coverage is a downgrade gap. If the upstream resolver returns no AD (old resolvers, DNS interception on the local network), the tool reports the DNSSEC status as not confirmed and checks only the syntax, instead of wrongly claiming security.

Reading the result

Green means: every MX host has at least one syntactically valid TLSA record, the zone is DNSSEC-validated and all MX hosts are covered. Warnings appear for partial coverage, for Usage 0 or 1 (not allowed for SMTP) and when the DNSSEC status could not be confirmed. No TLSA record is not an error but the note that DANE is not set up for this domain. The actual comparison of whether the certificate presented in the SMTP handshake matches the TLSA hash requires an SMTP connection and is not part of this DNS check.

Background

DANE and the TLSA record are defined in RFC 6698, the operational use in RFC 7671, the SMTP-specific rules (only Usage 2 and 3, DNSSEC mandatory, handling of multiple MX) in RFC 7672. DNSSEC itself is described in RFC 4033 to 4035. Without DNSSEC a TLSA record is worthless, because an attacker could remove or replace it in transit; the validated AD flag is therefore the prerequisite, not merely a recommendation.

Common problems and how to fix them

TLSA record present, but zone without DNSSEC. DANE then does not take effect. First enable DNSSEC for the zone of the MX host and put the DS records at the registrar, then publish the TLSA records.
Only some of the MX hosts have TLSA records. A sending server then falls back to the unprotected MX. Set a matching TLSA record for every MX host name.
Certificate renewed, TLSA not. With Usage 3 and Matching-Type SHA-256 the hash changes with every new key. Before the switch, publish the new TLSA record in addition (both in parallel), switch over, then remove the old one. Anyone who pins the key instead of the certificate (Selector 1) and keeps the key has to touch nothing.
Usage 0 or 1 in the record. These PKIX-bound modes are not allowed for SMTP (RFC 7672). Switch to Usage 3 (server's certificate or key directly, DANE-EE) or Usage 2 (own CA, DANE-TA).
Wrong byte length for the Matching-Type. Matching-Type 1 requires exactly 32 bytes (SHA-256), Type 2 exactly 64 bytes (SHA-512). A truncated hash or one wrapped with spaces makes the record invalid.

Common questions

Why is DNSSEC mandatory for DANE?: A TLSA record without DNSSEC can be forged in transit; an attacker could remove or replace it and thereby defeat the protection. Only a DNSSEC-validated TLSA record is trustworthy, which is why the AD flag of the response is checked.
What do the three numbers in a TLSA record mean?: Usage (for SMTP only 2 = DANE-TA, own CA, or 3 = DANE-EE, server directly), Selector (0 = whole certificate, 1 = public key only) and Matching-Type (0 = full value, 1 = SHA-256, 2 = SHA-512).
How do I create a TLSA record for SMTP?: The common form is 3 1 1: Usage 3, Selector 1 (public key), Matching-Type 1 (SHA-256). Take the SHA-256 hash of the SubjectPublicKeyInfo from the server certificate and publish it as a record under _25._tcp.<mx-host> with a TTL. The zone must be DNSSEC-signed.
How do I rotate the certificate without a delivery outage?: Before the switch, publish the TLSA record of the new key in addition, so the old and the new record apply in parallel. After the switch and once the TTL has expired, remove the old record. With Selector 1 and an unchanged key this is not needed at all.
Why is DANE not part of the Domain Check?: DANE is still not widely deployed and requires DNSSEC. In the combined check it would only report 'not set up' for most domains. Anyone who uses it checks it specifically here.
MTA-STS or DANE, which should I use?: Both enforce TLS for incoming mail. DANE is stronger (bound to DNS instead of the Web PKI) but requires DNSSEC in your own zone. MTA-STS works without DNSSEC but needs an HTTPS endpoint. Publishing both covers both sender types.