When asked early Friday afternoon why Microsoft was doing this, a representative had no answer and asked for more time. By Monday morning, the improper routing was no longer occurring, but the representative still had no answer.
The new JSON response suggested that as of Monday morning Microsoft hadn’t actually fixed the configuration routing traffic to the Sumitomo Electric servers. Instead, the JSON response no longer occurs. Where the output was occurring on Friday, the command simply sits and hangs for 10 or 20 seconds and then terminates with a not found error. This behavior can be seen in the following output:
> GET /autodetect/detect?app=outlookdesktopBasic HTTP/2 > Host: prod.autodetect.outlook.cloud.microsoft > Authorization: Basic ZW1haWxAZXhhbXBsZS5jb206cGFzc3dvcmQ= > User-Agent: curl/8.14.1 > Accept: */* > * Request completely sent off * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): < HTTP/2 204 < date: Mon, 26 Jan 2026 18:23:55 GMT < server: Kestrel < strict-transport-security: max-age=2592000 < x-olm-source-endpoint: /detect < x-provider-id: Unknown < x-debug-support: eyJkZWNpc2lvbiI6ImF1dG9EdjIgPiBhdXRvRHYxID4gZml4ZWQgZGIgcHJvdmlkZXIgPiBmaXhlZCBkYiBkb21haW4gcHJvdG9jb2xzID4gZGIgcHJvdmlkZXIgPiBkYiBkb21haW4gcHJvdG9jb2xzIiwiYXV0b0QiOnsidjIiOm51bGwsInYxIjpudWxsfSwiZGIiOnsicHJvdmlkZXIiOm51bGwsImRvbWFpbiI6eyJmaXhlZCI6ZmFsc2UsImF1dG9EdjJFbmRwb2ludCI6bnVsbCwicHJvdmlkZXJJZCI6bnVsbCwicHJvdG9jb2xzIjpudWxsfX19 < x-autodv2-error: ENOTFOUND
“It looks like they may have outright removed the endpoint that validates the email, because I’m seeing ‘not found’ errors,” said Dan Tentler, founder of Phobos Group. As denoted by ENOTFOUND, the error “suggests that [Microsoft admins] “just ripped out whatever this thing was.”
It’s not clear how Sumitomo Electric’s domain would have found itself part of this SNAFU. Microsoft last year said the Japanese company’s parent company, Sumitomo Corp., was deploying Microsoft 365 Copilot, but that still doesn’t explain why a subsidiary’s domain got added to Microsoft’s network configuration.
Questions sent to Microsoft include: how are autodiscover records added at Microsoft, was the routing intentional, and how long has the behavior been occurring? (tinyapps.org, which noted the odd routing behavior earlier this month, said it lasted five years.) There doesn’t appear to be anything nefarious about the improper routing, and as long as people inside Microsoft’s network weren’t sending live credentials in tests, there was no danger posed.
There’s still reason for concern. In 2024 Microsoft revealed that one of its admins had assigned administrative privileges to a test account on the company network and then forgot about it. Russia-state hackers seized on the gaffe to gain initial access into Microsoft’s system. They went on to root through the network and monitor top executives’ email for two months. The routing misconfiguration for example.com raises the question: What other possibly more severe errors lurk on the network?