Why every organization should enable DANE
Inbound DANE is now several months available in Exchange Online and Outbound DANE has already been automatically active since years. Since a few months Azure DNS also supports DNSSEC, which is a prerequisite for DANE. For those organizations that have a full Microsoft stack, there are now no longer any showstoppers implementing DANE. And I think every organization should make this effort. Let me explain why every organization should enable DANE.
What wrong with plain old SMTP?
SMTP mailflow was never designed to be a secure way of transporting information. THE EITF improved security when they added the STARTTLS addition to SMTP. Unfortunately, organizations took years before they more broadly accepted and implemented it. Often organizations adopted only Opportunistic TLS which allows for unencrypted transport if the encryption negotiations fails. Transporting mail is more important than securing it.
You create more certainty that your mail is transported securely using Partner connections as Exchange Online calls them. These are custom connection based on the mail domain and have a more strict configuration over the default. This configuration for instance, requires a trusted certificate or even a specific server. The connection will be only transport when there is a secure connection according the configured requirements. Unfortunately this has to be setup for each domain, which takes a toll on managing these domains. Especially when certificates expire the mailflow fails. Another issue to consider are Advisary-in-the-middle (AitM) attacks. This is where malicious entities intercept transport traffic. Personally I haven’t encountered such an attack, but it is something to be aware about. Although it is more difficult, even a partner connection are not fully immune to such an attack.
Why is DANE better?
DANE solves basically all these problems. The high over principle is that the receiving org publishes their certificate info (thumbprint) in DNS records. This allows the sending org to check whether the server presents the correct certificate, eliminating AitM attacks. DNS queries are protected via DNSSEC, which creates a trust chain and alerts DNS clients when someone manipulates the information.
From a mail admins perspective DANE provides some massive benefits, provided that both mailing organization support inbound and outbound DANE. And to be fair, the adoption is not what is should be IMHO. Probably due to some technical limitations, lack of specialized knowledge and other factors. But when organizations can adopt DANE, all the configuration effort for partner connections fall away.
Replace Partner Connections with DANE
If you currently have a lot of custom Partner connections, you really should discuss adopting DANE with your counterparts. Exchange Online automatically uses Outbound DANE per default. You can focus on a single organizational configuration of your inbound mail instead of per mail domain effort. It also increases security as Partner connections do NOT protect against AitM attacks, as it lacks DNSSEC and is still vulnerable. If you rely on certificate validation, this will become more labor intensive when the validity of CA issued public certificates will be reduced to 200 days in March 2026 and 47 in March 2029!
To fully mirror the functionality of Partner Connections, Microsoft has indicated that in the near future (H2 2025?) it will be possible to force DANE connections tenant wide or to specific domains. Normally outbound traffic will first try DANE, then MTA-STS and eventually Opportunistic TLS or even unencrypted transport. If you know your partner organization does support DANE, you can force it to only use DANE and not fall back to other protocols. As there is no further configuration required (e.g. certificate validation), this is very low effort with no additional domain specific configurations required. Easy peasy!
How to implement DANE?
Now that i’ve convinced you that every organization should enable DANE, which steps do you have to take? In short for Exchange Online: Enabled DNSSEC on your domain, Enable DNSSEC on your accepted domain, change your MX record to the new value and activate DANE and you are done! There are some things to figure out in specific cases and you need to take DNS replication in consideration, but in the end it’s not that difficult.
The biggest fundamental technical requirement is DNSSEC. If your DNS registrar does not support DNSSEC, you have to switch to one that does. Even if you do not use the registrar DNS management, they are part of the DNSSEC chain of trust and the whole chain must support it (even the TLD has to have support, if it does not you cannot use DNSSEC for those domains…). Most should provide it, although some ask an extra fee.
Do you use Azure DNS?
Do you use Azure DNS as a custom name server? First enable DNSSEC in Azure DNS. You will get information for a DS record. This information is something you need to add within the configuration of your DNS registrar (e.g this is how my registrar TransIP describes it). It’s important to realize that your registrar still needs to support DNSSEC even when using your own name servers!
Take some time for DNS replication, but then follow the steps to enable Inbound DANE in Exchange Online. Early adopters and MVPs (like myself) have tested this step-by-step guide in their environment during the previews and provided feedback to Microsoft. Do take special care when you also implemented MTA-STS as you will have to change your MX record value and that can be a bit tricky.
Conclusion
You now know why SMTP has it’s issues and solutions like Partner Connections try to solve some of these, but cost quite some administration in upkeep and having to resolve issues which will only increase with shorter certificate validity times.
DANE provides less administration and more security overall. The only hard requirement is having DNSSEC enable in you whole DNS infrastructure, but that is also the biggest hurdle. For organizations that use Microsoft for everything, it’s good to know that Azure DNS also supports DNSSEC. The manuals and experience are ready for you to implement it and flip that Inbound DANE switch. Go for it!
Let me know if you run into any issues implementing DANE or have a different opinion. Leave a comment!
