Introduction

An Exim queue that starts growing after a server migration usually means the new server is accepting mail locally but cannot hand it off successfully. That handoff can fail because the queue runner is not processing mail, outbound SMTP is blocked, the server identity changed, or the migrated relay configuration no longer matches the new host. The fastest fix is to treat this as a delivery-path problem, not just a mailbox problem, and verify why messages are being deferred on the new server.

Symptoms

  • The Exim queue count keeps increasing after the migration instead of draining
  • Outbound messages are delayed for many domains, not just one recipient
  • Mail appears in the queue manager as deferred or frozen
  • Users can submit mail, but delivery happens hours later or not at all
  • The problem started after moving to a new server, IP address, network, or provider

Common Causes

  • The new server cannot reach remote SMTP servers or its smarthost after the migration
  • Exim is running, but the queue runner is disabled, unhealthy, or not processing the spool correctly
  • The migrated server now sends from a different hostname, IP, or PTR state that remote systems reject or defer
  • A copied relay or authentication configuration still depends on the old server IP, old credentials, or old provider rules
  • Disk, inode, or spool-permission problems on the destination server prevent normal queue processing

Step-by-Step Fix

  1. Confirm whether the new server is supposed to deliver mail directly to remote recipients or send through a relay, because the correct fix path depends on the intended outbound design, not on the old server's assumptions.
  2. Review the current queue state and group messages by the real defer reason instead of only counting queued mail, because a queue caused by connection timeouts, relay authentication failures, DNS issues, and disk problems will each require a different correction.
  3. Verify that Exim itself is healthy on the new server and that queue processing is actually running, since a migration can leave the service started but the queue runner disabled, misconfigured, or unable to process the spool.
  4. Check local server health for mail handling, including available disk space, inode usage, and spool ownership or permission consistency, because Exim queue growth often accelerates when the new host can accept submissions but cannot write, retry, or clean queue files correctly.
  5. Validate the sending identity of the migrated server by checking the active mail hostname, forward DNS, reverse DNS, and the hostname Exim presents during delivery, because remote systems commonly defer or distrust mail when the new server identity does not match the new IP assignment.
  6. Test whether the new host can reach its required outbound SMTP path, including direct delivery to remote mail servers or the configured smarthost, because cloud networks, VPS providers, and firewalls often block or rate-limit outbound SMTP after a migration.
  7. Inspect any migrated relay configuration, authentication data, and allowlists tied to the old environment, because a smarthost may still expect the previous source IP, old credentials, or a different TLS or authentication policy than the new server now uses.
  8. Use Exim delivery logs and retry results to identify the dominant failure pattern, then fix that root cause before retrying mail broadly, because repeated forced retries against unresolved DNS, TLS, auth, or policy errors only keeps the queue growing.
  9. After deliveries start succeeding, monitor whether the queue drains steadily, then handle frozen or stale messages separately so you do not discard mail that became deliverable once the new server identity, network path, or relay configuration was corrected.