MTA-STS vs DANE: Which SMTP Encryption Standard to Publish (2026 Scan: MTA-STS Leads DANE 533×)

MTA-STS and DANE both force SMTP to use TLS or refuse delivery — but only one is deployable on almost any domain today. The whole MTA-STS vs DANE decision turns on a single variable. Across 5,499,028 domains we scanned in February 2026, 15,997 publish an MTA-STS policy (0.3%) and 30 publish a DANE TLSA record (0.0%). MTA-STS leads DANE by 533×. That single variable is whether your DNS chain supports DNSSEC: DANE needs it, MTA-STS does not — and if your chain can’t, MTA-STS alone is the complete answer.

So when people ask DANE vs MTA-STS, they are usually asking the wrong question. The honest framing is one trade-off: DANE is cryptographically stronger because it roots trust in DNSSEC; MTA-STS is deployable today because it does not need DNSSEC at all. This post gives you the explicit verdict by scenario, the trust-model contrast sourced to the protocol authors, the comprehensive DANE protocol guide and a working MTA-STS policy file example for each side, and the corrected Microsoft connector-mode mapping — for M365 and Google Workspace admins reacting to Microsoft’s March 2026 announcement, Postfix and Exim operators, and anyone weighing NIS2 or BSI obligations.

What’s the Difference Between DANE and MTA-STS?

The difference is where each protocol roots trust. DANE — DNS-Based Authentication of Named Entities for SMTP, RFC 7672, built on the TLSA record of RFC 6698 — pins the receiver’s TLS certificate in a DNSSEC-signed TLSA record. MTA-STS — Mail Transfer Agent Strict Transport Security, RFC 8461 — publishes an HTTPS-hosted policy file discovered via an unsigned DNS TXT record and trusts the Web PKI.

The protocol authors state the split plainly. The original MTA-STS draft (Brotman et al.) puts it from their own side: “DANE requires the use of DNSSEC to authenticate DANE TLSA records, whereas SMTP STS relies on the certificate authority (CA) system to avoid interception.” That single sentence is the entire mechanical contrast — everything else is a consequence of it.

In practice the two protocols differ on five axes that matter to an operator:

• Discovery. MTA-STS uses a plain TXT beacon at _mta-sts.<domain> plus an HTTPS fetch of /.well-known/mta-sts.txt; DANE uses a TLSA record (DNS type 52) at the owner name _25._tcp.<mx-host>.
• Modes. MTA-STS has three: none, testing, enforce (RFC 8461 §5). DANE has no modes — a valid, DNSSEC-signed TLSA is mandatory the moment it exists.
• Certificate usage. DANE distinguishes certificate usage 2 (DANE-TA, a trust anchor) from 3 (DANE-EE, the end-entity key), and DANE-EE accepts self-signed certificates (RFC 7672 §3.1). MTA-STS requires a certificate that chains to a public CA.
• Authenticated non-existence. DANE inherits DNSSEC’s signed NXDOMAIN, so the absence of a record is itself authenticated; MTA-STS cannot prove non-existence over plain DNS.
• Downgrade resistance. DANE’s signed records defeat STARTTLS-stripping (RFC 3207) outright; MTA-STS is soft on first contact under trust-on-first-use (TOFU) and hard only once a policy is cached.

When we built our DANE and MTA-STS checkers, this last point — TOFU versus a signed mandate — was the one operators most often misread. Both protocols were designed to coexist; the Dutch Internet Standards Platform notes they “intentionally do not interfere.” TLS-RPT (RFC 8460) reports failures for both.

The threat model and history for each protocol live on their reference pages — MTA-STS and DANE; this post is the comparison and the verdict.

Which Is Better, MTA-STS or DANE?

On cryptographic strength, DANE is better — named authorities (Wes Hardaker and Viktor Dukhovni of USC/ISI, the .nl registry SIDN, the Dutch Internet Standards Platform, and Germany’s BSI) rate it stronger because it authenticates TLS support via DNSSEC and closes the TOFU gap MTA-STS accepts. On deployability, MTA-STS wins decisively — it needs no DNSSEC, which is why 533× more domains run it.

The TOFU critique is institutional consensus, not partisan opinion. The Dutch Internet Standards Platform calls MTA-STS “less secure than DANE due to trust on first use and caching,” and RFC 8461 §10 itself concedes that DANE offers better downgrade resistance. Wes Hardaker, co-author of RFC 7672, is blunter: “MTA-STS… is useful only for domains that are for some reason unable to deploy DNSSEC” (USC/ISI, 2021-09-20). That is a 2021 statement, and the date matters — but the structural point it makes has not changed.

What has changed is the empirical counterweight. Theoretical strength is not deployment reality. Our scan puts DANE at 0.0% — 30 domains out of 5.5 million. Regardless of which protocol is stronger on paper, DANE is unusable for the overwhelming majority of operators today, and a protocol that protects no traffic protects nothing.

Both camps have a stake worth disclosing. The pro-DANE camp is concentrated in DNSSEC-invested institutions — SIDN runs the world’s largest DANE-for-mail TLD; Hardaker and Dukhovni are long-standing DANE/DNSSEC authors. MTA-STS was authored by the cloud-provider bloc — Google, Oath/Yahoo, Comcast, and Microsoft — precisely because DNSSEC stalled, and RFC 8461 §1 says so outright: MTA-STS exists “even when deploying DNSSEC is undesirable or impractical.” Neither side is neutral; both are correct about their own half of the trade-off.

Do I Need Both MTA-STS and DANE? The Verdict by Scenario

Most operators do not need both. The honest answer is keyed to one variable — whether your registrar-and-DNS chain can fully support DNSSEC today. If it cannot, MTA-STS alone is the correct, complete deployment. If it can, publish both. Here is the verdict for eight common scenarios, each a complete SMTP transport-encryption decision.

The decision rule, stated plainly: DNSSEC already on your zone and registrar → both. No DNSSEC, or a registrar or host that makes it painful → MTA-STS only. Always pair either choice with TLS-RPT and roll out in testing (for MTA-STS) or Opportunistic (for SMTP DANE on Exchange Online) first, so failures surface as reports rather than bounces. That covers every realistic MTA-STS-or-DANE stack.

Why DANE Adoption Is Near Zero — the DNSSEC Barrier

DANE sits at 0.0% because it depends on a three-link chain that breaks for most domains: sign the zone, publish a DS record at the registrar, and add a TLSA record at the DNS host. MTA-STS was designed to require none of this.

That dependency is hard and one-directional — DANE requires DNSSEC (RFC 6698 §4.1; RFC 7672), and a break in any one of the three links makes DANE unusable. DNSSEC signing, in turn, is concentrated in a few incentivized ccTLDs and nearly absent from the giant gTLDs. SIDN reports 62% of .nl domains are signed; .se, .cz, and .no all exceed 50%, driven by registrar fee-incentive schemes. By contrast, Verisign reported .com at 4.2% signed and .net at 5.1% (2023 figures — flagged as older than two years). That skew is the direct mechanical cause of DANE’s geographic concentration in the Netherlands and Germany.

Some of the most load-bearing broken links were only recently repaired. AWS Route 53 signed zones since December 2020 but added TLSA support only in October 2024; DNSimple added TLSA in January 2026. Residual breakage clusters at consumer registrars — IONOS requires an emailed request to publish a DS record for external nameservers, Namecheap carries TLD gaps, and some registrars still lag on Algorithm 13. As Frederic Cambus, maintainer of the StatDNS portal, frames the stall: the near-absence of DNSSEC in .com/.net is “partly the complexity of DNSSEC and partly the absence of any direct benefit.”

The macro picture confirms it. APNIC measured DNSSEC validation at 36% and secure-delegation (signing) at 7% for 2025 — meaning even where resolvers check signatures, most zones are not signed to begin with. A domain whose zone is unsigned cannot use DANE at all — MTA-STS is the only transport-security standard that still reaches it.

Which Mail Providers Support DANE and MTA-STS?

Microsoft 365 is the only major mailbox provider that supports both DANE and MTA-STS in both directions. Google, Yahoo, and Fastmail deliberately favor MTA-STS and do not do DANE; Proton Mail and Mailbox.org publish both. Postfix and Exim ship DANE natively but need an add-on for MTA-STS.

The publish-versus-honor distinction matters here, because providers differ on each. “Publish” means acting as a receiver; “honor” means acting as a sender.

The landscape splits into two camps with stated reasons. The DANE camp — Microsoft, Proton Mail, Mailbox.org — invests in DNSSEC; mailbox.org was awarded BSI gold status in 2025 for full DNSSEC implementation. The MTA-STS camp — Google, Yahoo, Fastmail — chose availability over confidentiality. Fastmail’s December 2025 post is the clearest articulation: “we don’t currently consider the confidentiality benefits of DANE over MTA-STS to be worth the trade-off against increased availability risk. Other major providers such as Google and Yahoo have made similar choices.” Treat the rows marked “unverified (first-party)” — Yahoo’s DANE status in particular — as third-party-sourced, not provider-confirmed.

How to Choose Your Microsoft 365 Outbound Connector Mode (Mar 2026)

Microsoft’s March 10, 2026 announcement shipped two independent per-connector PowerShell parameters, not one selector — and the exact casing is the part most write-ups get wrong:

• -SmtpDaneMode: Opportunistic (default) / Mandatory (SMTP DANE only — mail is queued and then NDR’d on validation failure) / None.
• -MtaStsMode: Opportunistic (default) / None. There is no Mandatory mode for MTA-STS — only SMTP DANE supports Mandatory.

Both are configured per outbound connector on New/Set/Get-OutboundConnector, outbound only — not tenant-wide and not inbound. Microsoft’s stated reason for splitting enforcement this way: “customers have told us that one-size-fits-all enforcement can be challenging when sending mail to partners with inconsistent or misconfigured implementations.”

Is MTA-STS or DANE Required for NIS2, DORA, or BSI Compliance?

No EU instrument names MTA-STS or DANE literally. But NIS2 Article 21’s “state-of-the-art” encryption-in-transit duty — now in force as Member States transpose it, with Germany’s NIS2 law effective 6 December 2025 (transposition deadline 17 October 2024) — is operationalized by national bodies as DANE-first. Germany’s BSI TR-03108 makes DANE mandatory and MTA-STS only a recommendation; the Dutch comply-or-explain list mandates DANE.

BSI TR-03108 v2.0 is explicit: DANE “provides effective and scalable protection against this threat and is therefore mandatory for compliance with this BSI TR.” MTA-STS was added in the newest version as an alternative, but “it offers a lower level of protection than DANE… For this reason, MTA-STS is only included in the guideline as a recommendation.” On the Dutch side, the national standards process places DANE — not MTA-STS — on the comply-or-explain list.

A note on honesty about scope: NIS2 itself frames the obligation as strong transport security, not a named-protocol mandate. There is no NIS2 “email deadline” tied to a specific protocol. The DANE-first reading comes from national operationalization (BSI, the Dutch standards forum), and DORA’s ICT-risk articles (overseen by national authorities such as Germany’s BaFin) follow the same pattern — the regulation sets the duty; the national standard names the mechanism. Document a deployment plan against whichever standard applies to your sector — our BSI TR-03108 and NIS2 readiness check shows where your domain stands against the German baseline. For the NIS2-specific picture, see our NIS2 email security requirements guide.

For regulated senders, DANE email security is therefore the higher bar — but only the registrar-and-DNS chain decides whether you can clear it.

How to Validate and Deploy Your TLS-Transport Stack

Validate before you enforce. Confirm the MTA-STS TXT plus HTTPS policy fetch, and the DNSSEC-signed TLSA match, then turn on TLS-RPT so failures arrive as JSON reports instead of silent bounces.

How to Validate Your MTA-STS Deployment

Two commands confirm both halves of the protocol — the TXT beacon and the HTTPS-served policy file — and verify they agree:

# 1. Confirm the MTA-STS beacon TXT resolves (RFC 8461 §3.1)
dig +short TXT _mta-sts.example.com
#   → "v=STSv1; id=20260625120000Z;"

# 2. Confirm the policy file fetches over HTTPS with a valid certificate
curl -sS https://mta-sts.example.com/.well-known/mta-sts.txt
#   → version: STSv1
#     mode: enforce
#     mx: *.mail.protection.outlook.com
#     max_age: 604800

Paste a domain into our MTA-STS checker to do both in one pass, or generate a ready-to-host policy file with our MTA-STS policy generator.

How to Validate Your TLSA Record

The one rule that catches operators: an unsigned TLSA is worthless. Confirm the RRset carries an RRSIG, because conforming MTAs ignore any TLSA that DNSSEC did not authenticate (RFC 7672 §2):

# Confirm the TLSA RRset is DNSSEC-authenticated (RFC 7672 §2)
dig +dnssec _25._tcp.mx01.example.com TLSA

# The answer MUST carry an RRSIG line. An unsigned TLSA buys you
# nothing — conforming MTAs ignore any TLSA that DNSSEC did not
# authenticate. No RRSIG → no DANE.
#
#   _25._tcp.mx01.example.com. 3600 IN TLSA 3 1 1 2CD895DC...
#   _25._tcp.mx01.example.com. 3600 IN RRSIG TLSA 13 5 3600 ...

Our DANE checker does the full DNSSEC walk and TLSA match for you.

How to Avoid MTA-STS Overriding DANE in Postfix

If you publish both, watch the documented downgrade footgun: a resolved MTA-STS policy can override DANE inside postfix-mta-sts-resolver. The fix is to list a dane-only resolver first, or use postfix-tlspol, which prioritizes DANE per RFC 8461 §2:

# /etc/postfix/main.cf — keep MTA-STS from silently overriding DANE.
# Resolver order is the precedence rule (RFC 8461 §2): list the DANE
# policy resolver (responding `dane-only`) BEFORE the MTA-STS
# socketmap, or switch to postfix-tlspol, which prioritizes DANE.
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_policy_maps =
    socketmap:unix:/run/dane-policy/dane-policy.sock:dane
    socketmap:inet:127.0.0.1:8461:postfix

Whichever protocols you run, TLS-RPT (RFC 8460) closes the loop — it reports failures for both DANE and MTA-STS. See our TLS-RPT setup guide to wire up the reporting channel before you enforce anything.

FAQ

What is the difference between DANE and MTA-STS?

DANE pins the receiver’s certificate in a DNSSEC-signed TLSA record (RFC 7672); MTA-STS publishes an HTTPS policy file discovered via an unsigned TXT record and trusts the Web PKI (RFC 8461). DANE is cryptographically stronger; MTA-STS deploys on any domain with HTTPS, which is why far more domains run it.

Do I need both MTA-STS and DANE?

Only if your registrar-and-DNS chain supports DNSSEC. If it does, publish both — DANE carries traffic when your MTA-STS cert fails to renew, MTA-STS reaches DANE-blind senders like Gmail. If your zone is unsigned, MTA-STS alone is the correct, complete deployment; do not publish a TLSA you cannot anchor.

Is DANE more secure than MTA-STS?

Yes, on paper. Named authorities (USC/ISI, SIDN, Germany’s BSI) rate DANE stronger because it authenticates TLS via DNSSEC and avoids the trust-on-first-use gap MTA-STS accepts — conceded in RFC 8461 §10. In practice, DANE’s near-zero adoption means MTA-STS protects more real traffic today.

Does MTA-STS require DNSSEC?

No. MTA-STS was designed specifically to avoid DNSSEC — that is its core reason for existing (RFC 8461 §1). It discovers its policy over plain DNS plus HTTPS, which is why it deploys on virtually any domain. DANE is the protocol that mandates DNSSEC.

Which mail providers support DANE and MTA-STS?

Microsoft 365 supports both. Google Workspace and Yahoo support MTA-STS but not DANE; Fastmail states a preference for MTA-STS over DANE but has no confirmed live policy. Proton Mail and Mailbox.org publish both. Postfix and Exim ship DANE natively but need an add-on (postfix-tlspol) for MTA-STS. Provider stance changes; verify with a live check.

What percentage of domains use MTA-STS vs DANE?

In DMARCguard’s February 2026 scan of 5,499,028 domains, 15,997 published an MTA-STS policy (0.3%) and 30 published a DANE TLSA record (0.0%). MTA-STS leads DANE by 533×. See our 2026 email authentication adoption study for methodology.

Does NIS2 require MTA-STS or DANE?

Neither is named in NIS2. Article 21’s state-of-the-art encryption-in-transit duty is operationalized nationally as DANE-first: Germany’s BSI TR-03108 makes DANE mandatory and MTA-STS a recommendation; the Dutch comply-or-explain list mandates DANE. Document a deployment plan against the standard that applies to you.

Conclusion

MTA-STS vs DANE comes down to one trade-off and one fact. The trade-off: DANE is cryptographically stronger, MTA-STS is deployable today. The fact: across 5.5 million domains, MTA-STS leads DANE 533× because DNSSEC remains out of reach for most. From there the verdict is mechanical:

• No DNSSEC on your chain → MTA-STS only. It is the correct, complete deployment, not a consolation prize.
• DNSSEC intact → both. DANE adds hard downgrade resistance; MTA-STS reaches DANE-blind senders like Gmail.
• Microsoft 365 → set -SmtpDaneMode and -MtaStsMode per connector — two parameters, and no Mandatory mode for MTA-STS.
• Pair either with TLS-RPT. It is how you see failures before your users do.

Whichever side of the verdict you land on, TLS-RPT setup is the reporting layer that turns a silent bounce into an actionable report.