Introduction

A mail migration can move the live server successfully while outbound messages still leave through the old smarthost or relay. Mail may appear to send normally, but headers, logs, or provider-side reports still show the legacy relay path because the sending system never stopped using the old outbound route.

Treat this as an outbound relay configuration problem instead of an inbound DNS issue. Start by proving which relay is currently handling live outbound mail, then check whether the destination server, application, or mail client still references the previous smarthost.

Symptoms

  • Outbound messages still route through the old relay after migration
  • Mail headers or provider logs show the previous smarthost name or IP
  • The new mail server is live, but outbound traffic still depends on the old environment
  • Some applications send through the new host while others still use the old relay
  • Deliverability or authentication behavior still matches the legacy outbound path
  • The issue started after moving mail services or applications to a new server

Common Causes

  • The new mail server still has the old relayhost or smarthost configured
  • Application-level SMTP settings still point to the previous outbound relay
  • Authenticated relay credentials were copied forward without changing the destination host
  • One part of the environment sends directly while another still relays through the old server
  • A control panel or mail client retained cached outbound settings from before the migration
  • The old relay remained reachable, so the stale routing path was never exposed during cutover

Step-by-Step Fix

  1. Inspect a recent outbound message or mail log and identify which relay actually handled it, because you need proof of the live outbound path before changing the mail configuration.
  2. Check the destination mail server for any relayhost, smarthost, or outbound relay setting that still references the old environment, because server-level outbound routing often survives a migration unchanged.
  3. Compare application and website SMTP settings with the new intended outbound path, because many migrations update the mail server but leave apps still sending through the previous relay.
  4. Verify any authenticated relay credentials and destination hostnames in use on the new system, because copied credentials can continue working against the old smarthost and hide the stale dependency.
  5. Test whether different send sources such as webmail, server mail, and application mail all follow the same route, because mixed results often mean only part of the environment was migrated cleanly.
  6. Review control panel or client-side outbound settings for accounts that still send incorrectly, because a single saved SMTP host can keep one workflow pinned to the legacy relay.
  7. Remove or replace the stale outbound relay reference and retest with fresh messages, because the old smarthost path will persist until every sending layer points only to the new route.
  8. Compare message headers and logs before and after the change to confirm the relay hop is gone, because a successful send alone does not prove the legacy path was removed.
  9. Document the final outbound mail path for servers, apps, and clients after recovery, because smarthost dependencies are easy to miss during future migrations.