Enable inbound SMTP DANE with DNSSEC in Exchange Online and switch your MX

To enable inbound SMTP DANE with DNSSEC in Exchange Online, sign your domain's zone with DNSSEC at your DNS host, run Enable-DnssecForVerifiedDomain to get a new MX host name under mx.microsoft, add that record at priority 20, test it, make it the only MX at priority 0 and delete the legacy record that ends in mail.protection.outlook.com, then run Enable-SmtpDaneInbound so Exchange Online publishes TLSA records for the new host. Finish by validating with the DANE test in the Microsoft Remote Connectivity Analyzer. The whole change is per accepted domain and can be rolled back.

Who this is for and what you will have

This guide is for Exchange Online administrators who want sending servers to authenticate their inbound mail endpoint, not just encrypt the connection opportunistically, and who are comfortable changing MX records in production. At the end you will have, for one accepted domain:

• DNSSEC enabled in Exchange Online and the MX record moved to the mx.microsoft host it returns, with no gap in mail delivery.
• Inbound SMTP DANE enabled, so senders that validate DANE can confirm they reached Exchange Online.
• A tested rollback path and the status commands to check the configuration later.

How inbound DANE protects your mail

Opportunistic TLS encrypts a connection when both sides support it, but a sender can still be sent to the wrong server if DNS is spoofed, and an attacker in the path can strip the STARTTLS offer. DNSSEC signs DNS records so a validating resolver can prove the MX, address and TLSA records are authentic. DANE for SMTP (RFC 7672) adds a TLSA record for each MX host, published at _25._tcp.<MX host>, that tells the sender which certificate or public key to expect. A sender that supports DANE refuses to deliver if TLS isn't offered or the certificate doesn't match.

Both halves have to be signed: your zone, which holds the MX record, and the zone that holds the MX host and its TLSA records. That second zone is why Exchange Online gives you a new MX host name. The mx.microsoft hosts returned by Enable-DnssecForVerifiedDomain are where Exchange Online provisions the DNSSEC-capable records and, after Enable-SmtpDaneInbound, the TLSA records. You keep control of your own zone's signing at your DNS host.

The o-v1 part of the example can't be predicted from your domain name; always use the value Exchange Online returns.

What changed for new domains in 2026

Message center post MC1048624 announced that A records for new accepted domains provisioned from July 1, 2026 are created under subdomains of mx.microsoft instead of mail.protection.outlook.com, rolled out gradually during July 2026. For such a domain, if your zone is already DNSSEC-signed, DNSSEC protection extends to the mx.microsoft record without further action. The post also tells administrators to stop building MX values from the old mail.protection.outlook.com pattern in automation and to read the value from the List serviceConfigurationRecords Graph API instead:

GET https://graph.microsoft.com/v1.0/domains/contoso.com/serviceConfigurationRecords

The MX entry is the object with recordType set to Mx, and its mailExchange property holds the host name; the API needs Domain.Read.All. Existing domains keep their current MX until you change it with the procedure below, and DANE is still enabled separately with Enable-SmtpDaneInbound.

Prerequisites

• The domain is an accepted domain and shows Healthy in the Microsoft 365 admin center. Microsoft's procedure assumes the existing MX is at priority 0 or 10 with no fallback or secondary MX record; if you have one, plan the change carefully with whoever owns it.
• DNSSEC enabled for the zone at your DNS hosting provider, so you get the full benefit of the feature.
• Exchange Online PowerShell with permission to run the DNSSEC and DANE cmdlets.
• Access to your DNS host to add, re-prioritize and delete MX records and change TTLs.
• If you publish MTA-STS, the ability to edit the policy file and the _mta-sts TXT record.

Domains that aren't supported: the tenant's onmicrosoft.com domain (the cmdlets return DomainNotSupported) and domains set up through self-service (viral) sign-up.

Check that your zone is signed before you start. A DS record at the parent and RRSIG records in your zone are the signs to look for:

Resolve-DnsName -Name contoso.com -Type DS -Server 8.8.8.8
Resolve-DnsName -Name contoso.com -Type MX -DnssecOk -Server 8.8.8.8

dig +short DS contoso.com @8.8.8.8
dig +dnssec MX contoso.com @8.8.8.8

Step 1: Lower the TTL of the current MX record

Set the TTL of your existing MX record to the lowest value your DNS host allows, but not lower than 30 seconds, then wait for the old TTL to expire. If it was 3,600 seconds, wait an hour. This makes the later priority changes take effect quickly.

If you use MTA-STS, set the policy mode to testing now, update the id in the _mta-sts TXT record (the current UTC time works as an ID) and wait for the policy's max_age to expire before continuing.

Step 2: Enable DNSSEC for the domain in Exchange Online

Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
Enable-DnssecForVerifiedDomain -DomainName contoso.com

The command can take a few minutes. A successful result looks like this:

Result   DnssecMxValue                       ErrorData
------   -------------                       ---------
Success  contoso-com.o-v1.mx.microsoft

DnssecMxValue is the host name your new MX record must point to. Copy it exactly.

Step 3: Add the new MX record at priority 20

At your DNS host, add a second MX record for the domain pointing to the DnssecMxValue, with the lowest TTL allowed (not under 30 seconds) and priority 20. Leave the existing record in place for now:

contoso.com.  MX  0   contoso-com.mail.protection.outlook.com.
contoso.com.  MX  20  contoso-com.o-v1.mx.microsoft.

If you use MTA-STS, replace the mx: line for the legacy host in the policy file with the new host name, and update the policy ID in both the file and the TXT record.

Step 4: Test the new MX

Run the Inbound SMTP Email test in the Microsoft Remote Connectivity Analyzer (https://testconnectivity.microsoft.com/tests/O365InboundSmtp/input), expand Test Steps and confirm that the Mail Exchanger ending in mx.microsoft was tested successfully. Because of DNS caching you might need to run it more than once.

Step 5: Swap priorities, then remove the legacy MX

1. Change the legacy record (ending in mail.protection.outlook.com) to priority 30, and the new mx.microsoft record to priority 0.
2. Once mail is flowing through the new record, delete the legacy MX record. Microsoft lists three legacy forms to remove: records ending in mail.protection.outlook.com, mail.eo.outlook.com or mail.protection.outlook.de.
3. Raise the TTL of the mx.microsoft record to 3,600 seconds.
4. Optionally run the Remote Connectivity Analyzer DANE test page (https://testconnectivity.microsoft.com/tests/O365DaneValidation/input) and choose DNSSEC Validation, not DANE Validation [including DNSSEC], because DANE isn't on yet. Results settle once the legacy record's TTL has expired.

The end state is a single MX record:

contoso.com.  MX  0  contoso-com.o-v1.mx.microsoft.

Step 6: Enable inbound SMTP DANE

Enable-SmtpDaneInbound -DomainName contoso.com

A Success result means Exchange Online will provision the TLSA records. Propagation can take 15 to 30 minutes. Then run the Remote Connectivity Analyzer DANE test again, this time choosing DANE Validation [including DNSSEC].

Exchange Online publishes several TLSA records for reliability, and Microsoft states that some of them are expected to fail validation. As long as one TLSA record passes, DANE is configured correctly.

You can also query the records yourself from a validating resolver; the owner name is _25._tcp. followed by your MX host:

dig +dnssec TLSA _25._tcp.contoso-com.o-v1.mx.microsoft @8.8.8.8

If you use MTA-STS, set the policy mode back to enforce once mail is flowing as expected, and update the policy ID again.

Check the configuration later

Get-DnssecStatusForVerifiedDomain -DomainName contoso.com
Get-SmtpDaneInboundStatus -DomainName contoso.com

For readable detail from the DNSSEC status cmdlet, expand its properties:

$r = Get-DnssecStatusForVerifiedDomain -DomainName contoso.com
$r.DnssecFeatureStatus
$r.DnsValidation
"Expected MX record: [$($r.ExpectedMxRecord.Record)]"
$r.MxValidation
$r.MtaStsValidation

MxValidation compares the records in your zone with the expected one, and MtaStsValidation checks that your MTA-STS policy lists the new host.

If a third-party gateway receives your mail first

When the MX points to a filtering service that relays to Exchange Online, the internet-facing MX doesn't change. Instead, run Enable-DnssecForVerifiedDomain, then in the gateway's admin portal change the smart host it delivers to into the DnssecMxValue, and validate with the DNSSEC Validation test. DANE then protects only the leg from the gateway to Exchange Online, and only if the gateway supports SMTP DANE with DNSSEC validation; Microsoft says this configuration must be set up with Exchange Online PowerShell. Gateways in front of Exchange Online also affect sender authentication; ARC trusted sealers and Enhanced Filtering covers that side.

If a third-party service on your outbound path resubmits mail to Exchange Online through a connector, it has to find Exchange Online by DNS lookup and use the new mx.microsoft host name. Coordinate the change with that provider.

Troubleshooting

Errors from the enable and disable cmdlets

Messages from Get-DnssecStatusForVerifiedDomain

Microsoft notes that DNS propagation can take up to 48 hours with some providers, so rerun the status cmdlet after a while before changing records again.

Mail flow problems after enabling

• DANE validations failing: run Disable-SmtpDaneInbound -DomainName contoso.com.
• DNSSEC validations failing: disable DNSSEC for the zone at your DNS provider and open a ticket with them to find out how to re-enable it safely. If disabling DNSSEC doesn't resolve the issue, the problem might be the MX value.
• MX value problems: compare your MX with Settings > Domains > your domain > DNS records > Check health in the Microsoft 365 admin center, then roll back if needed.

Roll back the MX change

1. Add an MX record at priority 20 pointing to <MX token>.mail.protection.outlook.com, where the token is the first label of your current mx.microsoft host (for contoso-com.o-v1.mx.microsoft it is contoso-com).
2. Confirm it works with the Remote Connectivity Analyzer Inbound SMTP Email test, checking that this MX record is healthy in the test details.
3. Run Disable-DnssecForVerifiedDomain -DomainName contoso.com.
4. Delete the mx.microsoft MX record and set the restored record to priority 0, so it is the only MX.

Checklist

• Zone DNSSEC-signed at the DNS host; DS record visible at the parent.
• MX TTL lowered and old TTL expired; MTA-STS in testing mode if used.
• Enable-DnssecForVerifiedDomain returned a DnssecMxValue; new MX added at priority 20 and tested.
• Priorities swapped, legacy MX deleted, new MX at priority 0 with TTL 3,600.
• Enable-SmtpDaneInbound succeeded; DANE validation passes for at least one TLSA record.
• MTA-STS back in enforce mode with the new host listed.
• Automation reads MX values from the serviceConfigurationRecords Graph API, not from the old naming pattern.
• Rollback steps documented for the domain.

References

• How SMTP DNS-based Authentication of Named Entities (DANE) works
• Enable-DnssecForVerifiedDomain
• Get-DnssecStatusForVerifiedDomain
• Enable-SmtpDaneInbound
• Get-SmtpDaneInboundStatus
• List serviceConfigurationRecords (Microsoft Graph)
• MC1048624: DNS Provisioning Change (message center archive)
• Resolve-DnsName
• RFC 7672: SMTP Security via Opportunistic DANE TLS