You keep your domain and your email when you move off WordPress, because a website migration only touches the DNS records that point visitors at your site, not your domain ownership or your mail records. Your domain stays registered in your name, and your email keeps flowing as long as the MX records are left alone. WPBuildAI changes only the website-serving records at cutover and never touches your MX or domain registration, which is why email keeps working through the move. The fear here is common and almost always misplaced.
The one rule that prevents trouble: change the records that serve the website, leave the mail records alone.
Your domain and your website are not the same thing
A domain is a name you rent from a registrar. Where that name sends different kinds of traffic is controlled by DNS records, explained well in Cloudflare’s overview of DNS. A migration updates the records that resolve your website (the A or CNAME record) so the name points at the new site. It does not transfer the domain, and it does not have to touch anything else.
That separation is why you can change your entire website and keep the same address, the same registrar, and the same inbox.
Which DNS records change, and which stay
Only the website-serving records move. Email and verification records stay exactly as they are.
| Record | What it does | Changes in a migration? | Verdict |
|---|---|---|---|
| A / CNAME (website) | Points the domain at your site | Yes, to the new host | The only essential change |
| MX (email) | Routes your email | No, leave untouched | Keep as is |
| TXT (SPF, DKIM, verification) | Email auth and site verification | No, unless you also move email | Keep as is |
| NS (nameservers) | Where DNS is managed | Only if you change DNS host | Optional, plan carefully |
The pattern: the A or CNAME record is the one thing that must change, and the MX record is the one thing that must not. WPBuildAI edits the first and never the second.
How email keeps working through the move
Email is routed by MX records, which are completely separate from the record that points to your website. As long as those MX entries are untouched, your mail provider keeps delivering exactly as before, during and after the switch. The website cutover and the mail flow simply do not intersect.
For example, a business on a workspace email provider can repoint its website to a new host in minutes and never see a single email delayed, because the change is scoped to the website record alone. The safe full sequence is covered in how to migrate a WordPress site to Lovable.
Where people actually get into trouble
Two mistakes cause the rare horror stories. The first is changing nameservers without copying every existing record first; moving DNS hosting replaces the whole record set, so any MX or TXT entry not carried over disappears, and email breaks. The second is editing the wrong record in a panic. Both are avoided by a simple rule: snapshot the full DNS zone before any change, edit only the website record, and confirm MX and TXT are identical afterward.
Use a low time-to-live on the website record before cutover so the switch propagates fast, then raise it again. If you are still deciding whether to move at all, Lovable vs WordPress for small business sites covers that call.
Which records must you write down before you change anything?
Five, and losing any of them is how a website move takes email down with it.
| Record | What it does | What breaks if it is wrong |
|---|---|---|
| MX | Routes incoming mail to your provider | Mail stops arriving, silently |
| SPF (TXT) | Lists who may send as your domain | Your mail lands in spam |
| DKIM (TXT or CNAME) | Signs your outgoing mail | Same, plus failed authentication |
| DMARC (TXT) | Tells receivers what to do on failure | Either no protection, or mail rejected |
| Verification TXT | Proves ownership to search and mail tools | Search Console and mail admin access lost |
Export the full zone before touching it, not just these five. A screenshot of the DNS panel takes one minute and is the difference between a fast rollback and an afternoon of guessing.
The pattern worth internalising: the only records a website move should change are the ones pointing at the website, which is usually the A record for your apex domain and the CNAME for www. Everything else stays exactly as it is.
How do you cut over without downtime?
By lowering the TTL first, then changing one record at a time, then checking from outside your own network.
Lower the TTL on the records you intend to change to five minutes, at least a day before the move. That tells resolvers to recheck frequently, so when you make the real change it propagates in minutes rather than over a day, and a rollback is equally fast.
Have the new site live and reachable on a temporary address first, fully tested, before any DNS change. The cutover should be the least eventful moment of the project, not the moment you find out whether the site works.
Change the website records only. Then check the site from a device on mobile data rather than your office connection, since your own machine may hold a cached answer for hours.
Then send yourself a test email in both directions, from an outside address to your domain and from your domain to an outside address, and confirm both arrive in the inbox rather than in spam.
Raise the TTL back to something normal a few days later, once you are confident.
What actually goes wrong with email?
Three failures, and all three are quiet, which is what makes them expensive.
The first is a host that manages DNS deleting records it did not create when the hosting account closes. Mail stops arriving and nobody notices immediately, because absence of email looks like a quiet day.
The second is a rebuilt SPF record that omits a sender you had forgotten: an invoicing tool, a CRM, a newsletter platform. Those messages start failing authentication and land in spam, which looks like a deliverability problem rather than a DNS one.
The third is contact form mail from the new site being sent through a different route than before. The domain has not authorised the new sender, so enquiries silently go to spam, and the business concludes the new site is generating fewer leads.
All three are prevented by the same habit: change only the website records, and after the move send a real test message from every system that sends mail as your domain.
When should you move the domain itself?
Rarely, and almost never at the same time as the website. Transferring a domain between registrars is a separate operation with its own risks, and combining it with a website move means two things can fail at once with one set of symptoms.
There are good reasons to move eventually: the domain sitting in an agency’s account rather than your business’s, a registrar you cannot get support from, or a renewal you nearly missed. All of those are worth fixing.
Do it a few weeks before or a few weeks after the website move, never during. And if the domain is currently in someone else’s account, transferring it into your own is worth doing regardless of what happens to the website, because a site you cannot point where you want is only conditionally yours.
When is a website move the wrong time to touch DNS?
When more than one thing would change at once. A website move should alter the records pointing at the website and nothing else, so combining it with a mail provider change, a domain transfer, or a new email security policy means several failures can appear with one set of symptoms.
It is also the wrong time when you do not control the DNS. If an agency or a former developer manages the zone, get access first, before anything is scheduled, because a cutover that depends on somebody answering an email is a cutover with an unknown date.
And it is the wrong time immediately before something that matters. A Friday afternoon, the day before a campaign, or the week of an event are all bad, not because the change is risky but because the recovery window needs people who are available.
The safe pattern is boring on purpose: one change, in a quiet period, with the previous state written down and a TTL low enough to undo it in minutes.
What should you verify after the cutover?
Six things, in the first hour, because every one of them fails quietly.
The website itself, loaded from a device on mobile data rather than your office connection, so you are not reading a cached answer.
Both www and the bare domain, and both http and https, since visitors and old links use all four and only one of them is the one you tested.
Incoming mail, by sending yourself a message from an outside address and confirming it lands in the inbox rather than spam.
Outgoing mail, by sending from your domain to an outside address and checking the same.
Contact form mail from the new site specifically, because it often sends through a different route than your normal email and that route may not be authorised to send as your domain.
And any automated sender: invoicing, CRM, newsletters, booking confirmations. Each is a separate system that sends as you, and each has to be tested rather than assumed.
Key takeaways: keeping your domain and email
A migration changes only the DNS record that points your domain at the website, usually an A or CNAME, and leaves your domain registration and MX records alone, so ownership and email are unaffected. Trouble only happens when nameservers are switched without copying every record across. WPBuildAI repoints the website record at cutover and never touches your mail, so your address and inbox carry on exactly as before.
Common questions about this move
Will I keep my domain and email if I move off WordPress?
Yes. A migration only updates the DNS record that points your domain at the website; it does not transfer your domain or change your email. Your registration stays in your name and your MX records keep routing mail as before. WPBuildAI changes only the website-serving record at cutover and never touches your MX or domain ownership, so your address and inbox keep working throughout the move.
Does changing my website affect my email?
No, as long as the MX records are left alone. Email is routed by MX records, which are separate from the A or CNAME record that resolves your website. Repointing the website record has no effect on mail delivery. Email only breaks if someone switches DNS nameservers without copying the existing MX and TXT records to the new DNS host first.
Do I need to transfer my domain to migrate?
No. You keep your domain at its current registrar. A migration just updates where the domain points by editing one DNS record. Transferring the domain to a new registrar is a separate, optional action and is not required to change your website. Keeping the domain where it is also keeps the move simpler and lower risk.
What is the riskiest DNS mistake during a migration?
Changing nameservers without first copying every existing record. Moving DNS hosting replaces the entire record set, so any MX, SPF, DKIM, or verification entry you forget to carry over vanishes, which is what breaks email. The fix is to snapshot the full DNS zone before any change, edit only the website record, and confirm the mail records are identical afterward.
Which DNS records should I write down before a website move?
MX for incoming mail, SPF, DKIM, and DMARC for outgoing authentication, and any verification TXT records proving ownership to search or mail tools. Export the whole zone rather than just those five. A website move should only change the records pointing at the website, usually the apex A record and the www CNAME, and everything else stays exactly as it is.
How do I cut over without downtime?
Lower the TTL on the records you intend to change to five minutes at least a day beforehand, so the change propagates in minutes and a rollback does too. Have the new site fully tested on a temporary address first. Change only the website records, then check from mobile data rather than your office connection, and send test email in both directions.
What should I verify straight after the DNS cutover?
Six things in the first hour. The site loaded from mobile data rather than your office connection. Both www and the bare domain, over http and https. Incoming mail from an outside address. Outgoing mail to one. Contact form mail from the new site, which often uses a different sending route. And every automated sender: invoicing, CRM, newsletters, booking confirmations.
