BrianBaldock apologies for the belated thanks; Ed Fisher's article is useful as are the associated links. I'd worked out the local breakout/DNS recommendations (the hard way), as noted previously. However, the article is o365-oriented and doesn't appear to address MDE; I'll see if further digging turns up more on that.
The core problem is not that it's difficult to allow MDE endpoints (or any other o365/Azure client) access to MS's services - direct, always-available outbound permit rules are trivial to apply. The problem is that once these rules are in place at the network level, it's non-trivial to prevent them from being misused by other software running on the endpoint.
IMHO it's remiss of MS to insist on customers adopting an open skies policy but not to provide a technical solution (a proxy would be ideal) to implement some specific controls the way MS itself recommends - especially having acknowledged that it's a "challenge" for many.
BTW via my Case, MS Support have stated:
- Regarding this particular URL - https://login.microsoftonline.com/ it was redirecting to the https://www.office.com/ and this particular URL is not present in the MDE URL's list
- As you said, it is a documentation issue, and for this, we need to escalate this to the development team so that they will make changes in the document from the backend.
I'm surprised to be the first to notice this.