DANE, or DNS-based Authentication of Named Entities, lets a domain publish the expected TLS certificate or public key for its mail servers in DNS, with the answers signed by DNSSEC. It is an alternative route to the same goal as MTA-STS: making it hard to downgrade or intercept server-to-server mail. This article explains how SMTP DANE works, what it requires, and where it sits compared with MTA-STS.
The idea
MTA-STS relies on the public certificate authority system. DANE instead relies on DNS, and in particular on DNSSEC, which signs DNS answers so that they can be verified back to the root. A TLSA record states what the certificate or its public key should be. A sender that validates DNSSEC and finds a matching TLSA record can check the server's certificate against it, without depending on which CA issued it.
For SMTP, the relevant specification is RFC 7672, which defines how TLSA records are used for MX hosts.
Publishing a TLSA record
TLSA records live at a name built from the port, the protocol, and the host. For SMTP on the MX host mx1.example.com, the name is:
_25._tcp.mx1.example.com. IN TLSA 3 1 1 <64 hex characters>The three numbers mean: certificate usage 3 (DANE-EE, the end-entity certificate is matched directly), selector 1 (match the public key rather than the whole certificate), and matching type 1 (SHA-256 of the selected data). Usage 3 with selector 1 is a common choice for SMTP, because the record survives certificate renewal as long as the key is reused.
To generate the hash from an existing certificate:
$ openssl x509 -in mx1.pem -noout -pubkey \
| openssl pkey -pubin -outform DER \
| openssl dgst -sha256 -hexThe output begins with a label such as (stdin)=. Copy only the hex digits into the record. Check the output format of your version of OpenSSL before you paste it.
What the sender checks
A DANE-validating sender first confirms that the MX lookup and the TLSA lookup were DNSSEC-authenticated. If the zone is signed and validation succeeds, the sender connects with STARTTLS and compares the certificate it receives with the TLSA data. A match means the connection is accepted. A mismatch means the sender should not deliver to that host.
If DNSSEC validation fails, the sender must not treat the TLSA data as authentic. Depending on how it was obtained, the data may cause the connection to be refused or be ignored. This is the critical point: DANE is only as strong as the DNSSEC chain beneath it.
The DNSSEC dependency
DANE needs three things to work correctly:
- The domain's zone must be DNSSEC-signed, with a valid chain of trust from the root and a DS record published at the parent.
- The MX host's name must sit within a signed zone, and its TLSA record must be signed.
- Your key rollover process must keep TLSA records current. Replacing a key without updating the TLSA record makes the host unreachable to DANE-validating senders.
Check the chain with a validating resolver. A successful validation sets the ad flag in the response header, which you can see without +short:
$ dig +dnssec TLSA _25._tcp.mx1.example.comA DNSSEC failure is worse than a missing record, because it turns a working zone into one that validating resolvers cannot resolve. Make DNSSEC changes carefully, and plan the DS record update with your registrar before you enable signing.
An honest assessment
DANE is the more precise design. It does not depend on the CA system or on a separate HTTPS policy host, and it can pin a specific key. It is also more fragile. Its benefit depends on the sending side validating DNSSEC, and support among senders is uneven. A domain that publishes DANE still receives mail from senders that ignore it. For many domains, MTA-STS is the simpler and more widely understood choice. It fails more forgivingly, and it reports problems through TLS-RPT.
The two are not mutually exclusive. Publishing both covers more senders, provided each is set up correctly and kept in step with certificate changes. The cost is more moving parts. If you add DANE, you must also maintain DNSSEC and automate TLSA updates whenever certificates or keys change.
Recommendation
For most small domains, start with MTA-STS and TLS-RPT, which are covered in MTA-STS and TLS-RPT explained. Consider DANE once DNSSEC already runs reliably for your zone and you have a process for key rollover. The MTA-STS setup for hosted domains is described in the MTA-STS documentation. If you have questions about your domain, contact support.