Hello,

Sorry if this is in the wrong place but I didn't know where else to put it. I've just moved a website to a new server. I then set up the same pop3 accounts that were on the old server. I also added a couple of accounts. Now some emails are being received but some are not.

If an email is not received then it will either bounce or just disapear.

If an email is sent to one of the email accounts that was set up before the server migration then it just disappears. If an email is sent by the same person to one of the new accounts then the email is bounced.

It seems that these emails are being sent to the old server, which doesn't exist anymore. Does anyone know where the server might be occuring and how to fix it?

Dani AI

Generated

This is a classic post-migration mail-routing problem. reported some messages bouncing and some simply vanishing; noted timing/caching issues and asked about MX records — both directions are relevant. The likely causes are stale DNS/MX information at senders, an inadvertent fallback to the domain A record, or the old host still accepting mail (and delivering it somewhere unexpected). The steps below make it possible to identify which is happening and what to do next.

Quick DNS checks (from multiple resolvers and against authoritative NS) to confirm what other MTAs see:

dig +short MX example.com
dig @8.8.8.8 example.com MX +short
dig @1.1.1.1 example.com MX +short
dig +trace example.com MX
dig +short A example.com

Notes: verify there is an MX for the domain (if no MX exists, SMTP falls back to the A record). Inspect the TTL values returned — long TTLs mean caches can persist.

SMTP-side diagnostics and what their results mean:

tail -f /var/log/mail.log         # or /var/log/exim_mainlog, /var/log/maillog
nc -vz mx.example.com 25
telnet mx.example.com 25

If the new server shows inbound SMTP attempts for the domain, the issue is likely configuration on the new MTA (virtual domain not enabled, mailboxes missing, forwarding rules). If the new server shows no attempts, remote MTAs are still targeting the old MX (or the A record).

Short-term remedies and precautions:

  • If the old host was taken down too early, bringing it up as a simple relay (or restoring its MX entry temporarily) will capture queued mail and forward it to the new server.
  • If that is not possible, wait for cached MX/A entries to expire (based on prior TTL) or ask major senders to retry from networks that have refreshed DNS.
  • For future moves, lower MX TTL (to e.g. 300s) well before the cutover, verify authoritative DNS/MX from multiple locations, then decommission the old server only after confirming no traffic to it.

Caution: changing DNS and MX affects live mail flow—confirm authoritative answers before turning off the old host.

Recommended Answers

All 2 Replies

When you moved to the new server, did you give sufficient time for all dns to resolve before you disabled the old server? It normally takes 24 to 48 hours for dns to resolve. Or better yet, do you still now, after 8 days, experience this problem?

Are your MX records correct? Could be something fluky going on there.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.