For more updates on the subject, please see Announcing General Availability of Inbound SMTP DANE with DNSSEC for Exchange Online.
As previously announced, in July 2024 Microsoft is releasing a Public Preview for Inbound SMTP DANE with DNSSEC for Exchange Online mail flow. This will complete Exchange Online’s support for SMTP DANE with DNSSEC, as outbound SMTP DANE with DNSSEC has been supported since March 2022.
SMTP DANE is a security protocol that uses DNS to verify the authenticity of the certificates used for securing email communication with TLS and protecting against TLS downgrade attacks. DNSSEC is a set of extensions to DNS that provides cryptographic verification of DNS records, preventing DNS spoofing and adversary-in-the-middle attacks to DNS.
To support inbound SMTP DANE with DNSSEC, we built new DNS infrastructure for Exchange Online that will be secured by DNSSEC. This new architecture will impact legacy Exchange Online DNS infrastructure, specifically the domain mail.protection.outlook.com which is the domain that hosts current customers’ A records for mail flow to Exchange Online. Because DNS is a backend service that is often considered ‘set-it and forget-it’, we wanted to bring this to the attention of the email community at large so everyone has advanced notice prior to the Public Preview in July 2024. If you are an email admin, or a 3rd party organization that resells Microsoft 365 or integrates with Exchange Online for mail flow purposes, you should review this post to understand if you have any action items to take before the feature releases.
How will we release SMTP DANE with DNSSEC?
The initial support for inbound SMTP DANE with DNSSEC will come in 2 waves:
- July 2024: opt-in Public Preview. For Accepted Domains provisioned in mail.protection.outlook.com, customers will be able to use Exchange PowerShell for enabling SMTP DANE on an Accepted Domain and will be able to migrate existing domains into the new DNSSEC-enabled zones.
- July 2025: post General Availability (GA), layering DNSSEC into Exchange Online for inbound mail flow. In July 2025, we will gradually switch provisioning of all A records for new Accepted Domains into the new subdomains under mx.microsoft.
This change spans the provisioning of Mail Exchange (MX) records and Address (A) records for mail flow of Accepted Domains known as vanity domains, and specifically the zones where Microsoft will provision future A records. The key change is the introduction of the subdomains <subdomain>.mx.microsoft, which will replace mail.protection.outlook.com for hosting the A records of future Accepted Domains. We must use many subdomains instead of 1 jumbo domain due to scale limitations with DNSSEC.
Current State: Today, when an Accepted Domain is created, Exchange Online provisions an A record in mail.protection.outlook.com and the admin configures an MX record that references that A record. For these records, nothing changes. For example, if an admin adds Contoso.com as an Accepted Domain before April 2025, the Microsoft 365 Admin Center will show this:
The Change: Starting April 2025, a portion of new A records will be provisioned in one of many subdomains under the domain mx.microsoft. This will be a gradual increase between April and July 2025, with the goal of 100% of Accepted Domains being provisioned in the subdomains under mx.microsoft by July 2025. The tenant admin must configure an MX record that references the correct A record in its specific subdomain. This is the only change to the admin experience when manually configuring Accepted Domains the first time. For Accepted Domains created before April 2025, Exchange PowerShell cmdlets will be released as part of our Inbound SMTP DANE with DNSSEC Public Preview and would be used for migrating DNS records into the DNSSEC-secured domains. A DNSSEC-enablement wizard will be released in CY25 to ease the experience.
Continuing with the Contoso.com example, if the Contoso.com admin adds Fabrikam.com as an Accepted Domain (not as the onmicrosoft.com domain for the tenant) after April 2025, the Microsoft 365 admin center could show this:
As the ‘1j2b’ portion of the domain name is randomly assigned, this change introduces some ambiguity with auto-provisioning of MX records and will pose a problem for those who use automation to auto-provision MX records that reference A records in mail.protection.outlook.com. Resellers and customers using automation to create MX DNS records cannot rely on A records always being provisioned in mail.protection.outlook.com starting April 2025.
Doing this will layer DNSSEC into mail flow for the service, and we are giving away DNSSEC due to the significant security benefits. While mail.protection.outlook.com will remain operational indefinitely, we will stop provisioning future Accepted Domain A records to this domain and it will not receive any new DNS enhancements such as SMTP DANE with DNSSEC. Starting in July 2024 as part of the Public Preview, customers will be able to use the Microsoft 365 Admin Center and/or Exchange PowerShell to migrate their mail flow DNS records out of mail.protection.outlook.com and into the new subdomains under mx.microsoft in order to enable DNSSEC for a particular Accepted Domain then enable SMTP DANE on that DNSSEC-enabled Accepted Domain.
What does this mean for you?
As a result of the changes outlined above, there may be some things you may need to consider:
- Hard coding of mail.protection.outlook.com in MX lookups, retries, validations, or fallback mechanisms cannot be relied upon starting in July 2024 when the new mx.microsoft subdomains are introduced and customers adopt them as part of the SMTP DANE with DNSSEC Public Preview. If you need to obtain information about an Accepted Domain’s MX record configuration, use the List serviceConfigurationRecords Graph API instead.
- Any auto-provisioning of MX records upon initial setup must stop referencing A records in mail.protection.outlook.com by April 2025. Auto-provisioning of MX records must migrate to using the List serviceConfigurationRecords Graph API to retrieve the “mailExchange” field, which will be only source of truth for providing the correct domain suffix information needed to properly configure the MX record. Making this change prevents significant issues that could arise with mail flow for future tenants if no action is taken. If provisioning is not modified, starting April 2025, the A record will be created in the mx.microsoft zone but the MX record could point to the wrong zone (mail.protection.outlook.com) and mail flow will not work.
- Per standard operating procedure, we will be updating our product documentation and the list of IPs/URLs that organizations sending to Microsoft need to include as ‘Allowed’ in Access Control Lists. Email service providers, admins, or other entities sending to Exchange Online should ensure they are tracking the IP/URL page Office 365 URLs and IP address ranges - Microsoft 365 Enterprise | Microsoft Learn and making the necessary changes to their network and firewall settings.
Limitations
As we get closer to supporting Inbound SMTP DANE with DNSSEC, we have identified some scenarios that will not initially be supported:
- Domains purchased from Microsoft known as Viral or self-service sign-up domains: domains that were purchased from Microsoft and set up as self-service will not get support for Inbound SMTP DANE with DNSSEC as part of the public preview. We do intend to support Inbound SMTP DANE with DNSSEC for these domains but the ETA is unknown, we are tentatively aiming for H2CY24.
- onmicrosoft.com domains: the ‘onmicrosoft.com’ domain for the tenant will not get support for Inbound SMTP DANE with DNSSEC as part of the public preview. We are investigating supporting Inbound SMTP DANE with DNSSEC for the onmicrosoft.com domains but the ETA is unknown.
- 3rd party gateways: customers using a 3rd party email gateway on the inbound path that accepts mail for the tenant, does some processing, then relays it to Exchange Online will need to follow a different enablement process and may need to work with their 3rd party service provider to ensure successful configuration. This feature can be used by this set of customers, but it will only secure the traffic from the 3rd party gateway to Exchange Online and only if the 3rd party gateway supports outbound SMTP DANE with DNSSEC validation as they would be doing the SMTP DANE and DNSSEC validations against Exchange Online. If the 3rd party does not support outbound SMTP DANE with DNSSEC, the flow will still work but there will be no additional security benefits whatsoever until the 3rd party does support the protocol. The DNSSEC-enablement wizard in the Microsoft 365 admin center will not support setting up this configuration; customers using 3rd party email gateways would need to set up inbound SMTP DANE with DNSSEC using Exchange PowerShell and documentation we will provide.
- Fully Delegated domains: domains that are hosted by Microsoft and use NS delegation so that Microsoft’s name servers are authoritative for the domain, will not get support for Inbound SMTP DANE with DNSSEC as part of the public preview. We do intend to support Inbound SMTP DANE with DNSSEC for these domains and we are tentatively aiming for second half of CY25.
- New limitations may be added to the list.
Feedback
We value your feedback and want to hear from you if you have concerns or dependencies that we may have not addressed. Please comment on this post if you have any feedback or concerns and we will reach out to you directly as needed.
We understand that change can be difficult, but in this case, it's required to ensure the continued smooth operation of mail flow in Exchange Online. We appreciate your cooperation and support as we work to enhance the security and reliability of email delivery for Microsoft 365.
Microsoft 365 Messaging Team
