HelpWithWebGet Help Now

Copy DNS records from Bluehost to GoDaddy

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 inside whichever DNS zone is currently authoritative.

Both providers support zone files, which makes this far less tedious than retyping. Bluehost exports the zone as a .txt file; GoDaddy imports BIND-format zone files. It is still worth reading the file before you import it, because a straight copy carries across records you no longer want — including the A record pointing at Bluehost's server.

Do this before the nameserver change, not after. Records sitting at GoDaddy while Bluehost is still authoritative do nothing at all, which is exactly what you want during setup.

Hands-on time
30–60 minutes
Start to finish
Records apply within an hour of becoming authoritative
Difficulty
Moderate
Steps
7

Downtime risk: None while Bluehost 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 a new server and leaving email, subdomains and the registrar where they are, then yes — this is one record edit at Bluehost, not a DNS migration. It is the lowest-risk change on this page, because every record you do not touch cannot break. Do this instead of moving the zone unless you specifically want GoDaddy managing your DNS.

The short version — 5 minutes, plus TTL

  1. 1Get the IP address of the GoDaddy hosting account, from the hosting dashboard or cPanel's server information panel.
  2. 2In the Bluehost portal, open Domains → your domain → the DNS tab.
  3. 3Lower the TTL on the A record to 300 first if you can wait an hour before the change — it makes a mistake correctable in minutes.
  4. 4Edit the A record for @ (the bare domain) and set it to the GoDaddy IP address.
  5. 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.
  6. 6Wait for the TTL to expire, then confirm with dig example.com A +short that the new IP is being returned.

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 GoDaddy running the whole zone, follow the full steps below instead.

Can I do just this, and nothing else?

Yes — this works on its own

Yes, and this is the task most often needed on its own — usually in its smallest form, which is a single A record edit. If the only thing you want is the website served from a different server, you do not need to move the zone, change nameservers, or transfer anything.

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 wherever it is now
  • Nameservers are unchanged, so the same company still answers DNS
  • Every record you do not touch keeps working, email included

Before doing dns records on its own: Know the IP address or hostname you are pointing at, and confirm the destination is actually serving the site before you point at it.

Before you start

  • Access to both the Bluehost portal and the GoDaddy Domain Portfolio
  • A list of every service that depends on this domain — email, newsletter sending, Google Search Console, Microsoft 365, payment providers
  • The IP address or hostname of the new GoDaddy hosting 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 Bluehost or GoDaddy.

  1. 1At Bluehost

    Export the zone file from Bluehost

    Bluehost can hand you the entire zone as a text file, which is both your working copy and your record of what the live configuration was.

    • Bluehost portal → Domains → select the domain → DNS tab
    • Choose Export DNS zone, then Download DNS zone
    • Save the .txt file — it is your reference if anything is missing later
  2. 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 come across untouched.

    • A and AAAA records pointing at Bluehost's IP must be updated to the GoDaddy server, 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 should not be imported
    • Delete records for subdomains and services you no longer run — a migration is a good moment to stop carrying them
  3. 3At Bluehost

    Lower the TTLs at Bluehost, a day ahead

    TTL is how long resolvers cache a record. Dropping it to 300 seconds a day before cutover means that if something is wrong, your correction propagates in five minutes instead of four hours.

    • Edit the TTL on the A, CNAME and MX records in Bluehost's DNS tab
    • Do this at least one full old-TTL period before you cut over, or the change itself is still cached
    • Raise them back to 3600 or higher once the move has settled
  4. 4At GoDaddy

    Clear GoDaddy's default records first

    GoDaddy pre-populates new domains with its own parking records. The zone import adds to existing records and fails outright on any conflict, so a leftover default A record will block the whole import.

    • GoDaddy Domain Portfolio → select the domain → DNS
    • Remove the default parked A record and the www CNAME if they conflict with what you are importing
    • Leave anything you deliberately want to keep
  5. 5At GoDaddy

    Import the zone file at GoDaddy

    GoDaddy accepts BIND-format zone files (RFC 1035). Bluehost's export is usually close enough, but expect to clean it up first — strip the SOA and NS lines and check that hostnames are fully qualified with a trailing dot.

    • Domain Settings → DNS → Actions menu → Import Zone File
    • Drop the file in, or Browse files, then Apply Zone File
    • If the import is rejected, the cause is almost always a conflict with an existing record or a format issue on one line
    BIND-format lines GoDaddy accepts
    example.com.        3600  IN  A      203.0.113.10
www.example.com.    3600  IN  CNAME  example.com.
example.com.        3600  IN  MX     10 mx1.mailprovider.com.
example.com.        3600  IN  TXT    "v=spf1 include:mailprovider.com ~all"
  6. 6At GoDaddy

    Add anything the import could not carry

    Work down your list of dependent services and confirm each has its record present at GoDaddy. 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 are the most commonly mangled
    • DMARC at _dmarc
    • Any CNAME your email or newsletter provider requires for tracking domains
  7. 7Either side

    Compare the two zones line by line

    Put the Bluehost export next to GoDaddy's record list and reconcile them. Every record should either exist at GoDaddy, be deliberately changed, or be deliberately dropped.

    • GoDaddy can export its zone too, which makes a side-by-side diff easy
    • Pay attention to wildcard records — a * A record catches subdomains you have forgotten about
    • Check CAA records; a stale CAA can stop your new host issuing an SSL certificate

What goes wrong

The failures that actually happen on this step, rather than a generic warning to be careful.

  • Losing MX records is the classic outage

    Can cause downtime

    Nothing 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.

  • Zone import fails on any conflict

    Can cause delays

    GoDaddy's import adds records to what is already there and fails if anything collides. Because it fails as a unit, a single conflicting default record blocks the entire zone. Clear conflicts first rather than debugging the import.

  • Do not blindly copy the A record

    Can cause downtime

    The A record in the Bluehost export points at Bluehost. Import it unchanged and you have moved your DNS to GoDaddy while still sending all traffic to the old host — which works, confusingly, right up until you cancel Bluehost.

  • Verification TXT records are load-bearing

    Can cause delays

    Google Search Console, Microsoft 365 domain ownership, and various payment and analytics providers verify via TXT. 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 delays

    DKIM public keys exceed the 255-character limit for a single TXT string and must be split into quoted chunks. Copy-paste 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 GoDaddy hosting 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

Because the records are staged at GoDaddy before nameservers change, rollback is instant: point nameservers back at Bluehost, whose zone is untouched and still correct. This is precisely why you do not delete anything at Bluehost 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 in Bluehost's DNS and leave everything else where it is. Email, subdomains and verifications never move, so they cannot break. Move the whole zone only when you actually want GoDaddy 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. GoDaddy's own guidance allows up to 48 hours for global propagation. Nameserver changes are slower and are covered separately.

Should I use Cloudflare for DNS instead?

It is a reasonable third option and sidesteps this question for future migrations: DNS lives with a provider you are unlikely to leave, so changing host or registrar later never touches the zone. The trade-off is another account and another place to look when something breaks.

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 Bluehost to GoDaddy moves regularly and can tell you what is actually blocking it.

Get Help With This MigrationMigration service details

← All Bluehost to GoDaddy stepsMigration guide tool

CallTextMessage