DANE or MTA-STS: Which One Should a SaaS Vendor Deploy First?

Both DANE and MTA-STS exist to stop the same attack: an on-path adversary stripping STARTTLS from an SMTP session so mail to your domain arrives in clear text.

They differ in what they trust to prove the policy is genuine, and that single difference decides which one you can deploy this week.

The trust anchor is the whole distinction

DANE publishes a TLSA record in DNS that pins the certificate your mail server will present. The record is authenticated by DNSSEC. Nothing about the certificate authority system is involved, so a CA that mis-issues a certificate for your domain cannot be used to intercept your mail.

MTA-STS publishes a policy file over HTTPS at a well-known URL on an mta-sts. subdomain. The policy is authenticated by the certificate on that subdomain, which means the CA system is the root of trust.

Cryptographically, DANE is stronger. Operationally, MTA-STS is deployable on any domain today, because it needs no DNSSEC.

The comparison that actually drives the decision

	DANE	MTA-STS
Trust anchor	DNSSEC	Certificate authority
Prerequisite	Signed zone	HTTPS host for a subdomain
Deployable today without a project	Only if DNSSEC is already on	Yes
Resists CA mis-issuance	Yes	No
Resists DNS tampering without DNSSEC	Yes	Yes, policy is CA-authenticated
Sender support	Widely implemented, notably in European providers	Widely implemented, notably at the large mailbox providers

The last row is why the honest answer is “both”. Senders that support both prefer DANE and fall back to MTA-STS when DNSSEC validation is unavailable. They cover partially overlapping populations of sending servers, so deploying one leaves a gap the other would have closed.

BSI TR-03108 expects both, and that is the reasoning behind it rather than belt-and-braces caution.

Why the order is MTA-STS first

For a SaaS vendor without DNSSEC on the zone, the sequencing is not really a choice.

Enabling DNSSEC is a genuine project. It touches registrar configuration, key management, rollover procedure, and it has a failure mode where a botched rollover makes your entire domain unresolvable, not just your mail. It is worth doing. It is not worth doing on the same afternoon you discovered you have no transport security.

MTA-STS plus TLS-RPT is two DNS records and one static file, with a testing mode that makes the rollout observable before it becomes enforcing. You can have it live, in testing, before lunch, and enforcing three weeks later once the reports are clean.

So: MTA-STS and TLS-RPT now, DNSSEC and DANE as a scheduled project.

The single exception is a domain that already has DNSSEC. Then add the TLSA records at the same time, because the marginal cost is an hour.

The mistake to avoid on both

For MTA-STS, the mistake is staying in mode: testing. Testing reports failures and delivers anyway, so a domain parked there has the appearance of the control and none of the protection. Put a calendar entry on the switch to enforce when you deploy, not later.

For DANE, the mistake is a TLSA record that does not match the certificate actually served after a renewal. With certificate lifetimes dropping toward 47 days, that risk compounds: every renewal is an opportunity for the pin to go stale, and a stale TLSA record does not degrade gracefully, it blocks mail.

Pin to the CA public key rather than the leaf certificate (TLSA usage 2 or 3 selector 1), and automate the record update alongside renewal. A DANE deployment without automated TLSA maintenance will break, and the step down in certificate lifetimes decides when.

What TLS-RPT does for both

Whichever you deploy, TLS-RPT is what tells you it is working.

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Daily JSON from sending providers, listing successful and failed negotiations with the failure reason. It catches the stale TLSA record, the MX host missing from the MTA-STS policy, and the expired certificate on the secondary mail server that nobody has looked at in two years.

Deploy TLS-RPT before either policy mechanism, so the first report you read is a baseline rather than an incident.

Where it maps

• NIS2 Article 21(2)(h) cryptography, 21(2)(e) network security.
• ISO/IEC 27001:2022 A.8.24 and A.5.14 information transfer.
• DORA Article 9 for financial entities.
• BSI TR-03108 in a German supervisory context.

The short version

DANE is stronger, MTA-STS is available now, and the two cover different senders, so the destination is both.

Start with TLS-RPT for visibility, then MTA-STS in testing, then enforce. Schedule DNSSEC and DANE as the follow-on project rather than as a blocker for doing anything at all.