What is DANE and does your email need it?

What are the requirements?

DNSSEC must authenticate the TLSA lookup

A DANE client uses DNSSEC validation to decide whether TLSA data is secure and usable. DNSSEC is not an optional hardening layer around SMTP DANE. It is the trust mechanism that prevents an active network attacker from replacing or suppressing the TLSA answer.

Before publishing TLSA records, confirm that the zone is signed, its delegation is correct, and validating resolvers can obtain secure answers. A DNSSEC failure can have delivery consequences for DANE-aware senders, so treat DNSSEC changes as production mail changes.

The TLSA record binds a TLS service to certificate data

RFC 6698 defines a TLSA record as four fields: certificate usage, selector, matching type, and certificate association data. The first three fields state how to evaluate the association data. The last field contains the certificate or public-key material, or a digest of it, selected by those fields.

For SMTP, the TLSA owner name is built from the TCP port and the destination MX hostname. This structural example is illustrative only. Do not publish another organization's certificate association data. Generate the actual value from the certificate or key used by your own MX host.

_25._tcp.mail.yourdomain.com. IN TLSA 3 1 1 <SHA-256-subject-public-key-info-digest>

A 3 1 1 TLSA record uses DANE-EE certificate usage, the SubjectPublicKeyInfo selector, and a SHA-256 matching type. RFC 7672 describes DANE-EE as the expected SMTP deployment profile. The correct value still depends on the certificate or public key your receiving mail server presents.

SMTP delivery uses the MX hostname, not only the recipient domain

SMTP delivery first follows the recipient domain's MX records. RFC 7672 applies TLSA lookups to the resulting SMTP destination hostnames. If yourdomain.com has several MX hosts, each host that can receive mail needs TLSA data that matches the TLS service it presents.

A TLSA record at _25._tcp.yourdomain.com does not automatically cover mail.yourdomain.com when that is the MX hostname. Review the published MX answers and build the TLSA name from each actual destination host.

This is also why an MX change, certificate renewal, or load-balancer change needs DANE review. A valid TLSA record for one host does not authenticate another host with a different certificate or public key.

The sender authenticates TLS when usable DANE records exist

SMTP has historically used opportunistic TLS. A sender can use STARTTLS when offered, but traditional opportunistic TLS does not by itself stop a network attacker from stripping STARTTLS or presenting an untrusted certificate.

RFC 7672 defines how a DANE-aware SMTP client uses DNSSEC-authenticated TLSA records to obtain authenticated TLS. When the client has usable DANE TLSA records for the destination, it must not fall back to unauthenticated delivery merely because TLS authentication fails. Delivery can defer while the sender retries according to its queue policy.

A stale or incorrect TLSA record can interrupt inbound mail from DANE-aware senders. Stage certificate and TLSA changes together, and keep a tested rollback path.

When does the requirement take effect?

DANE is an IETF protocol standard, not a single mailbox-provider deadline. RFC 6698 was published in August 2012 and defines TLSA records. RFC 7671, published in October 2015, gives DANE operational guidance. RFC 7672, published in October 2015, defines SMTP transport security using DANE.

These are final RFCs, not drafts. They do not impose a universal date by which every email domain must publish TLSA records, and they do not guarantee that every sending platform will use them. Your effective date is operational: DANE begins to affect delivery when a supporting sender reaches one of your DNSSEC-validated MX destinations and finds usable TLSA records.

Do not turn uneven implementation support into a protocol claim. Test the sending paths that matter to your organization, and retain MTA-STS or other transport controls where they fit your requirements.

How do I implement the requirement?

1. Inventory your receiving MX hosts

Query the MX records for the recipient domain and list every hostname that can receive SMTP mail. Include priority changes, regional hosts, and failover hosts.

Use DNS records for business email as a reference for the roles of MX, TXT, and other email DNS records. DANE records are tied to the MX destination hostname, not to a vague idea of the email domain.

2. Establish and validate DNSSEC

Enable DNSSEC with the DNS operator responsible for the zone and confirm the parent delegation is correct. Validate the chain with a DNSSEC-aware resolver before relying on TLSA data.

A public lookup can help inspect published DNS. It cannot prove that every production sender validates the chain, that your mail host is presenting the intended certificate, or that a particular receiver will accept delivery.

3. Obtain the certificate association data from the receiving service

Identify the certificate or public key that each MX host presents for SMTP on TCP port 25. Decide the TLSA usage, selector, and matching type based on the applicable RFC profile and your service's certificate lifecycle.

Coordinate with a managed mail provider before publishing records. Do not derive values from a browser certificate for a web hostname and assume they apply to SMTP. The SMTP listener may use a different certificate or key.

4. Publish TLSA records for each destination host

Publish a DNSSEC-signed TLSA record at _25._tcp. for every relevant MX hostname. Allow DNS propagation and DNSSEC validation to complete before changing the certificate or routing production mail to a new host.

When rotating keys, publish association data that supports the planned transition before withdrawing the old record. The exact overlap strategy depends on the certificate material and record choices you use.

5. Keep transport security separate from sender authentication

DANE protects the connection between SMTP servers. It does not tell a recipient whether the visible From domain is authorized to send the message.

Maintain SPF, DKIM, and DMARC alongside transport controls. DMARC's role in email security is different: it evaluates identifier alignment and policy for a message's From domain.

How do I validate compliance?

Validate DANE at four layers.

• DNS: inspect MX, TLSA, DNSKEY, DS, and DNSSEC validation results through authoritative DNS and at least one validating public resolver. Confirm each TLSA owner name maps to a real MX destination.
• Vendor or host: confirm with the mail-hosting provider which SMTP certificate and public key each receiving host currently presents. A provider dashboard can help, but it is not message-path evidence.
• Message and TLS: test SMTP delivery from a DANE-capable sending path to the exact production MX host. Confirm that the certificate presented during SMTP TLS matches the published, DNSSEC-validated TLSA association.
• Ongoing DMARC evidence: use aggregate reports to understand who sends mail using your domain. DMARC reports do not validate inbound DANE, but they help keep sender authentication work separate from transport-security work.

Use Palisade's DNS lookup tool to inspect public DNS records for a domain before making changes. A public DNS check does not prove the production SMTP certificate, continuous DNSSEC health, a sender's DANE implementation, or future delivery decisions.

Inspect the DNS records behind your DANE deployment

Start with the MX hosts and published DNS records for the receiving domain. Compare every TLSA record with the SMTP service and certificate your mail provider confirms.

Start with Palisade

Palisade is agentic DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, and proposes prioritized remediation work for human review. It can help with the ongoing sender-authentication work around your domains, but it does not change a DANE policy, validate every SMTP TLS connection, or control a receiving provider's delivery decision.