What Is DANE for Email? TLSA Records and Real-World Adoption

DANE (DNS-based authentication (proof that email really comes from your company) of Named Entities) for email is a standard that lets a domain publish, in a DNSSEC-signed TLSA record, the fingerprint of the certificate its mail server will present. A sending server that supports DANE looks up the TLSA record for the MX host, and if it exists, refuses to deliver unless the connection is encrypted and the certificate matches. Unlike MTA-STS, it needs no HTTPS policy file, but it does require DNSSEC end to end.

Quick summary

• The sender resolves your MX records (the settings that tell the internet where to deliver email for your domain) and confirms the answer is DNSSEC-validated.
• It queries the TLSA record at _25._tcp.mail-host-name and validates that too.
• It connects on port 25 and issues STARTTLS.
• It compares the certificate the server presents against the TLSA data: either the full certificate hash or the hash of the public key, matched against the leaf or a trust anchor.
• A match means delivery proceeds. No match, or a failed TLS upgrade, means the message is deferred rather than sent in the clear.

How DANE works for SMTP

1. The sender resolves your MX records (the settings that tell the internet where to deliver email for your domain) and confirms the answer is DNSSEC-validated.
2. It queries the TLSA record at _25._tcp.mail-host-name and validates that too.
3. It connects on port 25 and issues STARTTLS.
4. It compares the certificate the server presents against the TLSA data: either the full certificate hash or the hash of the public key, matched against the leaf or a trust anchor.
5. A match means delivery proceeds. No match, or a failed TLS upgrade, means the message is deferred rather than sent in the clear.

Example TLSA record

Type:  TLSA
Host:  _25._tcp.mail.example-provider.net
Value: 3 1 1 8cb0fc6c527506a053f4f14c8464bebbd6dede2738d11468dd953d7d6a3021f1

Fields: usage 3 (DANE-EE, match the server certificate itself)
        selector 1 (use the SubjectPublicKeyInfo)
        matching type 1 (SHA-256 hash)

DANE vs MTA-STS

• Trust root: DANE trusts DNSSEC; MTA-STS trusts the web PKI and HTTPS.
• Requirements: DANE needs a DNSSEC-signed zone at the mail host domain and the sender must validate DNSSEC. MTA-STS needs an HTTPS host for the policy file and nothing else.
• Who publishes: for DANE, the TLSA record lives under the MX hostname, so it is the mail provider that must publish it. For MTA-STS, the policy lives under your own domain.
• Downgrade resistance: DANE is immune to first-contact attacks because DNSSEC signs the absence of a record. MTA-STS relies on caching after the first successful fetch.
• Support: Microsoft Exchange Online, Proton, Posteo, Mailbox.org and many European providers do DANE; Gmail does MTA-STS but not DANE.

Honest state of adoption

DANE is widespread among European and privacy-focused providers and is encouraged by government guidance in the Netherlands, Germany and Denmark, where regulators measure it. Elsewhere it is uncommon because DNSSEC deployment is low and because Gmail, the largest sender, does not validate DANE. Mail to your domain from Outlook.com or Exchange Online will use DANE if your MX host publishes TLSA records; mail from Gmail will use MTA-STS if you publish that. Supporting both is the complete answer, and both are receive-side protections that do not affect how your outgoing mail is judged.

How to check DANE for a domain

• Run dig +dnssec MX (Mail Exchanger — where incoming email is delivered) yourdomain.com and look for the ad flag, which confirms DNSSEC validation by your resolver.
• Run dig tlsa _25._tcp.your-MX (Mail Exchanger — where incoming email is delivered)-host and see whether a record exists.
• Use an online checker such as the Internet.nl mail test or the Have DANE tool, which validate the full chain and the certificate match.
• If you self-host, use posttls-finger from Postfix to simulate a DANE-aware sender.

What this means with OquMail

Because the TLSA record for DANE belongs to the MX hostname, it is published by the mail provider rather than by you. With OquMail you do not create TLSA records; your work is the MX, SPF, DKIM and DMARC records verified in the dashboard, and optionally an MTA-STS policy on your own domain. If DANE support at your provider matters to your compliance requirements, ask before you migrate, and remember that neither DANE nor MTA-STS changes whether your outbound mail lands in the inbox.

Common questions

Do I need DNSSEC on my domain for DANE?

For inbound DANE, the zone that holds the MX hostname and its TLSA record must be signed. If the MX host is on the provider domain, that is their zone, though signing your own zone protects the MX lookup too.

Can DANE break my mail?

A wrong TLSA record at the provider, or an expired DNSSEC signature, causes DANE-aware senders to defer mail until it is fixed. That is why rollover procedures matter.

Is DANE required by any regulation?

Some public sector standards in Europe require or recommend it. There is no general legal requirement for private businesses.