Exchange Online Introduces DANE and DNSSEC for Outbound Email

Long Time Waiting but Update Will Roll Out in Mid-January

Updated: February 3, 2022

In April 2020, the Exchange development group declared their intention to introduce DANE and DNSSEC for Exchange Online. At that point, Microsoft said that they would add outbound support by the end of 2020 and inbound support by the end of 2021. A subsequent update from the Ignite conference in September 2020 said nothing to indicate that things weren’t progressing as planned.

Almost twenty-one months after the original April 2020 announcement, Microsoft published message center notification MC308285 on December 24, to say that a slow roll-out of DANE and DNSSEC for outbound email will start in mid-January 2022 and complete by late May.

DANE and DNSSEC

DANE is the DNS Authentication of Named Entities (defined in RFC7672). DNSSEC is the Domain Name System Security Extensions (defined in RFC4033). Together, these standards address some fundamental security weaknesses in how servers exchange SMTP messages. DANE uses DNS TLSA resource records to signal the TLS protocol supported by servers to allow sending servers to authenticate legitimate receiving email servers.

Here’s an example of what a TLSA record might look like for the practical365.com domain.

_25.tcp.practical365.com. IN TLSA 3 1 1 
e1c362c8c03a15023fff83831a70d6fce33203d499a3f3d0b13243a1ac689088

When a mail server which support DANE wishes to send email, it performs a DNS query against the recipient domain to see if the TLSA DNS record exists. If the record exists, the sending mail server initiates mail transfer to the recipient mail server using the TLS protocol defined in the TLSA record. While the initial unencrypted handshake with the remote server persists, the existence of a TLSA record means that Exchange Online can be confident that it sends email to the right domain because the certificate provided by the target server matches what’s in DNS.

DNSSEC works by digitally signing the TLSA records in DNS using public key cryptography. Servers which use the DNS MX records to find the connection point for email for a domain can validate records to assure that they are authentic, and an attacker has not tampered with the records to divert mail flow elsewhere.

The initial support is for outbound connections. This means that when Exchange Online connects to external SMTP servers to send email, it uses DANE and DNSSEC validation to ensure that the connection is secure. If the checks fail against the recipient domain, Exchange Online does not trust the recipient domain, and therefore refuses to connect to the remote server to send email. The checks happen automatically, and tenant administrators need to do nothing to enable outbound validation.

According to the Microsoft 365 roadmap, inbound support for DANE in Exchange Online will come in December 2022.

Failed Server Validations

It’s possible that a target domain is misconfigured or compromised. If this happens, the validation fails. Neither the administrator of the sending tenant nor Microsoft Support can do anything to restore mail flow to the target domain. Someone with administrative control over that domain must resolve the problem by fixing any misconfiguration or securing it from compromise. All you can do is make contact (but not using email sent from Exchange Online) with the recipient domain to tell them that something is causing Exchange Online to reject connections to send email. Hopefully, they’ll pay attention and rectify the problem to re-establish mail flow.

Target domain owners have the option to receive reports from senders to monitor if DANE is passing or failing. The TLS reporting (TLS-RPT) standard is a feedback mechanism to give insight into what senders experience when trying to send you mail. Errors could point to a misconfiguration or active DNS-based attack.

According to Microsoft, analysis of connections reveals that only 0.00023% of all domains Exchange Online sends email to are misconfigured or potentially compromised. It sounds like the implementation of DANE and DNSEC might affect a small percentage of traffic, especially as it’s likely that the problematic domains receive a small volume of email traffic from Exchange Online. However, given the massive volume of email processed by Exchange Online, blocking mail flow to these domains will generate an increased number of non-delivery notifications (NDRs) received by Exchange Online mailboxes. Hopefully, the problem domains will realize that their inbound mail traffic has dropped off for some reason and will investigate and fix the issue.

Apart from interpreting the information included in NDRs, Microsoft updated the Microsoft Remote Connectivity Analyzer (RCA) tool to perform DANE and DNSSEC tests against target domains. Administrators can also see when messages fail against domains using the Exchange message trace utility. Microsoft says that they plan to publish details of the validation steps performed by Exchange Online together with links to additional troubleshooting information (such as a report about DANE/DNSSEC available in the Exchange admin center) in a message center notification before the update rolls out.

Why So Long?

Some will be critical that Microsoft missed their original date for outbound support for DANE and DNSSEC by a year and wonder when inbound support will be available. I think several factors are at play here, including:

• The sheer size of the Exchange Online infrastructure and the number of servers involved.
• The need to run tests to analyze the impact of implementing DANE and DNSSEC for Exchange Online against recipient domains worldwide. In a comment to the original post, Microsoft indicated that they planned to implement in log-only mode first and validate the results before proceeding to deployment. As often happens in engineering projects, this process might have taken longer than expected.
• Following their analysis, Microsoft took actions to ameliorate potential side effects for Exchange Online and tenants. The last thing Microsoft wants is to see a flood of support issues logged with Microsoft support. Tooling, development, and documentation all take time.

I can appreciate why Microsoft is cautious when it makes changes to important parts of the Office 365 infrastructure and it’s not unusual for developments to be slower than anticipated. Support for MTA-STS (Strict Transport Security), highlighted in the transport update from Ignite 2020 appears to be in the same category. According to Microsoft 365 roadmap item 67177, MTA-STS reached General Availability in April; 2021. In reality that point wasn’t reached until February 2, 2022 when they announced support for MTA-STS in Exchange Online.

No On-Premises Implementation

In a comment for the original post, Microsoft says that they have no plans to introduce support for DANE and DNSSEC in Exchange Server. However, if you use a hybrid deployment and route email through Exchange Online, email originating from on-premises mailboxes will gain the benefit of the new capabilities.

Extra Security is Always Welcome

Any change which increases security without needing tenant administrator intervention is welcome. Given the amount of testing and preparation, the roll-out of DANE and DNSSEC will hopefully go smoothly, and no one will discover that Exchange Online refuses to communicate with an important domain for their business. And if you see a flood of NDRs come in from a domain because of failed validations, remember that it’s not your problem… Go shout at the administrators of that domain.