If you know you want to email [email protected] and if you trust DNSSEC, then fetching the public key for [email protected] from the DNS should be at least as secure as visiting https://example.dk in your browser.

(If you don't trust that Alice's email address is [email protected] then you shouldn't send an email for her to that address regardless of MitM attacks.)

> ... and if you trust DNSSEC...

I don't, thanks.

You're omitting the part that example.dk could create a fake key for [email protected], publish that, decrypt a copy for themselves, and reencrypt it for [email protected]'s public key.

Well, I said it's at least as secure as visiting https://example.dk in your browser, where your attack is equivalent to the hosting company or DNS provider generating a new TLS certificate for that domain without the knowledge of Alice, the nominal registrant. (The web PKI also has the problem that any CA can issue a certificate for any domain).

The catch is that the primary reason to choose encrypted email is to prevent your hosting email provider from reading your email, so the inability of encrypted email to provide that guarantee kind of renders it worthless.

Of all the attackers you could worry about, I wouldn't put your own email hosting provider at the top of the list. MTA-STS is nice, but it's hard for an email client to guarantee that the hop-to-hop links between itself and the recipient's inbox are going to be protected with TLS. Passive snoops between mail providers seem like a much more realistic threat.

Also, by putting a public key in the public DNS, it means that Alice can catch her mail provider's DNS server giving false information about her public key, which would come with cryptographically signed proof of which entities were involved in that lie. Ideally there would be an equivalent to the Certificate Transparency system for keys that are used or protected by DNSSEC.