DKIM etc cannot authenticate the email address. It can authenticate the sender domain (which is the main win anyway).

Only signed emails can be authenticated against the sender.

true, but even the domain is a really obvious signal for most of these attacks, considering most companies use their own domain for emails and it's fairly difficult to fake an email coming from that domain. So something coming from <ceo><random string of digits>@gmail.com should raise alarm bells for both automated systems and users (assuming the users can actually see it, which they now can on outlook)

Yes of course - this is why I mentioned that authenticating the domain is the main win.

Now - setting up SPF, DMARC, ... is technically easy but not so much organizationally. This is a real pain in the ass to find what various organizations used in the past in their outsourced communication (marketing, pay system, travel, ...).

The advantage that Outlook had (and has) is that it will resolve the user information from Active Directory. Receiving an email in Microsoft from "Bill Gates <[email protected]>" will yield a very unusual visual (not the right firstname/lastname sequence, no picture, ...).

During a phishing test at an old company, I was able to:

     1. buy a cheap VPS ($5)
     2. Buy a domain name with homoglyph unicode similar to the company's name
     3. get a full stack of ssl from letsencrypt for the attack domain
     4. set up postfix to use this domain with SPF/DKIM/DMARC

I then sent emails as the "CEO" and got by every spam and anti-impersonation filter. Outlook showed my emails as 100% legit in all ways. The ONLY way to tell was to go to email->properties->headers and KNOW and check the IP addresses of the servers.

Homoglyphs in Outlook desktop app are not shown as punycode. However the users who used OWA saw the punycode expansion of the domain and rightly reported them.

I thought that had been fixed, by ordering the registrars not to allow problem domains (e.g. domain must be entirely in Cyrillic+Numbers or not at all), though Wikipedia says this isn't yet the case for .com. I'm not sure if that's up-to-date though.

Pretending I work for asdf.com, I could register аsdf.com (Cyrillic а) and maybe αsdf.com (Greek α) as a precaution.

But "xn--sdf-5cd.com" and "xn--sdf-nxc.com" both show as unavailable for registration.

Something like asclf.com (all ASCII) could be mistaken in some circumstances.

I've aways wondered what on earth possesses companies to make these idiotic decisions. Take some feature that obviously works well and make a very trivial change that makes it much worse? Who sits down and decides to do this? How do they ignore the chorus of actual smart people telling them "don't do this, the domain name is important!" What possible financial ROI could they have gotten out of making such a small but terrible change? I don't understand how the checks and balances at a big, mature company like Microsoft would let something like this pass.