RFC 7672 — DANE for SMTP

RFC 7672 defines DANE for SMTP, the other way to stop STARTTLS being stripped. It publishes what certificate to expect in DNS, using TLSA records defined by RFC 6698, and relies on DNSSEC to make that publication trustworthy.

It solves the same problem as MTA-STS and makes a different trade.

DANE against MTA-STS

	DANE	MTA-STS
Trust anchor	DNSSEC	Web PKI (HTTPS certificate)
Prerequisite	Your zone must be DNSSEC-signed	You must host an HTTPS endpoint
Failure mode	Delivery fails closed	Cached policy until max_age expires
Downgrade resistance	Stronger — no fallback window	Weaker — depends on cache state

DANE is the more rigorous of the two. It has no equivalent of MTA-STS’s first-contact problem, where a sender that has never fetched your policy has nothing to enforce.

Its cost is the prerequisite. DNSSEC is a serious operational commitment, and a signing error takes your whole domain off the internet rather than merely breaking mail. That is why MTA-STS exists at all — it was designed for operators who wanted the guarantee without adopting DNSSEC.

Which to publish

They are not exclusive, and publishing both is reasonable and common: senders that support DANE use it, senders that support only MTA-STS use that.

If your zone is already DNSSEC-signed, DANE is the stronger choice and worth doing. If it is not, adopting DNSSEC solely to enforce SMTP TLS is a large commitment for the benefit — MTA-STS gets most of the way there with far less risk.

Either way publish TLS-RPT first, because it reports on both.

Checking whether a domain has it

A TLSA record lives under the port and protocol of the MX host:

dig +short TLSA _25._tcp.mail.example.com

If it returns records and the zone is DNSSEC-signed, DANE is in force. The DNSSEC part is not optional — a TLSA record in an unsigned zone can be forged as easily as the STARTTLS announcement it is meant to protect, so senders ignore it entirely.

Read it: rfc-editor.org/rfc/rfc7672