DNS records · Bluehost
Move your DNS records to Bluehost
Moving DNS is the step that breaks email, and it breaks it silently. This page is about Bluehost as the destination — what its zone editor can hold, how records get in, and whether you can rehearse the move or have to perform it live.
Bluehost has no zone file import, so every record is entered by hand. Plan the time, and expect transcription errors — a mistyped MX priority fails silently.
Checked against Bluehost's documentation on August 9, 2026.
What is different about Bluehost
The process is standardised. These are the parts that are not — the things that are true of Bluehost and not of everyone else.
You cannot build the zone until you delegate to it
Bluehost only manages DNS for domains already pointed at its nameservers, which inverts the safe order. You cannot stage and verify the zone first, so the record entry has to happen immediately after the switch. Prepare on paper, or leave DNS where it is and point only the A record.
There is no zone file import
Every record is retyped. That is slower and more error-prone than it sounds — budget properly, and check the result against your source line by line rather than trusting the entry.
What the editor can actually hold
Bluehost documents A, AAAA, CNAME, MX, TXT, SRV. If your zone uses a type outside that list, find out before you commit rather than at cutover. CAA is not among them, which matters if you rely on one to constrain certificate issuance.
Bluehost at a glance
- Zone editor
- Bluehost portal → Domains → select the domain → DNS tab
- Without hosting attached
- cPanel → Domains → Zone Editor
- Record types
- A, AAAA, CNAME, MX, TXT, SRV
- Zone import
- No
- Zone export
- Yes, TEXT format
- Editable before delegation
- No — nameservers must point here first
- Propagation
- 24 to 48 hours
Step-by-step
- 1At your current provider
Inventory the zone you are leaving
Whatever the source, you need a complete picture before you touch anything. If your current provider exports a zone file, take it — it doubles as a dated record of a configuration that works.
- Capture type, name, value, priority and TTL for every record
- List every service that depends on DNS: website, email, newsletter sending, Search Console, Microsoft 365, payment providers
- Note anything you cannot explain, and keep it until you can
- 2At your current provider
Lower the TTLs a day ahead
Dropping TTLs to 300 seconds the day before means a mistake propagates its correction in five minutes rather than four hours. Do it at the old provider, while it is still authoritative.
- Edit the TTL on the A, CNAME and MX records
- Do it at least one full old-TTL period before cutover, or the change itself is still cached
- Raise them back afterwards
- 3At Bluehost
Recreate the records in Bluehost
No import, so this is deliberate one-at-a-time entry. Mail records first — they are the ones whose absence nobody notices until it is expensive.
- Bluehost portal → Domains → select the domain → DNS tab
- MX records with correct priorities, then SPF, DKIM and DMARC
- Then A, CNAME and any verification TXT records
- Export DNS zone → Download DNS zone produces a .txt copy of the whole zone
- 4On your computer
Verify from outside your own browser
Your browser and your ISP's resolver both cache, and both will tell you what you want to hear.
Check the answers the internet getsdig @8.8.8.8 example.com A +short dig @8.8.8.8 example.com MX +short dig @8.8.8.8 example.com TXT +short
Best practice
The habits that make this go smoothly, independent of which providers are involved.
- Recreate MX, SPF, DKIM and DMARC before anything else — email failures are silent and expensive
- Never import an exported zone without first updating its address records
- Lower TTLs a day ahead so a mistake is correctable in minutes
- Diff the new zone against the old one line by line before cutting over
- Keep the old zone intact until the move has settled; it is your instant rollback
- Have every record written down before you switch, because you cannot pre-build the zone here
What goes wrong
The failures that actually happen when Bluehost is the destination.
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.
The safe order is not available here
Can cause downtimeBecause Bluehost will not manage a zone before delegation, there is an unavoidable window where it is authoritative for a zone you are still filling in. Have every record written down first, or avoid the problem entirely by leaving DNS where it is and pointing only the A record.
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.
Where are you coming from?
Most of this job depends on the destination. These are the bits that depend on where you are coming from.
Coming from a provider that exports zone files
The export is still worth taking even though Bluehost cannot ingest it — treat it as the checklist you retype from, and keep it as proof of what worked.
Coming from a provider with no export
Build the inventory by hand and be systematic. With Bluehost you also cannot pre-enter it, so the list has to be complete before you switch — this is the hardest combination there is.
Coming from Cloudflare
Check which records are proxied. A proxied record's public answer is Cloudflare's address, not your origin — so copying what you see in DNS lookups rather than what is in the dashboard gives you the wrong values.
Know exactly where you are moving from?
Common questions
Does Bluehost import zone files?
No. Records are entered by hand, so budget the time and verify the result against your source rather than trusting the entry.
Can I add records at Bluehost before pointing my domain here?
No. Bluehost only manages zones for domains already delegated to it, so the records have to be created immediately after the switch. Prepare the full list in advance.
Do I actually need to move my DNS at all?
Often not. If you only want the website served from a different server, editing one A record where your DNS already lives is smaller and safer — every record you do not touch cannot break. Move the zone only when you genuinely want Bluehost managing DNS.
How long until the change takes effect?
Bluehost documents 24 to 48 hours for changes. Records inside a zone that is already authoritative apply much faster, governed by the TTL you set; a nameserver change is the slow one, because the delegation TTL belongs to the TLD registry.
Reference documentation
Provider interfaces change. When these steps and the official documentation disagree, the documentation wins.
The same job at other providers
Move your DNS records to GoDaddy
You can build the zone before delegating to it
Move your DNS records to SiteGround
You cannot build the zone until you delegate to it
Move your DNS records to Hostinger
You can build the zone before delegating to it
Move your DNS records to Cloudflare
You can build the zone before delegating to it
Want this done for you?
I move sites onto Bluehost regularly — files, database, DNS and the registrar — with the old provider kept as a rollback until it has settled.