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 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 

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.

About the Author

Tony Redmond

Tony Redmond has written thousands of articles about Microsoft technology since 1996. He is the lead author for the Office 365 for IT Pros eBook, the only book covering Office 365 that is updated monthly to keep pace with change in the cloud. Apart from contributing to Practical365.com, Tony also writes at Office365itpros.com to support the development of the eBook. He has been a Microsoft MVP since 2004.


  1. Jan

    David S, you can use Windows Server DNS.
    DNSSEC has been supported and working since 2012 🙂

  2. Adrian

    In your example for the register put your domain practical365.com (_25.tcp.practical365.com. IN TLSA) but the SMTP was practical365-com.mail.protection.outlook.com this works? The DNS record for SMTP would be the record domain and the value for the certificate? You know if this will work with *.domain ??

  3. Siebe

    We have several partners who require us to use DANE/DNSSEC for our Inbound email solution. We are moving away from our third party solution to Exchange Online for our inbound email in a few months. Can we expect issues with organizations unable to send messages to us.

    1. Avatar photo
      Tony Redmond

      That depends on your partner. If their mail systems are configured to insist on communicating with servers that support DANE/DNSSEC and your system does not, email mightfail.

  4. Per Søderlind

    Does this mean DNSSEC for Azure DNS is available “soon”?

    1. Avatar photo
      Tony Redmond

      No. This is an Exchange Online implementation of DNSSEC and DANE.

      1. David S.

        Pretty crappy for this new feature to be completely locked out from people using Microsoft’s OWN DNS infrastructure since they can’t be bothered to enable it after several years of people demanding support. I thought when they finally announced DNSSEC/DANE support was coming that it would be contingent up on their own offering being able to support it on the DNS side. Sad to see their shortsightedness on the issue and inability to prioritize.

  5. Eric Sherman


    Nice article, so how is Outbond DANE handled if you have a third party email gateway in front of the MS tenant. Our third party actually sends the email out for our Tenant. How is DANE TLSA handled in this case since the third party actually sends the email. I don’t have DANE setup on the third party email gateway either by the way. (which is TrendMicros)

    1. Avatar photo
      Tony Redmond

      My reading is that Exchange will route everything as normal to the third-party service and leave it to that service to decide if the target destination domain is OK.

Leave a Reply