DNSSEC and DANE for Exchange Online: turn the mail test green

A mail test such as our email security check often looks like this: IPv6, SPF, DKIM and DMARC are green, and the score stalls well short of 100%. Red: not all domain names are DNSSEC-signed, and the mail-server connection is not or insufficiently secured (STARTTLS and DANE).

That is not a missing checkbox inside the Exchange Online tenant. Outbound DANE has been on for all tenants since 2022. For inbound mail you must sign your own zone first, then move MX off the legacy host mail.protection.outlook.com onto Microsoft’s DNSSEC-signed *.mx.microsoft name, then let Microsoft publish TLSA.

What the mail test actually measures

SPF, DKIM and DMARC prove who may send as your domain. STARTTLS, DNSSEC and DANE are about the path to your mailbox: is the MX authentic, and is the receiving server’s certificate bound in DNS so a man-in-the-middle cannot swap it?

DANE without DNSSEC does not exist. If DNS is unsigned, an attacker can forge MX and TLSA. Exchange Online always offers STARTTLS, but without TLSA records the DANE check stays red.

What fails on mail.protection.outlook.com

A real test against MX 365fanatic-com.mail.protection.outlook.com shows four red subtests. They all belong to Microsoft’s legacy inbound host. You cannot turn cipher suites or SHA-1 off in the tenant admin center. The fix is the MX cutover — after your zone has DNSSEC.

DNSSEC existence and DANE existence go green after MX moves to a signed Microsoft host and DANE is enabled. Cipher suites and SHA-1 live in Microsoft’s TLS stack. They can still be red on the new host until Microsoft tightens inbound TLS.

Two layers, not one switch

1. DNSSEC on your own zone (Cloudflare / registrar). Apex, www, autodiscover and the MX lookup must sit in a signed zone with DS at the TLD. This is “not all domain names signed”.
2. Inbound SMTP DANE in Exchange Online. Microsoft does not publish TLSA on mail.protection.outlook.com. You switch MX to *.mx.microsoft (DNSSEC-signed) and then enable DANE. Microsoft writes the TLSA records; you do not create them.

Outbound DANE (mail from Exchange Online to a recipient that has DANE) is already on. You do not configure that.

Step 1 — DNSSEC on the domain (Cloudflare)

Do not touch Exchange Online until this is green.

1. Cloudflare → the domain → DNS → Settings → Enable DNSSEC.
2. If the registrar is elsewhere (SIDN, TransIP, …), copy the DS record Cloudflare shows into the registrar. Without DS at the TLD the zone is “signed but insecure”, and the DNSSEC check stays red.
3. If Cloudflare is the registrar, one click is enough; the DS goes to the registry automatically.
4. Wait until the chain is live (minutes, sometimes up to 24 hours). Check with the Verisign DNSSEC Debugger or dig +dnssec MX your-domain.nl.

Do not turn DNSSEC off “to test” once the DS is at the registry: resolvers that enforce DNSSEC will then refuse the whole zone.

Step 2 — Exchange Online: DNSSEC MX

Do not start until step 1 is green. Further prerequisites: the domain is an Accepted domain with status Healthy, MX currently points to …mail.protection.outlook.com, Exchange Online PowerShell in PowerShell 7 (not ISE). Microsoft’s steps assume a single MX.

If you use MTA-STS: set the policy to testing, bump the policy id, wait until max_age has expired, then change the mx: row to the new host. Only then set enforce again.

Lower the TTL of the current MX (minimum 30 seconds). Wait until the old TTL has expired. Then:

Connect-ExchangeOnline
Enable-DnssecForVerifiedDomain -DomainName "contoso.nl"

The output contains DnssecMxValue, for example contoso-nl.o-v1.mx.microsoft. That is the new MX host. You do not create TLSA; you do create this MX record:

1. New MX: value = DnssecMxValue, priority 20, TTL as low as possible (≥ 30 s).
2. Test mail flow: Inbound SMTP Email in the Remote Connectivity Analyzer. Under Test Steps the exchanger must end in mx.microsoft.
3. Old MX (mail.protection.outlook.com) to priority 30; new MX to priority 0.
4. Wait until mail is arriving. Delete the old MX. Set the new MX TTL to 3600.

Partners or connectors that hard-code tenant.mail.protection.outlook.com must follow the new host (or keep that name as Microsoft’s smarthost — not as your public MX). Third-party gateways (Proofpoint, Mimecast, …) must support DNSSEC/DANE themselves, or the chain stops at the gateway.

Step 3 — Inbound DANE (TLSA)

Only once the DNSSEC MX is live:

Enable-SmtpDaneInbound -DomainName "contoso.nl"

Exchange Online publishes TLSA at _25._tcp. (15–30 minutes). Microsoft publishes several TLSA records; it is normal for one to fail at a validator, as long as at least one succeeds.

Get-DnssecStatusForVerifiedDomain -DomainName "contoso.nl"
Get-SmtpDaneInboundStatus -DomainName "contoso.nl"

Step 4 — Test

1. Microsoft DNSSEC and DANE Validation — first DNSSEC only, then DANE including DNSSEC.
2. Our email security check — after the DNS cache expires (sometimes hours) DNSSEC and DANE should go green. With SPF, DKIM, DMARC and IPv6 already fine, the score then reaches the top. Cipher suites and SHA-1 are not DNS settings; a TLS connection test can still show them Microsoft-red.

Test the mail domain (the name after @), not only www. A website test is not the yardstick here.

What not to do

• Publish a TLSA record on your zone for Outlook yourself. It belongs on Microsoft’s MX host, and Microsoft writes it.
• Leave old and new MX both at priority 0 “to be safe”. Senders then pick the unsigned host at random and DANE fails intermittently.
• Turn on inbound DANE on tenant.onmicrosoft.com. Microsoft does not support that.
• Force this in a five-minute change window. MX cutover follows TTLs; plan it, send a test message, then clean up.
• Run Enable-DnssecForVerifiedDomain while your zone still has no DS at the registry.

Roll back

Disable-SmtpDaneInbound -DomainName "contoso.nl"
Disable-DnssecForVerifiedDomain -DomainName "contoso.nl"

Then point MX back to contoso-nl.mail.protection.outlook.com (or whatever the admin center shows). Leave DNSSEC on in Cloudflare: that is your zone, not Microsoft’s MX.

In short

The mail test is not marking a missing Microsoft checkbox. It is marking an unsigned zone and an MX without DANE. Sign the domain at Cloudflare (including DS at the registrar) first. Move MX to *.mx.microsoft with Enable-DnssecForVerifiedDomain. Then Enable-SmtpDaneInbound. Recheck with the Microsoft analyzer and our email security check. SPF/DKIM/DMARC stay as they are; this is the transport layer on top.

Sources: Microsoft Learn, How SMTP DANE works; cmdlets Enable-DnssecForVerifiedDomain and Enable-SmtpDaneInbound. Test: 365Fanatic email security check.