Changing website hosting can improve performance, security, reliability, and technical flexibility, but the migration needs to be planned carefully when the same domain is also used for business email. A website and an email service may share the same domain name while operating on completely different servers, which means moving the website does not automatically require moving the email. Problems usually happen when DNS records are changed without first identifying which records control the website and which records control email delivery. A new host may provide instructions for changing nameservers or DNS settings, but replacing the entire DNS zone without copying the existing email records can interrupt incoming mail even when the website migration itself works perfectly.
The safest approach is to treat the website and business email as two separate services before making any changes. Start by identifying where the website is currently hosted and where email is currently being handled. The email may be hosted by Microsoft 365, Google Workspace, Zoho, the existing web host, a dedicated mail provider, or another service. You should also confirm whether the domain’s DNS is managed by the registrar, the current host, Cloudflare, or another DNS provider. This information determines which records need to remain unchanged during the migration and whether changing web hosting actually requires a DNS-provider change at all.
Identify the Email Records Before Moving Anything
Before changing hosting, export or document the current DNS records for the domain. Pay particular attention to MX records because these tell other mail servers where incoming email should be delivered. If the MX records are removed, replaced, or pointed to the wrong destination, new messages may stop reaching the business inboxes. You should also record the SPF, DKIM, and DMARC records because they help receiving mail systems verify that messages sent from the domain are legitimate. Depending on the email provider, there may also be autodiscover records, verification TXT records, CNAME records, or other mail-related entries that need to remain available.
Do not assume the new web host will recreate these records automatically. A hosting company may configure the website correctly but have no information about the company’s separate email provider. This is particularly important when changing nameservers because switching nameservers effectively changes which DNS zone controls the domain. If the new DNS zone contains only the website records and does not include the existing email configuration, the website may come online while email stops working. Maintaining a full record of the old DNS zone gives you a reference for recreating every required mail entry before traffic is moved.
Decide Whether the Email Service Needs to Move
In many migrations, there is no reason to move business email at all. A company may be moving a WordPress website from one host to another while continuing to use Microsoft 365 or Google Workspace for email. In that case, the migration should preserve the existing MX and authentication records and change only the website-related records. The web server may change, but email continues being delivered to the same service exactly as before.
The situation is different when the current email accounts are provided directly by the old web host. If addresses such as sales@example.com or support@example.com exist inside the old hosting control panel, cancelling that hosting account may also remove the mailboxes. Before the old service is closed, decide whether those mailboxes will be recreated on the new host or migrated to a dedicated email provider. The mailbox contents, folders, aliases, forwarding addresses, autoresponders, and account passwords should all be considered because simply creating the same email address elsewhere does not automatically move the historical messages stored on the old server.
Create a Complete Backup of the Website and Email
A hosting migration should never begin without a complete website backup. Save the site files, database, important configuration files, and any other data required to rebuild the current site. If email is hosted with the provider being replaced, make sure important mailbox data is also backed up or transferred before the account is cancelled. Depending on the email system, this may involve an IMAP migration, mailbox export, provider migration tool, or local backup.
The website backup protects against migration problems, while the email backup protects against a different category of risk. If the DNS is configured incorrectly for several hours, email may normally resume once the records are corrected, but if the original mailbox itself is deleted before its contents are migrated, historical messages may be much harder to recover. Keeping the old hosting account active during the transition provides another level of protection because both environments remain available while the migration is tested.
Set Up the New Hosting Before Changing DNS
The new website should be fully installed and tested before the domain begins pointing to it. Upload the site files, import the database, configure SSL, test the database connection, and confirm that the website works correctly in the new environment. Many hosting providers offer a temporary URL, staging URL, hosts-file method, or preview feature that allows the new site to be tested before DNS changes are made.
This is also a good time to check forms because contact forms often depend on email delivery. A contact form may appear to submit normally while the website is failing to send notifications. If the site’s outgoing email configuration depends on the old host’s mail server, that configuration may need to be changed after the website moves. Transactional email sent by the website, such as order confirmations, password resets, enquiry notifications, and WooCommerce emails, should therefore be tested independently from normal employee inboxes.
Lower DNS TTL Before the Migration
DNS changes are cached for a period defined by the Time to Live value, commonly called TTL. Before a planned migration, lowering the TTL on important records can help changes propagate more quickly when the final switch is made. This should ideally be done before the migration day because lowering the value immediately before changing the record may not affect DNS resolvers that already cached the older, longer TTL.
A lower TTL does not guarantee that every user will see the new website immediately, but it can shorten the transition period. During propagation, some visitors may temporarily reach the old server while others reach the new one. Keeping both copies of the website available during this period prevents unnecessary downtime. The same principle reinforces why email records should remain stable unless the email service itself is being migrated.
Change Only the Records That Need to Change
When the website is ready, update the DNS records required to send website traffic to the new server. In many configurations, this means changing an A record, AAAA record, or CNAME record while leaving the MX, SPF, DKIM, DMARC, and other email-related records unchanged. This is usually safer than replacing the entire DNS zone simply because the web host changed.
If the migration requires changing nameservers, first recreate the complete DNS zone at the new provider. Confirm that every important website and email record is present before changing the authoritative nameservers at the registrar. Once the nameserver change occurs, the new DNS provider becomes responsible for answering queries about the domain, so missing records can immediately affect services that have nothing to do with the website.
Verify MX Records Immediately After the Change
After DNS is updated, check the MX records publicly to make sure they still point to the intended email provider. The values should match the configuration documented before the migration. If Microsoft 365, Google Workspace, or another external service handled email before the move, those MX records should normally remain unchanged after the website begins loading from the new host.
Send test messages both to and from several company addresses. A successful test should include external services rather than only sending messages between accounts on the same domain. Test incoming mail from another provider, outgoing mail to another provider, replies, and any shared or departmental addresses that the business depends on. If forwarding rules or aliases exist, test those as well because they can sometimes be overlooked during mailbox migrations.
Check SPF, DKIM, and DMARC
Email authentication records deserve special attention because a business may continue receiving email even when one of these records is missing, while outgoing messages begin failing authentication or landing in spam. SPF identifies servers authorised to send mail for the domain, DKIM adds cryptographic verification to outgoing messages, and DMARC provides instructions for how receiving servers should handle messages that fail authentication checks.
If the company’s email provider remains unchanged, these records usually should remain unchanged as well. If the website sends email directly from the new server, however, the SPF configuration or SMTP setup may need review. It is usually better for important website notifications to use a properly authenticated SMTP or transactional email provider rather than relying on an unfamiliar web server’s default mail configuration.
Test Website Forms and Ecommerce Emails
Business email does not only mean employee inboxes. Websites generate important messages too. A website may send contact enquiries, appointment notifications, password reset emails, account verification messages, invoices, and administrative alerts. An online store may additionally send order confirmations, failed-payment notices, refund notifications, shipping updates, and new-order emails to staff.
Test these workflows after the hosting migration. Submit the contact forms, place a test order if the site uses ecommerce, reset a test account password, and confirm that the messages reach both customers and administrators. Checking only the homepage and assuming the migration is complete can leave these quieter but business-critical functions broken for days.
Keep the Old Hosting Active During the Transition
Do not cancel the previous hosting service immediately after pointing the domain to the new server. Keep it active long enough to confirm that the website, DNS, email, SSL, forms, scheduled jobs, and other functions are stable. If email was hosted there, this becomes even more important because old messages or account settings may still need to be transferred.
Maintaining the previous environment temporarily also creates an easier rollback option. If a serious problem appears on the new server, DNS can potentially be pointed back while the issue is investigated. Once testing confirms that the new hosting is stable and no business service still depends on the old account, the previous service can be retired more safely.
Common Hosting Migration Mistakes That Break Email
The most common mistake is changing nameservers and forgetting that the previous DNS zone contained the company’s email configuration. Another common problem occurs when a business assumes that transferring the website files also transfers the mailboxes. These are separate systems unless the provider has specifically migrated both.
Other problems include deleting the old hosting account too soon, forgetting email forwarding addresses, losing DKIM records, overwriting SPF configuration, using the wrong MX priority values, failing to test contact forms, and allowing the new web server to send unauthenticated mail. Most of these problems can be prevented by documenting the existing setup before touching DNS.
Final Thoughts
Changing website hosting does not have to interrupt business email. The key is understanding that the website, DNS, and email are separate components even when they all use the same domain. Before moving anything, identify where email is hosted, save the current DNS zone, document MX and authentication records, back up important website and mailbox data, and configure the new hosting completely before changing traffic.
When the time comes to switch, change only the records required for the website unless the email service is also intentionally moving. If nameservers must change, recreate the complete DNS zone first. After the migration, verify MX records, send external test emails, check SPF, DKIM and DMARC, and test every website function that sends notifications.
The most important rule is simple: do not cancel the old hosting until the website and email have both been verified independently. A successful hosting migration is not complete when the homepage loads from the new server. It is complete when the entire business can continue operating without customers, employees, forms, or ecommerce systems losing access to the communication channels they rely on.
FAQs
Does changing website hosting automatically change business email?
No. Website hosting and email hosting can be separate services. If the email provider remains the same, the existing mail-related DNS records should normally remain unchanged.
Which DNS records are most important for business email?
MX records are essential for receiving email, while SPF, DKIM and DMARC are important for authenticating outgoing messages and protecting domain reputation.
Can changing nameservers stop email from working?
Yes. If the new DNS zone does not contain the existing email records, changing nameservers can interrupt mail even when the website works correctly.
Should I cancel the old host immediately after migrating?
No. Keep the previous hosting active until the new website, DNS, email, forms and other business functions have been tested successfully.
Do website contact forms need testing after a hosting migration?
Yes. Forms may depend on server-specific email settings, so they should be tested even when normal company email continues working.