Introduction

A mailbox migration can finish successfully while new mail clients still auto-configure against the old server. This is usually not a mailbox outage. It is a profile discovery problem. Thunderbird, Apple Mail, mobile clients, and other setup flows may still be reading old autoconfig or autodiscover data, following stale redirects, or using cached setup profiles created before the cutover. Start by proving which discovery endpoint the client is actually using, then update that path instead of troubleshooting the mailbox blindly.

Symptoms

  • New mail setups keep suggesting the old incoming or outgoing server after migration
  • Thunderbird, Apple Mail, or mobile devices auto-fill outdated hostnames
  • Manual settings work, but automatic setup keeps failing or using the old server
  • Some users get the new settings while others still receive the old ones
  • The mailbox works in webmail, but fresh client setup keeps targeting the previous host
  • The problem started right after DNS cutover, provider migration, or mail platform change

Common Causes

  • The domain still serves old autoconfig or autodiscover XML data
  • DNS for autoconfig, autodiscover, mail, or webmail hostnames is still stale in some resolvers
  • Setup endpoints redirect to the old provider or old control panel host
  • Client devices are reusing cached setup profiles or previously discovered settings
  • A CDN or proxy is caching setup responses that should have changed during migration
  • The migration updated mail flow but not the client discovery layer

Step-by-Step Fix

  1. Confirm that manual mail settings for the new server work first, because that proves the mailbox itself is healthy and keeps the troubleshooting focused on discovery rather than basic mail access.
  2. Identify which setup method the failing client is using, such as Thunderbird autoconfig, Apple Mail profile discovery, mobile autodiscover-style lookup, or a provider-hosted XML profile, because different clients read different endpoints.
  3. Check the live responses from your autoconfig and autodiscover-related hostnames and files, because those endpoints often keep serving old server names even after the actual mailbox migration is complete.
  4. Verify DNS for all setup-related hostnames including autoconfig, autodiscover, mail, and webmail, because stale records in one part of the discovery chain can keep clients pointed at the old platform.
  5. Review HTTP redirects and hosting configuration for the discovery endpoints, because migrations often move the mailbox but leave the old redirect path or control panel-generated setup file in place.
  6. Test from more than one network or resolver if behavior differs by user, because some clients are reading fresh DNS while others are still seeing cached discovery data.
  7. Clear cached profiles, saved server suggestions, and remembered account settings on the affected client before retrying, because many mail apps silently reuse old setup data and make it look like the server is still wrong.
  8. Check whether a proxy, CDN, or caching layer is sitting in front of the discovery endpoint, because cached XML or cached redirects can preserve the old server details long after DNS was updated.
  9. Once the discovery path returns the correct hostnames consistently, test a brand-new mail profile on an unaffected device and document which endpoint the client now uses, because that confirms the fix is real and not just masked by one cleaned-up profile.