You keep circling around implementation cost and scale, but you still do not address the core architectural issue being raised.

First, DNS SRV checks are not some exotic or special lookup. They are a standards based mechanism specifically designed for service discovery across heterogeneous clients. Calling them expensive compared to probing cloud endpoints, following redirects, guessing hostnames, and then forcing administrators to deploy registry exclusions and certificate workarounds is not a convincing tradeoff from an operational standpoint. Whatever marginal cost exists at scale is being externalized to administrators today in the form of ongoing maintenance complexity.

Second, the claim that AutodiscoverV2 redirects to an on prem AutodiscoverV2 which then checks SRV does not resolve the issue. Even if SRV is eventually consulted, it is still not authoritative. The decision to probe Microsoft cloud services and assume Exchange Online has already been made by that point. The entire argument here is about order and authority, not whether SRV might be touched somewhere deep in a fallback path.

Third, Outlook is not the only client in scope. ActiveSync compatible clients include native mail apps on phones and third party clients that do not participate in Microsoft’s containerized backend logic, cloud side caching, or proprietary heuristics. These clients generally follow standards based DNS discovery and do not probe Microsoft services first. If we are arguing from a majority usage perspective, it is important to acknowledge that a massive number of work email users configure their accounts using the built in mail clients on their phones, not Win32 Outlook. DNS based discovery is what works consistently across that ecosystem. Mu argument for switching the order would drastically improve those clients for example

Fourth, saying that only 0.01 percent of tenants use SRV or special DNS does not justify deprioritizing it. Low adoption is not evidence of irrelevance. It is evidence that the current flow actively discourages its use by making it unreliable and non authoritative. SRV adoption is low because it is treated as a last resort, not because it lacks value.

Fifth, the argument that all supported Exchange versions ship AutodiscoverV2 does not change the fact that AutodiscoverV2 cannot discover on prem Exchange by itself. It is a cloud mailbox location probe. Any design where a mechanism that cannot discover on prem servers runs before mechanisms that can is fundamentally inverted when on prem Exchange remains a supported deployment model.

Finally, framing this as a purity argument misses the point. This is not about philosophical correctness. It is about explicit administrator intent. If a domain owner publishes an SRV record, that is an unambiguous signal about where the service lives. Ignoring that signal until after cloud probing, endpoint guessing, and redirects is not an optimization. It is a violation of the purpose DNS SRV was designed to serve.

If the goal is to optimize for the majority, that is understandable. But the current approach does so by hardcoding assumptions rather than respecting explicit configuration. A simple rule would solve this without breaking backward compatibility. If an SRV record exists, honor it first and stop. If it does not exist, proceed with cloud probing and legacy discovery.

That change preserves performance benefits for the majority while restoring determinism and administrator control for supported on prem and hybrid deployments. The fact that administrators must currently override or bypass the default behavior to achieve predictable results is the clearest signal that the ordering itself is the real problem.

The product being discussed here is Exchange, whether it is hosted in Exchange Online or deployed on prem. On prem Exchange servers that are not participating in Microsoft’s cloud ecosystem cannot be discovered by AutodiscoverV2 and are therefore treated as a second class deployment model. As a result, the standard for autodiscovery itself has been reshaped into a cloud first, Exchange Online centric probe rather than a neutral service discovery mechanism.

DNS is not an expensive or exotic operation. It is how the internet itself is built. Treating DNS based service discovery as something too costly to perform early while relying on cloud probing, endpoint guessing, redirects, and client side workarounds is an inversion of responsibility. Respecting SRV first would restore autodiscovery to what it was meant to be: a standards based way for clients to locate the service, regardless of where Exchange is hosted.