How to Configure Inbound SMTP DANE & DNSSEC in Exchange Online
- Sebastian F. Markdanner
- 11 minutes ago
- 5 min read
We’re already sending emails securely, now it’s time to secure inbound email as well!
Back in 2022, Microsoft enabled outbound SMTP DANE with DNSSEC for all Exchange Online customers, including MSA (hotmail, live, outlook), ensuring encrypted delivery when sending to domains that support it.
Finally, at the tail end of 2024, Microsoft enabled inbound SMTP DANE with DNSSEC across all Exchange Online tenants in a public preview. This adds transport-layer security for receiving email - something that, in my experience, still isn’t widely implemented, especially in the SMB segment.
Today, we’ll go through the requirements, limitations, and step-by-step configuration.
Let’s jump in.
Table of Contents
What is SMTP DANE with DNSSEC?
DANE and DNSSEC work together. DNSSEC is a prerequisite for DANE because DANE relies on DNS records, and those records must be protected and validated.
At a high level, they can be summarized as:
Domain Name System Security Extensions (DNSSEC):
Ensures the integrity of DNS records
Protects DNS queries using cryptographic signatures
Answers the question: Are these records authentic and untampered?
DNS-Based Authentication of Named Entities (DANE):
Enforces TLS encryption for email delivery
Publishes encryption requirements in DNS
Uses DNSSEC to validate those records
Answers the question: What encryption must be used, and how should it be verified?
Utilizing SMTP DANE with DNSSEC provides multiple benefits:
Prevents downgrade attacks:
DANE requires TLS, preventing fallback to insecure connections.
Stronger security:
Mail server identities are validated using DNSSEC, reducing impersonation risk.
Integrity and confidentiality:
With TLS, it guarantees the C & I of the CIA (Confidentiality, Integrity, Availability) with the data encrypted in transit.
Compliance:
Enhances standings and reputation of an email domain by showing compliance with different frameworks and security standards
SMTP DANE with DNSSEC is powerful, but it’s just one building block in modern email security.
If you want the full stack overview (SPF → DKIM → DMARC → MTA-STS), check out my deep dive: Modern Email Security Explained
Configuring Inbound DANE with DNSSEC in Microsoft Exchange Online
Before we jump in to the configuration, let's review the requirements and limitations.
Prerequisites
Access to your domains DNS registrar, DNS management portal
DNSSEC enabled on the domain.
If you're using a third-party DNS registrar, you'll need to ensure the provider supports DNSSEC, and enable it for the domain.
Admin privileges to Microsoft Exchange Online
Domain added as Accepted Domain in Microsoft 365
Limitations
This list is only some of the key limitations.
For the full list, you can find it HERE
onmicrosoft.com domains:
The tenant's default onmicrosoft.com domain does not currently support Inbound SMTP DANE with DNSSEC. There is currently no ETA for support.
This domain should not be used for production mail flow regardless
Third-party gateways:
If you use a third-party gateway to process mails before relaying them to Exchange Online, the feature can only be used if SMTP DANE with DNSSEC is supported on the gateway.
If outbound mail is routed through a gateway, coordinate with the provider before enabling DANE.
Configuration Steps - DNSSEC
Once prerequisites are met and DNSSEC is enabled at your registrar, we can begin the Exchange-side configuration, starting with enforcing DNSSEC.
Testing the current setup
Navigate to the official Microsoft test tool for inbound SMTP.
This initial step, ensures that our domain isn't already configured
Connectivity test showing it's using the non-dnssec enabled record: mail.protection.outlook.com Enable DNSSEC in Microsoft 365
To get DNSSEC & DANE working, we need to update the mx records.
Run the following PowerShell commands to enable DNSSEC and generate the new MX value:
Connect-ExchangeOnline
Enable-DnssecForVerifiedDomain -DomainName <your accepted domain>
Enabling DNSSEC & generating new MX Value Creating the new MX record
In your DNS registrar:
Create a new MX record
Set TTL to as low as possible, though not lower than 30 seconds
Set priority to the next level after the current MX record
Add the value generated in step 2
Verify the change
After TTL expiration, re-run the verification using the same connectivity tool as previously: Verification Tool
If everything is correct, you'll now see an additional line with the new .mx.microsoft record
Switching DNS priority
With verification that the new MX record is working as expected, we need to switch from the previous .mail.protection.outlook.com record.
Set the new .mx.microsoft record to priority 0
Lower the priority of the old .mail.protection.outlook.com record
Decreased priority on old MX record 
Increased priority on new MX record Verifying twice, cutting once
To complete the migration we need to delete the old MX record, and modify the new one a bit, but I like to double and triple check every time.
First we validate using the domain verification tool to verify the domain wide configuration, ensure you choose DNSSEC only for this initial verification.
NOTE: Before deleting the old outlook MX record, you'll be seeing a warning.
Complete migration
Delete the old record and update the TTL on the new record to 1 hour (3600 seconds).
Updated TTL to 1 hour After TTL expiration and full DNS propagation, the verification should show one record with no errors or warnings:
Configuration Steps - DANE
With DNSSEC enabled and verified on our accepted domain, we're finally at the last step - setting up SMTP DANE to enforce encryption on our inbound email traffic!
To configure DANE, follow these very long and tedious steps:
Enabling SMTP DANE via PowerShell
Run the follow cmdlet on the domain with DNSSEC enabled:
Enable-SmtpDaneInbound -DomainName <your accepted domain>
Verify the configuration
Exchange Online provisions the required TLSA records, which can take up to 30 minutes.
Once the records have been provisioned, we can validate and verify that DANE has been enabled and configured, using the same tool as previously.
NOTE: If the Microsoft tool shows errors, such as in my example, double check with another verification tool such as DANE Validator.
Optional: Configuring TLS-RPT monitoring for DANE & MTA-STS
Monitoring emails received with DANE & MTA-STS enabled, we need to enable TLS reporting, which sends delivery reports to a specified recipient email address.
To enable TLS-RPT, publish a new TXT record in our DNS registrar.
DNS record syntax:
Name: _smtp._tls
Value: v=TLSRPTv1; rua=mailto:yourtlsreportemail@yourdomain.com
Microsoft Exchange Online Upcoming Changes
Over the years, Microsoft have been moving in the right direction for both DNSSEC and DANE, and the latest announcement includes the following info, that'll change the flow for setting up SMTP DANE & DNSSEC:
July 1, 2026 – Transition provisioning of mail records for all newly created Accepted Domains into DNSSEC-enabled infrastructure underneath *.mx.microsoft
This eliminates the DNSSEC migration steps, but only for new domains created after that date.
Existing domains will still require migration.
Conclusion
Inbound SMTP DANE with DNSSEC allows Exchange Online administrators to verify and enforce encryption at the transport layer, instead of simply hoping TLS is negotiated correctly.
Once prerequisites are met, implementation is straightforward. The result is measurable improvement in mail security and stronger alignment with modern standards
Now a short, mandatory bad joke break!
I went to the zoo the other day...
There was only one dog in it!
It was a Shih Tzu 😎
Inbound DANE with DNSSEC is not a replacement for SPF, DKIM, DMARC, or MTA-STS. It strengthens transport-layer security and complements the broader email security stack.
If you haven’t enabled DNSSEC and inbound DANE yet, now is the time to raise your email security baseline.
What’s next?
In the next post, I'll release the next part in my Securing Business Premium series, in which we’ll move up the stack and explore how Microsoft Defender for Office 365 integrates with Exchange Online, and how to configure it to stop phishing, malware, and business email compromise before users ever see them.
Because email security doesn’t stop at delivery.
It starts there.