Introduction

Outlook can keep connecting to an old mail server after a migration even when DNS appears correct. That usually happens because Autodiscover is not driven by one setting alone. Outlook may use public DNS, internal Exchange SCP records, cached profile data, or older endpoint references that survived the cutover. The safest fix is to verify which source Outlook is actually using, then remove every remaining reference to the old server.

Symptoms

  • Outlook prompts for credentials against the previous server after migration
  • New mail profiles still try to connect to the old Exchange or mail host
  • Some users connect correctly while domain-joined office PCs do not
  • Outlook shows certificate warnings naming the old server
  • Mobile mail or webmail works, but Outlook desktop still follows the old endpoint

Common Causes

  • Public autodiscover DNS records still point to the previous mail environment
  • Internal Active Directory SCP records still advertise the old Exchange Autodiscover URL
  • Existing Outlook profiles cache old Autodiscover results or service endpoints
  • A hosts file, proxy, VPN path, or local DNS cache sends traffic to the previous server
  • The migration changed mailbox hosting, but not all Autodiscover-related records and internal references were updated together

Step-by-Step Fix

  1. Confirm which users and networks are affected, because a problem limited to domain-joined office machines usually points to internal SCP or local network state rather than public DNS alone.
  2. Check the live Autodiscover target Outlook is reaching and verify whether it resolves to the old environment, the new environment, or different answers depending on network location.
  3. Review public DNS for the domain, including the autodiscover host and any related CNAME, A, or SRV records, and make sure they match the current mail platform instead of the retired server.
  4. If users are on an internal Windows domain with Exchange history, inspect the Exchange SCP configuration in Active Directory and update or retire any Autodiscover service URL that still references the old server.
  5. Verify that the new Autodiscover endpoint presents the expected hostname and certificate, because Outlook may keep falling back or warning if the migrated endpoint does not match the names clients are told to use.
  6. Remove stale client-side state by testing with a fresh Outlook profile instead of trusting an existing one that may still cache the old mailbox service connection.
  7. Check for local overrides such as a hosts file entry, internal DNS zone, VPN resolver, proxy rule, or split-brain DNS setup that still sends autodiscover traffic toward the previous server.
  8. Retest from both an affected workstation and a clean client on another network so you can tell whether the problem is global DNS, internal directory configuration, or a machine-specific Outlook cache issue.
  9. After clients consistently resolve the new Autodiscover service, document the final DNS and internal Autodiscover settings and remove any leftover old-server references before fully decommissioning the previous mail environment.