Move the Website Without Cutting Off Company Email

The website and the mailbox are not the same move

A Malaysian company site often shares a cPanel with info@ and accounts@ on the same host: Exabytes, ServerFreak, or a reseller panel the freelancer never named. The website is files and a database. The mailboxes are a different service that happens to use the same domain name. Visitors and correspondents both type that domain, so people treat the move as one job. It is two.

If you point the domain at a new server and do nothing about mail, the new server becomes where the world tries to deliver email. An empty mail stack then bounces invoices and supplier messages. The website can look perfect while the company has gone silent.

What an MX record actually decides

DNS is a list of instructions. An A or AAAA record says where the website lives. An MX record says which server accepts mail for the domain, and at what priority. SPF, DKIM and DMARC are further TXT records that tell other mail servers whether a message that claims to be from you is allowed to be.

Google's note on MX records for Workspace is a clear statement of the general rule, even if you do not use Workspace: mail follows MX, not the website address (Google Workspace Help: MX records). Whoever can edit the DNS zone can break or preserve mail in one save.

The order that keeps mail arriving

Do the mail work before the website cutover.

Copy every mailbox you still need, including aliases that only forward. Export the last year of mail if people rely on search inside the old webmail. Write down the current MX hosts, the SPF string, and any DKIM selector you can find in DNS. Lower the TTL on those records a day or two ahead, so a mistake expires in minutes rather than a day.

Decide where mail will live after the move. If it stays on the old host, the new DNS must contain the old MX and a SPF record that still authorises that host. If mail moves to Workspace, Microsoft 365, or Zoho, create the mailboxes there first and prove a test message arrives before you change the public MX. Only then change the website's A record, or the nameservers.

Nameservers are the point of no return

Changing nameservers does not edit one record. It throws away the whole zone and serves whatever zone exists at the new DNS host. A new host's default zone often has an A record for the website and no MX, or an MX pointing at itself. That is the Saturday-morning outage.

If you must change nameservers, build the complete zone on the new side first: website, mail, SPF, DKIM, DMARC, and any verification TXT records for Search Console, Microsoft, or Facebook. Compare the two zones line by line. Then change nameservers. Keep the old zone in place and untouched until mail and the site have both worked for a full business day.

SPF and the old host

SPF is a single TXT record, not a pile of them. Two SPF records are an error, and receiving servers may treat your mail as unverified. When you add a new sender — a newsletter tool, a billing system, the new host — you add it inside the existing record. Leaving the old host's include in place for a week costs nothing and catches a scanner that still sends through the old server. Removing it on the same minute as the website launch is how a legitimate invoice starts landing in spam.

What to test before you tell staff it is done

Send mail from an outside Gmail account to info@ and reply back. Send from the company account to an outside address and check the headers for SPF pass. Open webmail, if you still use it, from a phone that is not on the office Wi-Fi. Submit the contact form on the new site and confirm it reaches a mailbox you just tested, not a file on the server.

JagaWeb's Essential System Review (RM1,500) is the right first pass when nobody can show you the current zone. It reads the records and says what will break if nameservers move tomorrow. It does not migrate the mailboxes for you. A move of the site after that inventory is scoped separately. Ongoing checks that the records have not been edited by a host panel belong with JagaWeb Care (RM450/month), after the cutover is already stable. Start with the ownership review if the zone is still a mystery.