The biggest step forward in email security is happening (right now) soon!

When you send email today on the Internet, your email is usually automatically and transparently encrypted when in transit, meaning the contents are protected from attackers in such a way they cannot read or manipulate the contents of the email.

However attackers may be able to block the email from reaching the recipient. Attackers may also spoof you, which is to send email to others that look like it came from you. Attackers may also be able to make a copy of your encrypted email while in transit, and then try to crack the encryption in order to read the contents at some point in the future.

The encryption in use for email transmission is what we call opportunistic unauthenticated encryption. In normal language: "send the email using encryption if available, and we do not care at all who the recipient party claim to be or who they might represent."

It is like putting your secret love letter in a closed envelope, hand it over to the first person you see and trust them 100% to deliver it for you to the correct recipient, without reading or changing the contents.

DNSSEC + DANE are two Internet standards developed for radically improving security while sending emails on the internet. Completely transparent for you as an end user, you don't need to do anything new or different.

One weakness we still have today is that it is not "us" who sends our email on the Internet, it is Microsoft. Other organisations may use Google or a plethora of other options available out there. Or simply operate their own mail servers for maximum control. Because of this we need to tell the internet that Microsoft is allowed to send and receive email on our behalf as our service provider.

<tech talk>

DNSSEC adds digital signatures to our information in DNS, verified by "the internet". By publishing the public key from our SSL/TLS certificate used by our (Microsoft) mailserver as a DANE TLSA record in our DNS, we tell mailservers on the Internet "Hey, here is the public key for our mailserver that you MUST use to encrypt email when sending to us. If you see another certificate or no certificate at all when connecting to our mailserver, do not use that (fake?) certificate and do not send any email in plaintext. The information in our DNS is signed by the internet, so you can be assured you haven't got the wrong information when requesting it from our nameserver." This way we are moving away from unauthenticated opportunistic encryption to mandatory authenticated encryption. That is a MASSIVE move for email security going forward!

</tech talk>

Microsoft announced several years ago that they wanted to implement DNSSEC + DANE in a two-step process:

1) Outbound DNSSEC + DANE support (implemented during summer 2022)

2) Inbound DNSSEC + DANE support (ETA July - December 2024)

In order to really benefit from this, a few things may be needed. First and foremost your domain names used for email must be signed using DNSSEC. Depending on the country and line of business, you can assume 20-60% of domains have this in place already.

A lot more information for those of you operating DNS and/or Microsoft/mail services can be found here from Microsoft: Implementing Inbound SMTP DANE with DNSSEC for Exchange Online Mail Flow - Microsoft Community Hub

Unfortunately there are limitations to this as well, one of them being Microsoft having said earlier that DNSSEC + DANE will only be able for customers on enterprise E5 subscriptions.

The Dutch government, as well as many others, have expressed written concern about this directly to Microsoft (PDF). At the moment we are waiting to see what Microsoft decide to do.

Security should never be a paid add-on option to basic systems used by everyone. As more organisations becomes part of the solution, the less of a security problem we'll have with email security. Which benefits everyone.

As a proof that nagging & persistence works, I like to personally brag a little with this screenshot of a simple "conversation" I had with the CEO of Cloudflare, on Twitter, and a response from Viktor Dukhovni, security developer on Postfix: