Checking Mail Headers to See If Messages Hit Your Old or New MX

Right after migrating a domain to a new hosting environment or changing its Mail Exchanger (MX) records, incoming messages often appear to vanish or arrive unpredictably. One customer sends an email and it arrives inside the brand new inbox, while another customer sends an email ten minutes later and it lands in the old server webmail. It is easy to assume the migration broke or the records are misconfigured, but in almost every case, you are looking at the natural split-brain window created by DNS caching. To know with certainty whether an email actually reached your new infrastructure or landed on your old server, you do not need to guess based on user reports. The definitive answer is always recorded directly inside the message headers.

What happens to mail delivery during an MX switch

When a remote mail server prepares to send you an email, it queries a recursive DNS resolver for your domain's MX records. That resolver checks the authoritative nameservers, retrieves your MX hostname, resolves that hostname to an IP address, and stores the answer in its local cache according to the record's Time to Live (TTL). If you change your MX record from pointing to your old server to your new mail provider, that change does not apply across the entire internet instantly. Recursive resolvers run by thousands of different Internet Service Providers (ISPs) and corporate networks will continue delivering mail to the old IP until their cached record expires. If an ISP resolver ignores low TTL values—a behavior occasionally seen on aggressive caching resolvers—it may continue pointing senders to the old destination for several hours or even a full day. While this cache expires, inbound mail naturally splits. Senders whose resolvers pulled fresh records deliver to the new server; senders whose resolvers still hold the old record deliver to the previous host. If the old hosting account has already been suspended or deleted, those senders will receive sudden bounce messages.

How to read the Received trace headers

Every time a mail server receives an email and passes it along, it prepends a Received: header to the very top of the email's raw text. Because each hop adds its stamp to the top, the header list is read in reverse chronological order: the oldest hop is at the bottom, and the most recent hop (the server that finally put the message into the recipient mailbox) is at the top. When you open the raw message source in any webmail client or desktop application, scroll past the metadata until you locate the block of Received: lines. To identify which server accepted the message from the outside world, look at the hop that sits directly above the sender's origin.

TEXT

Received: from mail-sender.example.com (mail-sender.example.com [198.51.100.25])
    by mx1.yournewdestination.com (Postfix) with ESMTPS id 4StyB3201
    for <[email protected]>; Wed, 18 Oct 2023 14:22:10 +0000 (UTC)
Received: from client-pc ([203.0.113.10])
    by mail-sender.example.com with ESMTPA id 98AbC
    for <[email protected]>; Wed, 18 Oct 2023 14:21:58 +0000 (UTC)

In this illustrative example, reading from bottom to top reveals the journey. The message originated at the sender's local client [203.0.113.10], which handed it to mail-sender.example.com. That sending server then delivered it across the internet to mx1.yournewdestination.com at IP 198.51.100.25. By checking the hostname following by and confirming its IP address, you can tell immediately whether that specific message arrived through your old server's mail transfer agent (MTA) or your new host. If the by field contains your previous cPanel server, Plesk instance, or legacy VPS hostname, the remote sender's resolver was still using the cached legacy MX record.

Common pitfalls when diagnosing delivery locations

One frequent misconception is checking DNS using local diagnostic tools like dig or nslookup and assuming everyone else on the internet sees the same result. Running dig MX yourdomain.com against Google Public DNS (8.8.8.8) or Cloudflare (1.1.1.1) only verifies what those specific public resolvers see. It tells you nothing about the local ISP resolver used by an external client in another region. Another point of confusion comes from email clients configured with IMAP. If a user sets up an email client using a generic hostname like mail.yourdomain.com, and that mail A record changes along with the migration, their mail client might abruptly switch to fetching from the new server while old messages remain sitting unread on the old server's disk. The user reports that half their mail is missing, when in reality the missing messages arrived at the old host and were never synchronized across. Similarly, when modifying nameservers rather than just individual MX records, registrar-level caching takes significantly longer. While an individual MX record might have a TTL of 300 seconds, nameserver delegation records (NS records) cached at root and TLD levels often carry TTLs of 24 to 48 hours. If the old nameservers host outdated MX records, resolvers asking the old nameservers will continue directing mail to the legacy server until the delegation cache fully flushes. When debugging delivery paths across infrastructure changes, it is also worth checking forward-confirmed reverse DNS to stop sudden mail bounces on the new MTA, as outbound replies sent from the new server may be rejected by third-party filters if PTR records do not match the new hostname.

How to safely verify and test the cutover

To inspect what an incoming message actually encountered without waiting for random customer complaints, you can run controlled delivery tests and check the headers yourself. Send a test message from an external mailbox—ideally from an external webmail service like Gmail or Outlook, as well as a secondary domain hosted on a distinct network. Once the message lands, view the raw source in your email client (often labeled "Show original", "View source", or "View message headers"). Next, verify that both the old and new servers are still monitored during the propagation phase. If you have administrative shell access to the target servers, you can also tail the MTA mail logs (such as /var/log/maillog or /var/log/mail.log) to observe live connection attempts:

BASH

# Watch inbound SMTP connections in real time on the target host
tail -f /var/log/maillog | grep -E 'connect from|client='

If the log on your new server remains silent while the test sender receives a delivery success, the message undeniably hit the old server. Checking the Received: header of that delivered message will identify the exact relay path. The safest way to handle this transition is to leave the mail service active on the old server for at least 48 to 72 hours after updating MX records. If you shut down the old mail server the moment you update DNS, any sender whose local resolver has not refreshed its cache will receive a connection refused error or a hard bounce instead of delivering the message to the fallback mailbox.