--- title: "MTA-STS vs DANE: Verdict by Scenario (2026 Data)" description: "Only 0.3% of 5.5M domains publish MTA-STS; 0.0% publish DANE. Get the per-scenario verdict, RFC 8461 vs 7672, Microsoft's connector modes, and NIS2 fit." publishedAt: 2026-06-25 tags: ["mta-sts", "dane", "tlsa", "dnssec", "smtp", "tls-rpt", "nis2"] faq: - question: "What is the difference between DANE and MTA-STS?" answer: "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." - question: "Do I need both MTA-STS and DANE?" answer: "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." - question: "Is DANE more secure than MTA-STS?" answer: "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." - question: "Does MTA-STS require DNSSEC?" answer: "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." - question: "Which mail providers support DANE and MTA-STS?" answer: "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." - question: "What percentage of domains use MTA-STS vs DANE?" answer: "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." - question: "Does NIS2 require MTA-STS or DANE?" answer: "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." --- # 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](/blog/what-is-dane/) and a [working MTA-STS policy file example](/blog/mta-sts-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.` plus an HTTPS fetch of `/.well-known/mta-sts.txt`; DANE uses a TLSA record (DNS type 52) at the owner name `_25._tcp.`. - **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. | Dimension | MTA-STS (RFC 8461) | DANE (RFC 7672) | | ------------------------------- | ----------------------------------------------- | ----------------------------------------- | | Trust anchor | Web PKI (HTTPS) + unsigned TXT beacon | DNSSEC chain + TLSA pin | | Downgrade resistance | Soft on first contact (TOFU), hard on cache hit | Hard — DNSSEC-signed mandate | | Self-signed certs | No — must chain to a public CA | Yes (DANE-EE, usage 3) | | DNS-host requirement | Plain TXT only | TLSA (type 52) + DNSSEC + DS at registrar | | Web-host requirement | Public HTTPS endpoint serving policy file | None | | Authenticated non-existence | No (plain DNS) | Yes (DNSSEC NXDOMAIN) | | Adoption (DMARCguard, Feb 2026) | 0.3% (15,997 / 5.5M) | 0.0% (30 / 5.5M) | | Reporting layer | TLS-RPT (RFC 8460) | TLS-RPT (RFC 8460) | The threat model and history for each protocol live on their reference pages — [MTA-STS](/learn/mta-sts/) and [DANE](/learn/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. — a single org-domain record is a misconfiguration.", ], [ "4", "Microsoft 365 / Exchange Online", "Yes (host your own policy)", "Yes (inbound DANE GA Oct 2024, DNSSEC-signed *.mx.microsoft)", "Both — and set outbound -SmtpDaneMode/-MtaStsMode per connector (see the Microsoft section below).", ], [ "5", "Google Workspace", "Yes", "No", "MTA-STS only. Google honors and publishes MTA-STS but does not do DANE/DNSSEC; a TLSA buys nothing for Gmail-bound mail.", ], [ "6", "Self-hosted Postfix / Exim", "Yes (via add-on)", "Yes (native)", "Both, DANE-first. Postfix and Exim ship DANE natively; order resolvers so MTA-STS never overrides DANE (postfix-tlspol).", ], [ "7", "MSP managing 100+ domains", "Yes (uniform)", "Only on DNSSEC-ready zones", "MTA-STS as the baseline you ship everywhere; add DANE per-domain where the chain is intact. Standardize, don't hand-tune 100 zones.", ], [ "8", "Regulated under NIS2 / DORA / BSI TR-03108", "Yes", "Yes (effectively required in DE/NL)", "Both. BSI TR-03108 makes DANE mandatory and MTA-STS recommended; the Dutch comply-or-explain list mandates DANE. Document the plan either way.", ], ]} verdict="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 first." /> 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. | Provider | MTA-STS publish | MTA-STS honor | DANE publish/inbound | DANE honor/outbound | Notes | | ------------------------------- | ------------------------------------- | -------------------- | -------------------------------------------- | ----------------------------------- | -------------------------------------- | | Microsoft 365 / Exchange Online | Yes (you host the policy) | Yes | Yes (GA 2024-10-28, DNSSEC `*.mx.microsoft`) | Yes (since Mar 2022) | Per-connector outbound modes, Mar 2026 | | Google Workspace / Gmail | Yes | Yes (since Apr 2019) | No | No | Relies on MTA-STS exclusively | | Fastmail | Preference (no confirmed live policy) | — | No (no DNSSEC) | No | "availability over DANE," Dec 2025 | | Yahoo | Co-author of MTA-STS | — | Unverified (first-party) | — | MTA-STS camp | | Proton Mail | Yes (own domains) | — | Yes (TLSA) | — | Both on proton.me | | Mailbox.org | Yes | — | Yes (DNSSEC + DANE) | — | BSI gold status 2025 | | Postfix (MTA) | Add-on only | Add-on | n/a | Native (≥ 2.11) | TLS-RPT in 3.10+ | | Exim (MTA) | Add-on only | Add-on | n/a | Native (≥ 4.91, `SUPPORT_DANE=yes`) | Defers DNSSEC validation to resolver | 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." Write-ups that describe a single mode with values "DaneOnly", "MtaStsOnly", or "DaneOrMtaSts" are wrong. Exchange Online exposes two separate parameters — `-SmtpDaneMode` and `-MtaStsMode` — and MTA-STS has no Mandatory mode. This matches the framing in our [working MTA-STS policy file example](/blog/mta-sts-example/): there is no Mandatory MTA-STS mode. ## 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](/tools/bsi-nis2/) shows where your domain stands against the German baseline. For the NIS2-specific picture, see our [NIS2 email security requirements](/blog/nis2-email-security/) guide. {/* TODO: link /blog/dora-email-authentication/ here once it publishes 2026-06-29 (after this post's 2026-06-25 date) — convert to a live "DORA email authentication" link in a post-publish edit per seo-conventions. */} 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: Paste a domain into our [MTA-STS checker](/tools/mta-sts-checker/) to do both in one pass, or generate a ready-to-host policy file with our [MTA-STS policy generator](/tools/mta-sts-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): Our [DANE checker](/tools/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: 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](/learn/tls-rpt/) 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](/research/email-authentication/) 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](/learn/tls-rpt/) is the reporting layer that turns a silent bounce into an actionable report.