DANE puts your mail server's certificate fingerprint in DNS, under the MX host it belongs to, and signs it with DNSSEC so a sending server can verify the certificate without trusting a public certificate authority. It is a finished standard, not a draft: RFC 7672 has been standards track since October 2015.
The four mailbox providers that decide whether most of your mail arrives publish no TLSA record at all. We checked Gmail, Outlook.com, Yahoo and iCloud on 22 September 2026 and found none. That does not make DANE worthless, but it does decide what you should do first, and the answer is MTA-STS.
DANE is a TLSA record under your MX host, and DNSSEC is the whole point
A TLSA record holds a hash of the certificate or public key your mail server presents, published at _25._tcp. plus the MX hostname. RFC 6698 defined the record type in August 2012; RFC 7672 defined how SMTP uses it in October 2015, and RFC 7671 added operational guidance the same month.
The trust anchor is DNSSEC, and that is not a detail you can defer. A sending server learns your certificate fingerprint from DNS, so the answer has to be authenticated in DNS. Without a signed chain, anyone in a position to tamper with the lookup can delete the TLSA record and the sender falls back to unauthenticated TLS, which is the attack DANE exists to stop. A TLSA record published in an unsigned zone is decoration.
That is also why DANE is a property of your MX host rather than your domain. The record hangs off each hostname in your MX set, so a domain with three MX hosts needs three sets of records, and every one of them has to stay in step with the certificate on that machine.
Only two of the four certificate usages are legal for SMTP
TLSA carries a usage field with four values, and RFC 7672 section 3.1.3 rules out half of them for mail.
| Usage | Name | Allowed for SMTP |
|---|---|---|
| 0 | PKIX-TA | No |
| 1 | PKIX-EE | No |
| 2 | DANE-TA | Yes |
| 3 | DANE-EE | Yes |
The reason is stated plainly in the RFC: SMTP client MTAs cannot be expected to be configured with a suitably complete set of trusted public CAs. Usages 0 and 1 ask the sending server to validate against the public CA system as well, and a mail server is not a browser. The specification says client treatment of those two is undefined and that clients may treat such records as unusable, so publishing one is a coin flip on somebody else's implementation.
In practice the field settles on one shape. Posteo publishes five TLSA records per MX host, every one of them usage 3, selector 1, matching type 1: DANE-EE over the subject public key, hashed with SHA-256. That is 3 1 1, and it is the form to copy. Selector 1 matters because it covers the key rather than the certificate, so renewing a certificate with the same key does not break the record.
None of the four large mailbox providers publish TLSA
We queried every MX host of each domain below for a TLSA record at _25._tcp., through both Google Public DNS and Cloudflare DNS, on 22 September 2026. Both endpoints agreed on every row.
| Domain | TLSA on its MX hosts |
|---|---|
| gmail.com | None |
| outlook.com | None |
| yahoo.com | None |
| icloud.com | None |
| t-online.de | None |
| posteo.de | 5 records per host, all 3 1 1 |
| mailbox.org | 1 to 2 records per host |
| gmx.net | 2 records per host |
| web.de | 1 record per host |
| freenet.de | 2 records per host |
| protonmail.ch | 2 records per host |
| nic.cz | 1 record per host |
| rijksoverheid.nl | 2 records per host |
The pattern is regional rather than technical. German and Swiss mailbox providers, the Czech domain registry and the Dutch government all publish TLSA and sign their zones. The four providers whose filtering decisions most senders actually care about do not, and t-online.de is the German exception that proves the split is a choice each operator makes rather than a national rule.
Exchange Online publishes TLSA on its newer MX hosts and not its older ones
Microsoft is the one large operator moving. Tenants whose MX points at the newer mx.microsoft hostname carry four TLSA records, mixing usage 2 and usage 3, in a DNSSEC-signed zone. We saw this on kpn.com and sidn.nl, both of which resolve to hosts under mx.microsoft.
The older Exchange Online hostname under mail.protection.outlook.com carries nothing, and neither does the consumer hostname behind outlook.com. So "does Microsoft support DANE" has no single answer: it depends which MX hostname your tenant was given, and that is worth checking on your own domain rather than reading off an announcement.
One host answered SERVFAIL, and that is not the same as no record
Querying microsoft-com.mail.protection.outlook.com returned SERVFAIL from Google Public DNS and NXDOMAIN from Cloudflare DNS. Those are different claims, and only one of them is an answer.
Only NOERROR and NXDOMAIN tell you something about the zone. A SERVFAIL tells you the lookup failed, which is a fact about the resolver and the path, not about whether a record exists. A checker that prints "no DANE" on a SERVFAIL is asserting something it did not measure, and the reader acts on it as though the operator had decided not to publish.
This is why every row in the table above was read twice, through two independent resolvers, and why the one host that disagreed with itself is described here instead of being given a verdict.
MTA-STS is the policy you can publish today without DNSSEC
MTA-STS solves the same problem with a different trust anchor. RFC 8461, published September 2018 by authors at Google, Oath, Comcast and Microsoft, puts a policy file behind HTTPS on a well-known host and points at it from a TXT record. The Web PKI authenticates the policy, so no DNSSEC is required.
| DANE for SMTP | MTA-STS | |
|---|---|---|
| Standard | RFC 7672, 2015 | RFC 8461, 2018 |
| Trust anchor | DNSSEC | Web PKI over HTTPS |
| Published as | TLSA per MX host | TXT record plus a policy file |
| Needs a signed zone | Yes | No |
| Large provider support | Rare | Common |
They are not rivals and a domain can publish both. If your zone is signed and you run your own mail servers, DANE is stronger, because it does not depend on the certificate authority system it replaces. If your zone is not signed, MTA-STS is the only one of the two you can deploy at all, and it is the one the large providers honor.
What to do, in order
- Check what your MX hosts already publish, with our MX record lookup, before deciding anything. If you are on a hosted platform, the answer is your provider's to change, not yours.
- Publish MTA-STS. It works without DNSSEC, the large providers enforce it, and it is the change that affects real delivery this quarter. Our MTA-STS checker reads the TXT record and the policy file together.
- Publish TLS-RPT. It is one TXT record, it changes nothing about delivery, and it is how you find out whether either policy is being honored. Our TLS-RPT checker validates the record, including the case-sensitive version tag that silently discards a record spelled in lowercase.
- Add DANE only if you sign your zone and run your own MX. Publish
3 1 1per host, and rotate the record before the certificate, never after. - Never publish TLSA in an unsigned zone. It authenticates nothing and it commits you to keeping a record in step with a certificate for no gain.
Why we check MTA-STS and TLS-RPT but not DANE
A DANE verdict needs a DNSSEC trust decision, and our checkers run in your browser over DNS-over-HTTPS. The AD bit in a DoH response is the resolver's claim that it validated the chain, not proof that the chain validates. Reporting a green DANE result on somebody else's assertion would be exactly the kind of confident, unearned verdict these tools exist to avoid, so we do not ship one.
The transport records we can read completely, we do read completely. Everything else about your sending setup is a different layer, and our guide to email authentication covers how SPF, DKIM and DMARC fit together above it. Across the domains we test for the Unspam 2026 Email Deliverability Benchmark, 48% publish a DMARC policy, which is the unfinished work that moves more mail than TLSA ever will.
To see what a real message actually carries when it arrives, run a free spam test.
