I run an authorization service that allows to log-in using magic links and we managed to solve this. First approach was for the link opening GET request to do not log the user in, but to include an HTML page with JavaScript that issued a POST request with a code from the link to log the user in. This worked well for a long time, because email scanners were fetching links from emails with GET requests but did not execute JavaScript on the fetched pages. Unfortunately, some time ago Microsoft tools indeed started to render the fetched pages and execute JavaScript on them which broke the links. What works now is to check if the link is open in the same browser that requested the link (you can use a cookie to do it) and only automatically login the user in these cases. If a link is open in a different browser, show an additional button ('Login as <email address>') that the user needs to click to finish the login action. MS tools render the login page but do not click buttons on it.
The issue that MS tools introduced is broader, because it affects also email confirmation flows during signups. This is less visible, because usually the scanners will confirm emails that the user would like to confirm anyway. But without additional protection steps, the users can be signed up for services that they didn't request and MS tools will automatically confirm such signups.
The issue that MS tools introduced is broader, because it affects also email confirmation flows during signups. This is less visible, because usually the scanners will confirm emails that the user would like to confirm anyway. But without additional protection steps, the users can be signed up for services that they didn't request and MS tools will automatically confirm such signups.