Introduction

A mailbox migration can finish successfully while an existing mail client profile keeps talking to the old IMAP or SMTP server. Webmail may already work and a newly configured device may already use the right provider, but Outlook, Thunderbird, Apple Mail, or another existing profile still holds older server names, older outgoing-server definitions, or old trust settings that survived the migration.

Treat this as a stored client-profile problem instead of a general mail-platform outage. Start by checking the live account settings inside the failing profile, because migrated mail systems often work correctly while only the reused client configuration still points at the previous server.

Symptoms

  • The mailbox works in webmail, but an existing mail client still connects to the old server
  • Sending or receiving fails only on devices that were configured before the migration
  • New profiles work, but older profiles still show the previous IMAP or SMTP hostname
  • Incoming mail, outgoing mail, or both still follow legacy settings after cutover
  • Certificate warnings or authentication prompts still reference the old mail server
  • The issue started after provider migration, server move, or mail-hostname change

Common Causes

  • The client profile still stores the old IMAP, POP, or SMTP hostname
  • The outgoing server profile is separate and was never updated during the migration
  • A saved certificate trust decision or cached account state keeps the client tied to the old server identity
  • The migration updated DNS and discovery paths, but existing profiles do not reconfigure themselves automatically
  • The account was migrated, but the client kept reusing a legacy send-only or receive-only server profile
  • Testing focused on new device setup while existing client profiles were never rebuilt

Step-by-Step Fix

  1. Open the failing mail client profile and record the exact incoming and outgoing server settings it is using, because you need to confirm whether the client is still targeting the old platform or failing for another reason.
  2. Compare the stored IMAP, POP, and SMTP hostnames with the intended post-migration settings, because many clients keep separate incoming and outgoing definitions that do not update together.
  3. Check whether the profile uses a separate outgoing server object, saved send connector, or legacy account preset, because mail clients often keep one hidden SMTP profile tied to the old environment.
  4. Confirm the mailbox works from webmail or a newly built client profile first, because that isolates the issue to the stored client configuration rather than the migrated mailbox itself.
  5. Review any certificate warnings, remembered trust prompts, or saved credentials shown by the client, because those clues often expose that the profile still expects the old server identity.
  6. Update the profile settings only after you confirm the correct new server names and ports, because repeated password resets do not fix a client that still talks to the wrong host.
  7. If the profile remains unstable, rebuild it from scratch and test again, because some mail clients preserve too much legacy state to recover cleanly through partial edits.
  8. Compare one fixed client with one still-failing older client, because differences in profile age or outgoing-server reuse usually explain why the issue is inconsistent across devices.
  9. Document the final incoming and outgoing settings, plus whether a full profile rebuild was required, because existing client profiles are one of the most common leftovers after mail migration.