Introduction

A mailbox migration can move users successfully while Outlook setup still discovers the old server through an Autodiscover SRV record. MX and normal mailbox access may already be correct, but account setup, profile recreation, or some clients still follow the SRV target and end up on legacy infrastructure.

Treat this as a service-discovery problem instead of a general mailbox-access problem. Start by checking whether the domain still publishes an Autodiscover SRV record and where that record sends clients now, because one stale SRV target can override the migration path you expected.

Symptoms

  • New Outlook profiles still discover the old server after migration
  • Account setup keeps redirecting users to the previous mail platform
  • Existing clients may work, but profile recreation fails or points to legacy infrastructure
  • The issue appears during Autodiscover or first-time account setup
  • DNS for MX looks correct, but client discovery still behaves as if the old server is live
  • The problem started after mailbox migration, Exchange cutover, or provider change

Common Causes

  • The Autodiscover SRV record still targets the old server
  • The SRV target hostname resolves to legacy infrastructure
  • Related Autodiscover records were updated unevenly, leaving one discovery path behind
  • The migration validated mailbox access but not the SRV-based setup path
  • Some clients still prefer the published SRV path during discovery
  • The old mail platform remains reachable, so the stale SRV record was not exposed immediately

Step-by-Step Fix

  1. Query the domain for any Autodiscover SRV record and identify its current target host and port, because you need the live discovery path before changing client-side settings.
  2. Check whether the SRV target hostname resolves to the intended new platform, because correcting the SRV record alone is not enough if the target host still points to the old server.
  3. Compare the SRV record with any autodiscover A, CNAME, or redirect-based discovery path for the same domain, because mixed discovery records can make one client look fixed while another still follows the legacy route.
  4. Test account setup with a new Outlook profile after confirming the published records, because existing profiles can hide SRV-related discovery failures that only appear during fresh setup.
  5. Remove or update the stale SRV target so it matches the current mail platform, because mailbox migration does not automatically retire an outdated discovery record.
  6. Verify whether the old server is still answering Autodiscover-related requests, because a reachable legacy endpoint can keep the wrong discovery path looking functional during the transition.
  7. Retest from more than one resolver or network after the DNS update, because cached SRV responses can make the old target appear to persist longer than the authoritative zone says it should.
  8. Compare one domain that sets up correctly and one that still fails if you manage multiple mail domains, because differences in SRV and related host records usually reveal the missed migration step.
  9. Document the final Autodiscover discovery method for the domain after recovery, because stale SRV records are easy to miss during future mailbox migrations.