Enabling DANE for Microsoft 365 (Exchange Online)

What DANE is

DANE (DNS-based Authentication of Named Entities) lets a sending mail server confirm it is talking to the genuine server for your domain before it hands over any email. Your domain publishes a TLSA record in DNS, protected by DNSSEC, that pins the receiving server's TLS certificate.

Without DANE, an attacker sitting between the two servers can strip or downgrade the TLS encryption (a downgrade or man-in-the-middle attack) and read or alter mail in transit. With DANE in place, the sending server refuses to deliver unless the secure connection matches what DNS says it should be, so mail coming in to your domain is protected from interception.

Does Microsoft 365 support DANE?

Yes. Exchange Online supports inbound SMTP DANE with DNSSEC. It is not switched on by default: your domain has to be moved onto Microsoft's DNSSEC-enabled mail infrastructure, which changes your MX record and is enabled with a short PowerShell step. Microsoft publishes and manages the TLSA records for its own servers, so you never create or renew those yourself.

Before you start

• Your domain is an Accepted Domain in Microsoft 365 and shows a Healthy status.
• Your current MX points to a host ending in mail.protection.outlook.com, at priority 0 or 10, with no secondary or fallback MX record.
• DNSSEC is enabled on your own domain's zone at your DNS provider (your registrar or DNS host), not on the Microsoft side. This authenticates your MX record so sending servers will trust it and perform DANE. Microsoft's mail infrastructure is already DNSSEC-signed and manages the TLSA records, so there is nothing to enable on the Microsoft side.
• You can reach Exchange Online PowerShell and have permission to run the cmdlets.
• Not supported: onmicrosoft.com domains and self-service sign-up domains.

Turning on DNSSEC is usually a single switch in your DNS provider's control panel; enabling it also places a DS record at your registrar to complete the chain of trust. If your DNS is hosted separately from your registrar, enable it where the zone is hosted and make sure the DS record reaches the registrar. To confirm it is active, check your domain with a tool such as the Verisign DNSSEC Analyzer (dnssec-analyzer.verisignlabs.com).

Connecting to Exchange Online PowerShell

The commands in the steps below run in Exchange Online PowerShell. If you have not connected to it before, do this first on a Windows PC:

1. Open Windows PowerShell as an administrator.
2. Install the Exchange Online management module (this is a one-time step; answer Yes to any prompt to trust the repository): Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser
3. Connect, signing in with a Microsoft 365 account that has administrator rights: Connect-ExchangeOnline -UserPrincipalName admin@yourdomain.com
4. A Microsoft sign-in window opens. Complete sign-in, including multi-factor authentication if you are prompted.

You are now connected and can run the commands in the steps below. You need a role that allows these cmdlets, for example Global Administrator or an Exchange administrator role. When you have finished, close the session with:

Disconnect-ExchangeOnline

Step 1: enable DNSSEC and get your new MX value

Connect to Exchange Online PowerShell, then run the command below (replace the example with your own domain):

Enable-DnssecForVerifiedDomain -DomainName yourdomain.com

This takes a few minutes. Note the DnssecMxValue it returns, this is your new MX host. It looks like yourdomain-com.o-v1.mx.microsoft. The exact value is unique to your domain, so always use the one the command gives you rather than copying this example.

Step 2: update your MX records in your DNS control panel

At your DNS provider, move your MX from the old Outlook host to the new Microsoft one. Microsoft recommend doing this in stages so that no mail is lost while DNS propagates:

1. Lower the TTL on your existing MX record and wait for the old TTL to expire.
2. Add the new MX record (the DnssecMxValue from Step 1) at priority 20.
3. Confirm it works using the Inbound SMTP Email test (link below).
4. Set the new MX to priority 0 and the old mail.protection.outlook.com MX to priority 30.
5. Once mail is flowing through the new record, delete the old MX and set the new MX TTL back to 3600.

Your mail is now running on DNSSEC-protected infrastructure under mx.microsoft.

Step 3: turn on SMTP DANE

Back in Exchange Online PowerShell, run:

Enable-SmtpDaneInbound -DomainName yourdomain.com

Microsoft provisions the TLSA records for you. Allow 15 to 30 minutes for them to propagate, then confirm with the DANE validation test (link below). Your inbound mail is now DANE compliant.

Verify and finish

• Inbound SMTP Email test: testconnectivity.microsoft.com/tests/O365InboundSmtp/input
• DANE validation test: testconnectivity.microsoft.com/tests/O365DaneValidation/input
• In the Microsoft 365 admin centre, open Settings, Domains, your domain, DNS records, then Check health.
• If you use MTA-STS, set its policy to testing mode before the MX change and return it to enforce once DANE validates.

If you need to roll back

To revert, disable DANE and DNSSEC and restore your original MX:

Disable-SmtpDaneInbound -DomainName yourdomain.com
Disable-DnssecForVerifiedDomain -DomainName yourdomain.com

Restore the old mail.protection.outlook.com MX at priority 0, verify mail flow, then remove the mx.microsoft record. DNS changes can take up to 48 hours to fully propagate with some providers.

Good to know

• If you have a third-party mail gateway or filtering service in front of Microsoft 365, your inbound mail is only DANE-protected if that gateway itself validates DANE. Otherwise, apply DANE at the gateway.
• Microsoft manages the receiving certificates and TLSA records, so there is nothing for you to renew on your side once this is set up.