Support of DANE and DNSSEC in Office 365 Exchange Online

Published Apr 06 2020 07:00 AM 39K Views

Microsoft is committed to providing world-class email security solutions and the support for the latest Internet standards in order to provide advanced email protection for our customers. Today we are announcing that Exchange Online will be adding support for two new Internet standards specific to SMTP traffic.

These standards are DNSSEC (Domain Name System Security Extensions) and DANE for SMTP (DNS-based Authentication of Named Entities).  

Some History

The SMTP protocol was designed a long time ago, when message delivery was considered more important than security. Over time, as security and privacy became increasingly more important, several new standards emerged and one of those is RFC 3207: “SMTP Service Extension for Secure SMTP over Transport Layer Security (TLS)”. This is often referred to as Opportunistic TLS, or STARTTLS. Opportunistic TLS provides encryption for SMTP connections and even though it’s a great improvement over plain SMTP, it still has a significant number of vulnerabilities.

One such vulnerability is the downgrade attack, which is a form of man-in-the-middle-attack (MITM). This happens when an attacker is able to strip the STARTTLS verb from the target SMTP gateway during the initial in-the-clear communication, often resulting in the sending SMTP server simply deciding to continue sending the message in clear text rather than stopping transmission.

Another limitation that exists with Opportunistic TLS is the inability for the sending server to authenticate the identity of the receiving SMTP gateway. An attacker can spoof the receiving SMTP gateway’s DNS record and present an alternate MX record for a server that they own. Even if the connection is encrypted, the sending server will never know that email was diverted to the malicious server.   

Our Future

Microsoft has been working closely with partners through the industry association M3AAWG  to solve such limitations throughout the email ecosystem. As a result, we have decided to build and add support for DNSSEC and DANE for SMTP to Exchange Online. This support will be specific to SMTP traffic between SMTP gateways. We will also be providing support for TLS reporting (TLS-RPT).  

  • DANE for SMTP provides a more secure method for email transport. DANE uses the presence of DNS TLSA resource records to securely signal TLS support to ensure sending servers can successfully authenticate legitimate receiving email servers. This makes the secure connection resistant to downgrade and MITM attacks.
  • DNSSEC works by digitally signing records for DNS lookup using public key cryptography. This ensures that the received DNS records have not been tampered with and are authentic. 
  • TLS-RPT enables diagnostic reporting to support monitoring and troubleshooting of TLS connectivity issues. 

The support of the above standards, especially DNSSEC, will require investment and architecture changes to the Microsoft infrastructure - an investment we believe is necessary to enhance protection for our customers. As this will require significant work, we will be releasing DANE and DNSSEC for SMTP in two phases.

The first phase will include only outbound support (mail sent outbound from Exchange Online) and we aim to enable this by the end of the calendar year 2020. The second phase will add inbound support for Exchange Online and we plan to enable that by the end of 2021. For both of those phases, corresponding TLS-RPT support will be provided.   

While we integrate these changes, we want to ensure our customers know that there are third party solutions available for Exchange Online. Customers have the option to run their own SMTP gateways supporting DNSSEC and DANE for SMTP and they can create Outbound and Inbound connectors to route the email messages to and from Exchange Online. 

We are happy to announce support for DNSSEC and DANE for SMTP to strengthen Office 365 Exchange Online email security and provide advanced protection to our customers 

The Exchange Transport Team

Regular Visitor

To the O365 "Exchange Online" team, welcome to the DANE SMTP community, congratulations and thanks!


You'll be in good company with,,,,,,,,, ...


I hope that like Comcast et. al. you'll have the fortitude to enforce DANE policy even on the rare occasions that an occasional MX host has misconfigured TLSA records. The onus is on them to fix their settings, not everyone else to work around it.  The more large senders implement DANE validation, the less credible it will be for a misconfigured receiving system to attempt to shift blame to the sender.


There are presently around 1k (out of 10.9 million) DNSSEC-signed domains where TLSA record lookups ServFail due to broken NSEC chains or outright blocking of TLSA queries by misconfigured middle-boxes.  I'm working to get these fixed, and just this week a ~600 such domains were resolved. I expect to see a similar number again get resolved soon, well before you go live, leaving only a tiny fraction of little-known problem domains.  These too will have to fix the problems on their end.


Perhaps a prominent blog post announcing your intent to not downgrade security by glossing over problems with a tiny minority remote sites will help motivate timely remediation in advance of your deployment.  Good luck!

Occasional Visitor

This news is great! adding new standards to the O365 platform. With an ongoing move to the cloud, CSP's not introducing new standards was the limiting factor so far.


When looking at Viktor's comment it might even be wise to start TLS-RPT first to get everyone aware about their "broken" configurations before starting to apply DANE to connections. 


This leaves me with other questions though:

  • When will DMARC reporting for the O365 platform be back? back in 2012 Microsoft actively participated in the development of the standard, sending out reports from the Hotmail/ platform. These services have now migrated to the same O365 platform, but completely stopped sending out DMARC rua reports.

  • When will O365 start respecting the DMARC policy set by a domain owner? Currently a decision was made to override the reject policy (oreject) and default it back to quarantine. From an O365 Admin perspective there is no "button" to disable this behavior. Only by going through a workarounds you'll be able to get a similar result.

  • In September 2018, together with TLS Reporting (TLS-RPT), SMTP MTA Strict Transport Security (MTA-STS) was released.
    If the goal is to secure TLS connections it should not matter which technology is available (DANE vs MTA-STS), so if one is unable to implement DANE they have an alternate internet standard (MTA-STS) to make sure that their connection can be secured.

Support for MTA-STS (RFC 8461) would be a welcome addition to this announcement. This could be as simple as saying that the certificate will always match the name on the MX record ( 

Regular Visitor

My take on the situation is that the wildcard certificate is intentionally (not by accident) compatible with PKIX validation and so also inbound MTA-STS. Compatibility with a wildcard certificate is surely why the MX host names use a single-label prefix like "example-com" rather than a more natural multi-label prefix like "".

The DNS subject names in the certificate are:

Consequently, if a hosted domain wishes to publish an MTA-STS policy, it can already do so. For example, the policy for "" (with MX host is:

version: STSv1
mode: testing
mx: *
max_age: 604800
Occasional Visitor

just to confirm what @Viktor_Dukhovni mentioned, for anyone on O365 it's possible already to setup MTA-STS (as long as they keep the certificates valid).


Personally I did setup the mx as: 

mx: *

The reason behind this is that Microsoft asks for a MX publication with <domain>-<tld> from their "wizard".


The only issue at this moment is that this works when the G-Suite platform (internet, MTA-STS capable) is communicating with (to) the O365 platform, not the other way around (O365 > G-Suite).

To properly contribute to the email ecosystem internet standards need to be implemented from a sending AND receiving perspective, so both parties (Google & Microsoft and others) need to play ball. 


@Viktor_Dukhovni, @AlwindB 


Our objective is to enforce the standard without a list of exceptions. Before we enable Opportunistic DANE for SMTP, we planned to run logging-only mode first and then analyze the results of the DANE validation. Depending on the outcome, we will evaluate if it makes sense to report the failures to domain owners which can help them to correct their configuration before we start to enforce the standard. If this approach would really not work for a few exceptions, we may have to give in.

Also, we are committed to deploy MTA-STS by the end of 2020. TLS-RPT will be available for both DANE and MTA-STS.  

Regular Visitor

@Leena03 The plan you outlined is sound and addresses my concerns. Thanks, and good luck with the deployment.


@AlwindB Sending DMARC reports is in the plans. You can track the progress here:

@michaelkennedy Work on MTA-STS is well underway and final testing is being performed. 

Occasional Visitor

Is there going to be future availability of DANE / DNSSEC / MTA-STS etc with on-premise Exchange?

If so, is there a timeline for this?


@AllanWallace For MTA-STS, there is no plan at this time for the outbound validation functionality to be added to Exchange Server. That said, customers who have a hybrid routing configuration (i.e. send emails out through Exchange Online/Exchange Online Protection to the internet) will be covered by MTA-STS.

For inbound emails, there is nothing for Exchange Server (or Exchange Online for that matter) to do besides negotiate TLS so you can support MTA-STS for your domain today by hosting a policy.   

Regular Visitor

Also for on-premise exchange, inbound DANE does not require anything special in Exchange, you just need a DNSSEC-signed domain and published TLSA records matching your server certificate. New code in Exchange is only needed for verifying DANE *outbound*.


That said, inbound DANE requires monitoring, and a well thought out, automated certificate rollover process that does not periodically invalidate the published TLSA records. So while Exchange does not need new code, the "orchestration" of certificates and matching TLSA records can benefit from robust automation, and built-in monitoring.  Just "fire-and-forget" is not a good deployment model for DANE, planning and monitoring are key.  If appropriate orchestration tools were added to on-premise Exchange some day, that'd be super.

Occasional Visitor

@Leena03 @The_Exchange_Team 


I've noticed TLS-RPT reports being sent since last week (for MTA-STS). Unfortunately, these reports do not follow RFC guidelines/recommendations and even contain inconsistencies in report data, causing errors while processing. I would like to get in touch with someone from Microsoft to assist with the correction of these issues.



Occasional Visitor


More then 5000 votes and 1½ year old answer from Microsoft...

Why should you then vote if they don't care...

Senior Member

Any news regarding DNSSEC?


Regarding outbound support you aim to enable this by the end of the calendar year 2020.


What is the status for this?

Regular Visitor

DNSSEC still not available as of March 28, 2021. 

Occasional Visitor

What's the new planning for this implementation, as it looks that "end of 2020" won't be met?

Version history
Last update:
‎Apr 03 2020 08:42 AM
Updated by: