Rebuild your DNS records at Bluehost
DNS records are the individual instructions: this hostname points at that server, mail for this domain goes to that provider, this text string proves you own the domain. They live in whichever zone is currently authoritative.
This direction is more manual than the reverse. GoDaddy will hand you the whole zone as a file, which is genuinely useful — but Bluehost has no equivalent import, so that file is a checklist you work through rather than something you upload. Budget more time than you would expect for what sounds like a copy and paste.
Do it before the nameserver change. Records sitting at Bluehost while GoDaddy is still authoritative do nothing at all, which is exactly what you want while you build them.
- Hands-on time
- 45–90 minutes
- Start to finish
- Records apply within an hour of becoming authoritative
- Difficulty
- Moderate
- Steps
- 6
Downtime risk: None while GoDaddy is still authoritative. Missing records only bite at the moment nameservers change.
Check this first
Is this just an A record update?
If you are only moving the website to Bluehost and leaving email, subdomains and the registrar where they are, then yes — this is one record edit at GoDaddy, not a DNS migration. It is the lowest-risk change on this page, because every record you do not touch cannot break.
The short version — 5 minutes, plus TTL
- 1Get the IP address of the Bluehost account, from the portal or cPanel's server information panel.
- 2Sign in to your GoDaddy Domain Portfolio, open the domain, and select DNS.
- 3Lower the TTL on the A record first if you can wait an hour before the change — it makes a mistake correctable in minutes.
- 4Edit the A record for @ and set it to the Bluehost IP address.
- 5Check the www record. If it is a CNAME to the bare domain it needs no change; if it is its own A record, update it too.
- 6Wait for the TTL to expire, then confirm with dig example.com A +short.
Not what you need? This does not move email, does not change who manages your DNS, and does not move the domain registration. If you want Bluehost running the whole zone, follow the full steps below.
Can I do just this, and nothing else?
Yes — this works on its own
Yes, and usually in its smallest form — a single A record edit. If all you want is the website served from Bluehost, you do not need to move the zone, change nameservers, or transfer anything. Edit the A record at GoDaddy and stop there.
What changes
- Where individual hostnames point — the website, or a subdomain, or mail
- Nothing else, if you edit the records where they already live
What stays exactly as it is
- The domain stays registered at GoDaddy
- Nameservers are unchanged, so GoDaddy still answers DNS
- Every record you do not touch keeps working, email included
Before doing dns records on its own: Know the IP address you are pointing at, and confirm Bluehost is actually serving the site there before you point at it.
Before you start
- Access to both the GoDaddy Domain Portfolio and the Bluehost portal
- A list of every service that depends on this domain — email, newsletter sending, Search Console, Microsoft 365, payment providers
- The IP address of the new Bluehost account
Step-by-step
Each step is labelled with which side you are working on, so you always know whether you should be signed in to GoDaddy or Bluehost.
- 1At GoDaddy
Export the zone file from GoDaddy
GoDaddy will hand you the entire zone as a file. Even though Bluehost cannot import it, this is the single most useful thing you can do at this stage — it is a complete, dated record of a configuration that currently works.
- Domain Portfolio → select the domain → DNS
- From the Actions menu, choose Export Zone File
- Keep the file. If something turns out to be missing after cutover, this is where you look
- 2On your computer
Read the file and decide what actually moves
A zone export is a snapshot of the old setup, not a plan for the new one. Some records must change, some must be dropped, most carry over untouched.
- A and AAAA records pointing at GoDaddy must be updated to the Bluehost IP, not copied
- MX records and mail-related TXT records copy across exactly, unless you are also changing email provider
- Verification TXT records for Google, Microsoft and similar must come across, or those services quietly de-verify
- NS and SOA lines describe the old zone's authority and are not yours to recreate
- Drop records for subdomains and services you no longer run
- 3At GoDaddy
Lower the TTLs at GoDaddy, a day ahead
TTL is how long resolvers cache a record. Dropping it to 300 seconds a day before cutover means a mistake propagates its correction in five minutes rather than four hours.
- Edit the TTL on the A, CNAME and MX records in GoDaddy's DNS screen
- Do this at least one full old-TTL period before cutover, or the change itself is still cached
- Raise them back to 3600 or higher once the move has settled
- 4At Bluehost
Recreate the records at Bluehost
Work down your exported zone and build each record in Bluehost's DNS tab. There is no bulk import here, so this is deliberate, one-at-a-time work — which is also a good moment to notice records you no longer need.
- Bluehost portal → Domains → select the domain → the DNS tab
- On plans with cPanel you can also use Domains → Zone Editor, which some people find faster for bulk entry
- Note that Bluehost only lets you manage the zone once the domain points at its nameservers, so some of this may need doing right after the cutover rather than before
- 5At Bluehost
Get the mail records exactly right
Work down your list of dependent services and confirm each has its record present. This is the part people skip and regret.
- MX records, with the correct priority values
- SPF — one TXT record only; two SPF records is a configuration error that causes soft failures
- DKIM selectors, which are long TXT values and the most commonly mangled
- DMARC at _dmarc
- Any CNAME your email or newsletter provider requires for tracking domains
- 6Either side
Diff the two zones before you cut over
Put the GoDaddy export next to Bluehost's record list and reconcile them. Every record should either exist at Bluehost, be deliberately changed, or be deliberately dropped.
- Pay attention to wildcard records — a * A record catches subdomains you have forgotten about
- Check CAA records; a stale CAA can stop Bluehost issuing an SSL certificate
- Anything you cannot explain is worth keeping until you can
What goes wrong
The failures that actually happen on this step, rather than a generic warning to be careful.
There is no zone file import at Bluehost
Can cause downtimeGoing the other way, GoDaddy accepts a BIND-format zone file and applies it in one action. Coming this direction there is no equivalent, so every record is typed by hand. Plan the time, and expect transcription errors — a mistyped MX priority or a truncated DKIM key looks fine on screen and fails silently.
Bluehost only manages the zone once you point at its nameservers
Can cause downtimeIts DNS tools apply to domains using Bluehost nameservers, which creates an awkward ordering problem: the zone you want to build in advance may not be editable until after the switch. Where that bites, keep the window short — have every record written down ready to enter, and do the nameserver change and the record entry back to back.
Losing MX records is the classic outage
Can cause downtimeNothing warns you. The website looks perfect, and inbound mail starts bouncing at the moment nameservers change. Senders get a rejection you never see, and you find out days later when someone mentions they emailed you. Confirm MX before cutover, every time.
Do not blindly copy the A record
Can cause downtimeThe A record in an export from your old provider points at your old server. Import it unchanged and you have moved your DNS while still sending all traffic to the old host — which works, confusingly, right up until you cancel that account.
Verification TXT records are load-bearing
Can cause delaysGoogle Search Console, Microsoft 365 domain ownership, and various payment and analytics providers verify via TXT records. Drop them and the service de-verifies — with Microsoft 365 that can affect mail flow, not just a dashboard badge.
DKIM values get truncated
Can cause delaysDKIM public keys exceed the 255-character limit for a single TXT string and must be split into quoted chunks. Pasting through a UI that does not handle the split silently produces an invalid key, and your mail starts failing authentication.
How to check it worked
Do not rely on the site looking fine in your own browser — it caches, and it will tell you what you want to hear.
- dig example.com A +short returns the Bluehost IP once nameservers have moved
- dig example.com MX +short lists exactly the mail servers you expect, with the same priorities as before
- dig example.com TXT +short shows one SPF record, not two
- Send a test message to and from the domain, and check the headers for SPF and DKIM passes
- Google Search Console still shows the property as verified
If it goes wrong
Point the nameservers back at GoDaddy. Its zone is untouched and immediately correct again — which is exactly why you do not delete anything at GoDaddy until the move has settled.
Questions about this step
Can I just point the A record instead of moving DNS?
Often, yes — and it is the lower-risk option. If you only want the website to move hosts, edit the A record where your DNS is managed today and leave everything else alone. Email, subdomains and verifications never move, so they cannot break. Move the whole zone only when you actually want a different provider managing DNS.
How long do DNS changes take to apply?
Record changes within a zone that is already authoritative apply within an hour for most resolvers, governed by the TTL you set. Nameserver changes are slower, because the delegation TTL belongs to the TLD registry — allow up to 48 hours.
Can I keep GoDaddy managing DNS after moving hosting to Bluehost?
Yes, and given there is no zone import at the Bluehost end it is often the pragmatic choice. Leave the nameservers at GoDaddy, change the A record to the Bluehost IP, and nothing else in the zone has to be touched or retyped.
Reference documentation
Provider interfaces change. When these steps and the official documentation disagree, the documentation wins.
Only if you are doing the full move
Stuck on this step?
Send me the domain and what you have tried. I do GoDaddy to Bluehost moves regularly and can tell you what is actually blocking it.