Introduction

A mail migration can complete and still leave the SMTP banner advertising the old server hostname. Mail may seem to send and receive normally, but remote systems, logs, and deliverability checks still show the previous identity because the mail stack did not fully adopt the new hostname.

Treat this as a server identity problem instead of a generic DNS issue. Start by proving which hostname the live SMTP service presents on connect, then trace whether that name comes from the system hostname, the mail transfer agent, a relay layer, or a certificate still tied to the old server.

Symptoms

  • SMTP connections still show the old hostname after the server migration
  • Mail headers or logs reference the previous server name
  • TLS or banner checks do not match the new mail host identity
  • The new server is live, but outbound mail still looks like it comes from the old host
  • Monitoring or deliverability tools report a hostname mismatch after cutover
  • The issue started after moving mail services to a new server or provider

Common Causes

  • The system hostname on the new server was never updated fully
  • The mail transfer agent still uses a custom banner or HELO name from the old host
  • A control panel restore copied old mail-server identity settings onto the new machine
  • TLS certificates still present the previous mail hostname
  • Outbound mail is still passing through an old relay path that returns the legacy banner
  • One service was migrated, but another SMTP-facing listener still runs with the old identity

Step-by-Step Fix

  1. Connect to the live SMTP service and record the exact banner hostname it returns, because you need to confirm the real identity being presented before changing server settings.
  2. Verify the system hostname configured on the destination server, because many mail stacks inherit their SMTP identity from the underlying host name.
  3. Review the mail server configuration for any explicit banner, greeting, or HELO setting, because a custom value can preserve the old hostname even when the new server name is already correct.
  4. Check whether the affected SMTP listener is the one you intended to migrate, because a secondary listener or stale service can keep presenting the legacy banner while another part of the mail stack looks correct.
  5. Confirm that the active TLS certificate matches the new mail hostname where appropriate, because certificate identity mismatches often expose that the SMTP-facing configuration was not fully updated.
  6. Trace the outbound path to make sure mail is not still relaying through the old server or smarthost, because the banner you see may belong to a legacy relay instead of the new host.
  7. Restart or reload the mail service only after correcting the hostname source, because banner changes do not take effect reliably if the service is still using cached or old running config.
  8. Retest from outside your network and compare the SMTP banner, HELO identity, and certificate name together, because partial fixes can update one layer while another still exposes the old host.
  9. Document the final hostname, certificate name, and relay path for the new mail server, because SMTP identity settings are easy to miss during future migrations and cutovers.