Setting up DANE and DNSSEC for Microsoft 365

DANE + DNSSEC for Microsoft 365: enabled via PowerShell since GA — DNSSEC on, switch the MX, SMTP DANE on.

Last updated: July 2026

In short: Microsoft 365 supports inbound SMTP DANE with DNSSEC (generally available). After this guide your domain is DNSSEC-signed and publishes, via Microsoft, a TLSA record that protects sending servers from downgrade and MITM attacks.

⚠️ Delivery risk: a wrong TLSA record or a broken DNSSEC chain makes DANE-validating servers hard-fail delivery to your domain. Enable DNSSEC first, verify every step, and plan for certificate renewal before publishing TLSA.

Prerequisites

A Microsoft 365 tenant, with your domain as an accepted domain in an error-free state
The MX record is at priority 0 or 10, without a fallback or secondary MX
Access to Exchange Online PowerShell with the necessary permissions
A DNS provider/registrar that supports DNSSEC

What is DANE with DNSSEC?

DANE (DNS-based Authentication of Named Entities) stores a TLSA record in DNS that pins your mail server's certificate. A sending server checks before delivery whether the recipient's TLS certificate matches the TLSA record — this makes the connection resistant to downgrade and man-in-the-middle attacks.

The catch, which Microsoft names clearly: "You can only trust TLSA records if you enable DNSSEC for your domain." DANE without DNSSEC is worthless — the two belong together. And without a TLSA record, "DNS resolution for mail flow works as usual without DANE checks".

DANE thus complements the other building blocks: SPF, DKIM, and DMARC secure the sender identity, DANE + DNSSEC secure the transport path.

Step-by-step guide

1. Check the prerequisites

Make sure your domain is listed error-free as an accepted domain in the Microsoft 365 admin center and the MX is at priority 0 or 10 without a fallback. If you have a fallback MX, clarify the switch beforehand with your Exchange Online administrator.

2. Lower the MX TTL

Before the switch, lower the TTL of your MX record to the lowest possible value (not below 30 seconds) and wait out the previous TTL. At an original 3600 seconds that means: wait one hour before continuing.

If you use MTA-STS: first set the policy mode to testing and update the id in the MTA-STS TXT record, then wait out the max_age. Otherwise the two mechanisms collide during the switch.

3. Enable DNSSEC

Connect to Exchange Online PowerShell and enable DNSSEC for the domain:

Enable-DnssecForVerifiedDomain -DomainName <DomainName>

The success response returns a new DNSSEC MX value in the form:

contosotest-com.o-v1.mx.microsoft

Your MX record must then point to this value — enter it at your DNS provider and also enable DNSSEC for the zone there. (If you use a third-party DNS, follow Microsoft's note for third-party gateways.)

4. Enable SMTP DANE

Once DNSSEC and the new MX are active, switch DANE on:

Enable-SmtpDaneInbound -DomainName <DomainName>

Microsoft then publishes the matching TLSA record for your domain's MX hosts. The TLSA configuration recommended by Microsoft (per the RFC guidance) is 3 1 1 — certificate usage 3, selector 1, matching type 1.

5. Wait and check

Provisioning the DNS records takes time — sometimes longer than expected due to caching.

Verify the result

Check your configuration with the free Kuveris scanner — it shows DNSSEC status, TLSA/DANE, and the interplay with SPF, DKIM, and DMARC.

Common mistakes

TLSA without DNSSEC. A TLSA record without a DNSSEC-signed zone is worthless and can cause delivery problems. Always DNSSEC first.

Overlooked a fallback MX. Microsoft's process requires exactly one MX without a secondary. A forgotten fallback MX breaks the DANE chain.

MX value not switched. After Enable-DnssecForVerifiedDomain the MX must point to the new …o-v1.mx.microsoft value — otherwise DNSSEC doesn't take effect.

MTA-STS collision. If MTA-STS is running in enforce mode, the switch can disrupt mail flow. First set it to testing, mind the id and max_age.