Both MTA-STS and DANE solve the same problem: SMTP between mail servers starts in plaintext, and STARTTLS can be stripped by an attacker sitting in the path. Each standard tells a sending server "encrypt to me, verify my certificate, and refuse to fall back to cleartext." The difference is what they trust to prove the certificate is genuine. MTA-STS leans on HTTPS and the public certificate authority system. DANE leans on DNSSEC and a hash pinned in DNS. For most domains in 2026 the honest answer is to publish MTA-STS now because the large mailbox providers honor it, and add DANE where your DNS host and receivers support it.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
The problem both standards fix
When one mail server delivers to another, it looks up the recipient's MX records, connects on port 25, and issues STARTTLS to upgrade the session to TLS. That upgrade is opportunistic by default. If a network attacker rewrites the STARTTLS response, the sending server silently delivers in plaintext, and by design SMTP does not warn anyone. This is a downgrade attack, and it defeats the point of TLS.
Opportunistic TLS also does not usually verify the certificate. A sending server will often accept an expired, self-signed, or wrong-name certificate because rejecting mail over a certificate problem historically caused more harm than the attack it prevented. So the two gaps are the same in both cases: no guarantee TLS is used, and no guarantee the certificate belongs to the real recipient.
MTA-STS (RFC 8461) and DANE for SMTP (RFC 7672, built on RFC 6698) both close these gaps. They differ only in how a sender learns the policy and how it authenticates the certificate.
How MTA-STS works
MTA-STS publishes a policy that a sending server fetches over HTTPS. You add a TXT record at _mta-sts.example.com and host a policy file at a fixed HTTPS URL on a mta-sts. subdomain.
The DNS record looks like this:
_mta-sts.example.com. IN TXT "v=STSv1; id=20260703T120000"
The policy file lives at https://mta-sts.example.com/.well-known/mta-sts.txt and reads roughly like this:
version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.com
max_age: 604800
A sending server that supports MTA-STS fetches this file over HTTPS, checks the certificate against the public CA system exactly like a browser does, and caches the policy for max_age seconds. In enforce mode the sender then requires TLS to a matching MX host with a valid, name-matching certificate. If it cannot get that, it does not deliver. You move through mode: none and mode: testing first so you can watch for breakage before you turn on enforcement. The full rollout is covered in how to set up MTA-STS.
The trust-on-first-use weakness
MTA-STS has one structural gap: trust on first use, or TOFU. The very first time a sender contacts your domain, it has no cached policy. An attacker who can block the HTTPS fetch to your mta-sts. host, or block the TXT lookup, can make the sender behave as if you have no policy at all and fall back to plaintext. The same is true after a cached policy expires. MTA-STS narrows the attack window dramatically compared with plain opportunistic TLS, but it does not remove it, because the policy itself is only as trustworthy as an unauthenticated DNS lookup plus a reachable web server.
How DANE works
DANE takes a different route. It does not use HTTPS or public certificate authorities at all. Instead it publishes a TLSA record in DNS that contains a hash of the mail server's certificate or public key, and it requires that DNS zone to be signed with DNSSEC.
A TLSA record for an SMTP host looks like this:
_25._tcp.mail.example.com. IN TLSA 3 1 1 0b87ea...
The three numbers are the usage, selector, and matching type. Usage 3 means "this exact certificate or key," selector 1 means the record covers the public key, and matching type 1 means SHA-256. A sending server that supports DANE looks up the MX host, requests its TLSA record, verifies the DNSSEC signature chain, and then requires that the presented certificate match the pinned hash.
Because DNSSEC cryptographically signs the whole lookup, DANE has no trust-on-first-use window. There is no "first contact" an attacker can exploit, because a forged or stripped TLSA answer fails DNSSEC validation and the sender treats that as an attack rather than as "no policy." That is the core advantage: DANE authenticates the very first connection, MTA-STS cannot.
DANE's cost of entry
The catch is DNSSEC. DANE is only as strong as the signed zone underneath it, so you must run DNSSEC correctly for your domain and for every MX hostname's zone. DNSSEC is powerful but unforgiving. A botched key rollover or an expired signature does not just break DANE, it can make your whole domain unresolvable. Many managed DNS providers still make DNSSEC awkward, and some do not let you publish arbitrary TLSA records at all. That operational bar is the single biggest reason DANE adoption trails MTA-STS.
The provider-support reality
This is where the decision usually gets made for you. The large consumer mailbox providers made opposite choices.
Google and Microsoft both act on MTA-STS as senders. When Gmail or Microsoft 365 delivers to your domain and finds an enforcing MTA-STS policy, it honors it. Google also publishes an MTA-STS policy for Gmail's own inbound mail. Neither Gmail nor Outlook validates DANE when receiving mail, so a TLSA record on your MX does nothing for mail arriving from those two networks. Microsoft has been rolling out DANE and DNSSEC support for outbound and inbound Exchange Online in stages, but you should confirm current status in the Microsoft 365 admin center rather than assume it is on.
DANE has deep support in a different population: much of the European hosting and ISP ecosystem, mailbox providers in Germany and the Netherlands, and large operators that already run DNSSEC. If you send to or receive from those networks, DANE carries real weight.
So the support map is roughly this. MTA-STS gives you coverage with the biggest global receivers. DANE gives you stronger, TOFU-free protection with the DNSSEC-committed operators. They protect overlapping but not identical traffic.
Which one to use
You do not have to choose, and you should not frame it as either-or.
Publish MTA-STS first if you only do one thing. It has no DNSSEC prerequisite, it protects mail from Gmail and Outlook to you, and you can roll it out safely through testing mode. For most business domains this is the higher-reach, lower-risk move.
Add DANE when your DNS is already on DNSSEC or you are willing to operate it properly. DANE closes the trust-on-first-use gap that MTA-STS leaves open, and it reaches DANE-validating senders that ignore MTA-STS. If you host mail for a European audience or a security-sensitive organization, DANE is worth the operational cost.
Run both where you can. The two coexist cleanly. A sending server picks whichever standard it supports; there is no conflict when both a valid TLSA record and an enforcing MTA-STS policy exist, because each sender simply follows the one it understands. Publishing both maximizes the set of senders that are forced to encrypt and verify on the way to you.
One point to keep straight: transport security is not authentication. MTA-STS and DANE protect the pipe between servers. They say nothing about whether a message is really from your domain. That job belongs to SPF, DKIM, and DMARC, explained in SPF, DKIM, and DMARC explained and set up through how to set up DMARC and how to set up DKIM. If you are working through the Google and Yahoo sender requirements, authentication is the mandatory layer and transport security sits on top of it.
Frequently asked questions
Can I run MTA-STS and DANE at the same time?
Yes, and it is the recommended setup when your DNS supports DNSSEC. The standards do not interfere. Each sending server follows whichever one it implements, so publishing both simply means more senders are forced to use verified TLS to reach you.
Does DANE require DNSSEC?
Yes. DANE's entire security model rests on DNSSEC signing the TLSA lookup. Without a validly signed zone a TLSA record is meaningless and DANE-aware senders will ignore it. If you cannot run DNSSEC reliably, use MTA-STS instead.
Do Gmail and Outlook support DANE?
As receivers, Gmail does not validate DANE, and Outlook's support has been rolling out in stages rather than being universally on. Both honor MTA-STS as senders. This is why MTA-STS is the higher-coverage choice for reaching the large mailbox providers, and why DANE is a complement rather than a replacement.
Is MTA-STS or DANE more secure?
DANE is stronger in one specific way: it has no trust-on-first-use window, because DNSSEC authenticates the first connection. MTA-STS can be bypassed on a sender's first contact or after its cached policy expires. In practice the more secure choice is the one your receivers actually honor, which is why deploying both gives the best real-world protection.