Answer first: To move a website without breaking business email, inventory the current domain, nameservers, DNS records, web host, mail provider, and certificate first. Change only the records required for the website, preserve mail-related records, lower risk with staged validation, and keep a tested rollback until the new site and email both work.
Imagine a hypothetical home-based event planner named Nia. She hires someone to move her website to faster hosting. The new homepage works, but new inquiries stop arriving. The website change replaced the domain’s nameservers and accidentally removed the records used by her mail provider.
Nia’s site is online. Her business communication is not.
This failure happens when “the website” is treated as one object. A business domain can connect several separate systems, and each must be accounted for before a change.
Separate the five systems
Write down the current owner and provider for each layer:
- Domain registration: who controls renewal and transfer of the domain name?
- Authoritative DNS: where are the active DNS records managed?
- Website hosting: which server or platform serves the website?
- Business email: which provider receives and sends mail?
- TLS certificate and edge services: which system provides HTTPS, caching, or traffic protection?
These services may come from one company or five. Moving one does not automatically require moving the others.
ICANN’s domain transfer FAQ explicitly distinguishes changing hosting from transferring a registrar. A registrant may be able to change nameservers or the hosting IP without using the inter-registrar transfer process. That distinction can prevent unnecessary risk.
Capture the current DNS before touching it
Export or record the full active DNS zone. At minimum, review:
AandAAAArecords used by the website;CNAMErecords, includingwwwand service-verification names;MXrecords used for mail delivery;TXTrecords for SPF, DKIM, DMARC, provider verification, and other services;- subdomains used by portals, forms, help desks, or applications;
- records used for certificate validation;
- current time-to-live values.
Do not copy only the records you recognize. An unfamiliar TXT or CNAME record may support email authentication or another live service. Investigate before removing it.
Save the snapshot with a date and identify who can restore it. A screenshot is better than memory, but a structured zone export is easier to compare.
Confirm where email really lives
A website contact form and a mailbox are different systems. The form may send through the web server, a transactional provider, or the business mailbox. Incoming mail follows the domain’s MX records.
Before migration, answer:
- Which MX records are active?
- Which provider hosts the mailboxes?
- Where are SPF, DKIM, and DMARC configured?
- Does the website send mail through the same provider?
- Which addresses receive form notifications?
- Is email forwarded anywhere else?
- Who can test sending and receiving from an approved mailbox?
Do not expose mailbox addresses, keys, or message content in a public migration document. Record provider names and DNS requirements in a restricted operations record.
If the website host changes but the mail provider stays, preserve the existing mail records. Do not let a hosting control panel assume it should receive local mail merely because the website was added to that server.
Decide whether the registrar or nameservers need to change
The lowest-risk website move may require only an A, AAAA, or CNAME change. If the existing DNS provider is working and authorized, there may be no reason to move nameservers.
A registrar transfer is a separate ownership and billing event. It may involve authorization codes, lock states, approval emails, and timing restrictions. ICANN notes that some registrant-detail changes or recent transfers can trigger a 60-day restriction. Check the current registrar’s policy before planning a deadline.
Do not combine a registrar transfer, nameserver move, mail-provider move, and website launch in one untested step unless there is a documented reason and rollback for each layer.
Build and test the new site before changing public DNS
The new site should be reviewed on a staging address or controlled local mapping before public cutover.
Test:
- primary pages and navigation;
- forms without sending to real customers;
- booking or checkout display without placing an order;
- account and protected-page boundaries;
- images and downloads;
- mobile layout and keyboard navigation;
- redirects from important old URLs;
- privacy, terms, refund, and contact pages;
- the intended canonical URLs and index directives.
Use synthetic data. Do not copy private customer records into an unsecured staging environment. If a full database is required, restrict access and follow an approved migration process.
Plan the DNS cutover as a reversible change
Before cutover, identify the exact old value and new value for each record. Name the operator, time window, monitoring method, and rollback condition.
If appropriate, lower the relevant DNS record’s TTL before the planned change. A lower TTL can reduce how long many resolvers cache the prior value, but it does not make propagation instantaneous and should not be treated as a guarantee.
Change the smallest possible set of records. If only the website host changes, preserve MX and mail-authentication records. Keep the old hosting available during the validation window when practical.
Do not delete the old site merely because the new homepage loads from one device.
Validate from outside the server
After the change, verify the public result from independent networks or resolvers:
- root domain and
wwwreach the intended site; - HTTPS is valid and covers the intended hostnames;
- important redirects reach the correct final URL;
- DNS answers match the planned records;
- mail still sends and receives through the approved provider;
- forms create the intended record and show an honest result;
- monitoring observes the public endpoint rather than only the server itself.
A certificate can take time to issue after DNS points correctly. The site should not switch its internal canonical domain until the HTTPS endpoint is valid and tested.
Let’s Encrypt explains that certificate issuance depends on proving control of the domain through supported challenge methods (Challenge Types). A certificate warning is not a cosmetic issue to click past; it is a reason to stop and correct the endpoint.
Protect email authentication
SPF, DKIM, and DMARC serve different roles. A migration should not combine their values casually or publish duplicate policy records.
When the website begins sending through a different authorized provider, update the relevant configuration deliberately. Test the exact sending path. A DNS record that looks correct does not prove messages are signed, accepted, or reaching the inbox.
Keep website notifications transactional. A contact-form confirmation is not permission to add the sender to a newsletter.
For a home-based business, test an inquiry from outside the business network and reply through the normal mailbox. This catches problems that a server-only check can miss.
Maintain a cutover log
Record:
- the approved scope;
- pre-change DNS snapshot;
- backups and restore location;
- exact record changes;
- time and operator;
- certificate status;
- website checks;
- mail send/receive checks;
- form checks;
- errors and recoveries;
- final acceptance or rollback.
Do not include secret values or private message content. The log should let another authorized operator understand the change without becoming a credential file.
Know when to roll back
Rollback conditions should be written before the migration. Examples include:
- the new site returns persistent errors;
- HTTPS cannot be issued in the approved window;
- mail delivery is interrupted;
- critical account or checkout paths fail;
- redirects create loops or send visitors off-site;
- the correct backup or old endpoint is unavailable.
Rollback means restoring the known prior records and confirming that the old service is healthy. It does not mean improvising a third configuration while customers wait.
Nia, our hypothetical planner, can avoid the email outage by changing only the website record. She preserves MX and authentication records, validates the new site first, confirms HTTPS, tests an external inquiry, and keeps the old host during the acceptance window.
The safest migration is not the one with the fewest steps. It is the one where every step has one purpose and a known recovery.
Review service prices and details
Turn a useful idea into a practical next step.
Use what you learned, then choose the support that fits the work ahead.
- Identify the work
Decide whether you need a new website, a focused service or ongoing support.
- Compare your options
Review scope and current charges before choosing.
- Talk through your project
Bring your website, your goal and the question you want to solve.
Older tutorials may describe earlier software or interfaces. Confirm current requirements before making changes.