DANE/TLSA Records Explained for Mail Server Security

Email was never designed with security in mind. While SPF, DKIM, and DMARC have tightened up sender authentication, the actual transport of email between servers remains surprisingly fragile. This is where DANE (DNS-based Authentication of Named Entities) and its companion TLSA records come in — a powerful but often overlooked layer of mail server security.

If you run a mail server for a New Zealand business, understanding DANE could be the difference between secure, verifiable email delivery and silent interception.

What is DANE?

DANE is a protocol that lets you publish information about your server's TLS certificate directly in DNS. When another mail server connects to yours over SMTP, it can check DNS to verify exactly which certificate it should expect — rather than trusting any certificate signed by any of the hundreds of public Certificate Authorities (CAs).

DANE relies on DNSSEC (DNS Security Extensions) to cryptographically sign DNS records, ensuring they can't be tampered with in transit.

The problem DANE solves

Standard SMTP uses opportunistic TLS via the STARTTLS command. The issue? It's trivially easy for an attacker to:

• Strip the STARTTLS advertisement, forcing plain-text delivery
• Present a fraudulent certificate signed by a compromised CA
• Perform a man-in-the-middle (MITM) attack undetected

Without DANE or MTA-STS, sending servers have no way to know whether TLS should have been used, or whether the certificate presented is legitimate.

What is a TLSA Record?

A TLSA record is the DNS record type that DANE uses to publish certificate information. It sits at a special hostname format tied to the port and protocol of your service.

For SMTP on port 25, the record name looks like this:

_25._tcp.mail.yourdomain.co.nz

A TLSA record contains four fields:

_25._tcp.mail.xteam.co.nz. IN TLSA 3 1 1 ABC123...hash...DEF456

The combination 3 1 1 is the recommended setup for most mail servers — it pins the public key, which survives certificate renewals as long as you reuse the same key.

How DANE Works in Practice

When a DANE-aware sending server wants to deliver mail to yourdomain.co.nz, here's what happens:

1. Look up the MX record for yourdomain.co.nz (e.g. mail.yourdomain.co.nz)
2. Verify the MX response is DNSSEC-signed
3. Look up the TLSA record at _25._tcp.mail.yourdomain.co.nz
4. Connect via SMTP and upgrade to TLS using STARTTLS
5. Compare the server's certificate against the TLSA record
6. If it matches — deliver. If not — fail closed and retry later

This last point is critical: DANE enforces TLS. If something looks wrong, mail isn't delivered in plaintext as a fallback.

Deploying DANE/TLSA: A Step-by-Step Guide

Step 1: Enable DNSSEC on your domain

DANE is useless without DNSSEC. Most New Zealand registrars — including those offering .co.nz and .nz domains — support DNSSEC, though you may need to enable it explicitly.

Check your DNSSEC status with:

dig +dnssec yourdomain.co.nz

Look for the ad flag in the response header — that confirms authenticated data.

Step 2: Ensure your mail server supports TLS

Your MTA (Postfix, Exim, Exchange, etc.) must have a valid TLS certificate configured. Let's Encrypt works well, but you'll need to be careful about key rotation — more on that below.

Step 3: Generate your TLSA record

For a Postfix server with a Let's Encrypt certificate, generate the hash:

openssl x509 -in /etc/letsencrypt/live/mail.yourdomain.co.nz/cert.pem \
  -pubkey -noout | \
  openssl pkey -pubin -outform DER | \
  openssl sha256

The output is your certificate data field.

Step 4: Publish the TLSA record

Add the following to your DNS zone:

_25._tcp.mail.yourdomain.co.nz. 3600 IN TLSA 3 1 1 \
  5d2c15c5e51e0b4e1d1f3a8b7c6d5e4f3a2b1c0d9e8f7a6b5c4d3e2f1a0b9c8d7

If your mail server has multiple certificates or you're rotating, publish both the current and next certificate hashes to avoid delivery gaps.

Step 5: Verify your setup

Use a DANE validator to confirm everything is working correctly. You can also test with:

posftix check (if you run Postfix)
openssl s_client -starttls smtp -connect mail.yourdomain.co.nz:25 -showcerts

The Key Rotation Challenge

This is where DANE trips people up. When your certificate renews, if the new certificate has a different public key, your TLSA record becomes invalid — and mail from DANE-enforcing senders will bounce.

Best practices:

• Use selector 1 (public key) rather than selector 0 (full certificate) so you can reuse keys across renewals
• Publish the new TLSA record before deploying the new certificate, and wait for DNS propagation
• Keep the old TLSA record for a period after rotation (dual-publishing)
• Automate the process — tools like danect or custom scripts tied to your Let's Encrypt renewal hook help

DANE vs MTA-STS

Google and Microsoft have backed MTA-STS (SMTP MTA Strict Transport Security) as an alternative to DANE. MTA-STS uses HTTPS and a policy file instead of DNSSEC.

The good news: you can run both. Many security-conscious mail operators deploy DANE and MTA-STS for maximum compatibility with sending servers worldwide.

Why This Matters for NZ Businesses

New Zealand organisations — particularly those in finance, health, legal, and government supply chains — are increasingly expected to demonstrate strong email security controls. Deploying DANE:

• Protects sensitive communications from interception
• Demonstrates technical diligence in security audits
• Aligns with NCSC NZ guidance on secure email transport
• Improves trust with overseas partners whose mail servers enforce DANE

Check Your Mail Server Security with xteam

Not sure whether your domain has DANE, MTA-STS, SPF, DKIM, or DMARC configured correctly? Don't guess — check.

Try xteam's free MailCheck tool to instantly audit your domain's email security posture. You'll get a clear report on your SPF, DKIM, DMARC, MTA-STS, and DANE configuration — with actionable recommendations tailored for New Zealand businesses.

Secure email transport isn't optional anymore. Make sure yours is locked down.