Introduction

An IMAP timeout after a mail server move usually means the mail client is still trying to reach the wrong place, the new server is not accepting IMAP on the expected port, or network filtering is blocking the connection. Password resets rarely fix this on their own. The fastest recovery path is to verify the live IMAP endpoint, confirm the mailbox client settings match it exactly, and then check whether the new server is actually reachable from the outside.

Symptoms

  • Mail clients show connection timed out when checking IMAP after a server move
  • Webmail may still work while Outlook, Apple Mail, or mobile clients fail
  • Some devices connect, but others keep timing out
  • The problem started right after changing hosts, IP addresses, or mail providers
  • Users can send mail through SMTP or webmail, but cannot sync inbox folders over IMAP

Common Causes

  • The mail client still uses the old IMAP hostname or cached old server IP
  • DNS for the mail hostname points to the wrong server or has mixed answers during cutover
  • The client uses the wrong IMAP port or encryption mode for the new provider
  • Firewall, security group, or hosting policy blocks inbound IMAP on the new server
  • The IMAP service on the destination server is down, misbound, or not listening publicly

Step-by-Step Fix

  1. Confirm the exact IMAP hostname the mailbox should use after the move, because many outages happen when clients keep using the previous server name or a generic host that no longer points to the active mail platform.
  2. Check whether that IMAP hostname now resolves to the correct new server from live DNS, and make sure it is not still returning the old IP address or split answers from incomplete migration.
  3. Review the mail client settings on an affected device and verify the incoming server name, port, and encryption mode match the new provider's required IMAP settings exactly.
  4. Remove any manually saved old server IP, custom host override, or outdated account profile that could make the client bypass correct DNS and keep dialing the retired host.
  5. Test the mailbox from webmail or the provider's own admin portal to confirm the account itself works, which separates a client connectivity problem from a mailbox or authentication problem.
  6. Verify that the new server or mail provider is accepting IMAP from the public internet on the expected port, and check firewall rules, cloud security controls, and hosting restrictions if the connection never completes.
  7. Inspect the new server's mail service state to confirm the IMAP daemon is running, bound to the correct interface, and presenting a valid certificate for the hostname clients are using.
  8. Retest from a different network or mobile connection if timeouts persist, because office firewalls, ISP filtering, or endpoint security can block IMAP even when the new server is correctly configured.
  9. After access is restored, update all devices and migration runbooks with the final IMAP hostname, ports, and cutover timing so future mail moves do not leave clients pointed at the old endpoint.