HelpWithWebGet Help Now

Import your DNS records into Hostinger

This is the easy one. Bluehost exports your zone as a file, and Hostinger's DNS Zone Editor imports BIND zone files in bulk, with a choice of appending to or replacing the existing records. The usual hour of retyping becomes a file upload.

Better still, Hostinger saves records even when the domain is still using someone else's nameservers — they are simply inactive until the delegation changes. That restores the sequence you actually want: build the zone, read it back, confirm it is right, and only then cut over.

That property is worth appreciating. It is the difference between a DNS migration you can rehearse and one you have to perform live.

Hands-on time
20–40 minutes
Start to finish
Applies when nameservers change
Difficulty
Easy
Steps
5

Downtime risk: Very low. Records are staged inactive, so mistakes are visible and fixable before anything goes live.

Check this first

Is this just an A record update?

If you only want the website on Hostinger and are leaving email, subdomains and the registrar alone, then yes. Hostinger builds this in: instead of changing nameservers, use Connect via DNS record, which gives you the IP address to point at. Its documentation calls out keeping DNS with your existing provider or Cloudflare as a perfectly normal reason to do it this way.

The short version — 5 minutes, plus TTL

  1. 1In hPanel, open the site and choose Connect via DNS record to get the IP address.
  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 changing it.
  4. 4Edit the A record for @ and set it to the Hostinger IP address.
  5. 5Check the www record — a CNAME to the bare domain needs no change; its own A record does.
  6. 6Confirm with dig example.com A +short once the TTL has expired.

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 Hostinger managing the whole zone, the import below is easy enough that it is worth doing properly.

Can I do just this, and nothing else?

Yes — this works on its own

Yes, and in its smallest form it is a single A record edit. If all you want is the website served from Hostinger, you do not need to move the zone at all — Hostinger documents a "Connect via DNS record" option for exactly this, and explicitly mentions keeping DNS at a provider like Cloudflare.

What changes

  • Where individual hostnames point — the website, or a subdomain
  • Nothing else, if you edit the records where they already live

What stays exactly as it is

  • The domain stays registered at Bluehost
  • Nameservers are unchanged, so Bluehost still answers DNS
  • Every record you do not touch keeps working, email included

Before doing dns records on its own: Know the Hostinger IP address, and confirm the site is serving there before you point at it.

Before you start

  • Access to the Bluehost portal and hPanel
  • A list of every service that depends on this domain — email, newsletter sending, Search Console, Microsoft 365, payment providers
  • The Hostinger IP address for the new site

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

  1. 1At Bluehost

    Export the zone file from Bluehost

    Bluehost hands you the whole zone as a text file, and for once the receiving end can actually read it.

    • Bluehost portal → Domains → select the domain → DNS tab
    • Choose Export DNS zone, then Download DNS zone
    • Keep the file regardless — it is a dated record of a working configuration
  2. 2On your computer

    Clean the file before importing it

    An export describes the old setup, not the new one. The import is only as good as what you feed it, and a blindly copied A record is the classic way to end up pointing at the host you just left.

    • Update A and AAAA records to the Hostinger IP rather than importing the Bluehost one
    • Leave MX and mail TXT records exactly as they are, unless you are changing email provider
    • Keep verification TXT records for Google, Microsoft and similar
    • Strip NS and SOA lines — they describe the old zone's authority
    • Delete records for subdomains and services you no longer run
  3. 3At Hostinger

    Import the zone into Hostinger

    The DNS Zone Editor takes a BIND file directly. Choose deliberately between appending to the existing records and replacing them.

    • hPanel → Websites → select the site → Advanced → DNS Zone Editor
    • For a domain without hosting: Domains → select the domain → DNS / Nameservers
    • Use the bulk import and supply your cleaned BIND file
    • Replace is usually what you want on a fresh site; append risks duplicate or conflicting records
    BIND lines the importer accepts
    example.com.        3600  IN  A      31.170.160.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"
  4. 4At Hostinger

    Read the imported zone back

    This is the step the other hosts do not let you take. The records are stored but inactive, so you can check every one of them against your source with nothing live depending on the answer.

    • Compare the imported list against the Bluehost export, line by line
    • Check MX priorities came across as numbers, not merged into the hostname
    • Check long DKIM values are intact rather than truncated
    • Confirm there is exactly one SPF record
  5. 5At Bluehost

    Lower the TTLs at Bluehost, a day ahead

    Still worth doing. It shortens the window in which a mistake keeps being served from cache after you have corrected it.

    • Edit the TTL on the A, CNAME and MX records in Bluehost's DNS tab
    • Do it at least one full old-TTL period before cutover
    • Raise them back to 3600 or higher once things have settled

What goes wrong

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

  • Import adds to what is already there

    Can cause delays

    Hostinger offers append or replace. Append on a site that already has default records leaves you with two answers for the same name, which resolves unpredictably. On a freshly created site, replace is almost always the right choice — but read what is there before deciding.

  • Staged records look live but are not

    Can cause delays

    The flip side of Hostinger saving records while the domain points elsewhere: a zone that looks complete in hPanel is doing nothing at all until the nameservers change. Do not conclude from a tidy record list that the migration is done, and do not test with dig expecting the new answers yet.

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

  • Do not blindly copy the A record

    Can cause downtime

    The 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 delays

    Google 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 delays

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

  • The imported record list in hPanel matches the Bluehost export, allowing for the A record you deliberately changed
  • dig example.com MX +short returns the same mail servers as before, once nameservers have moved
  • dig example.com TXT +short shows one SPF record, not two
  • A test message to and from the domain passes SPF and DKIM
  • Google Search Console still shows the property as verified

If it goes wrong

Until the nameservers change, there is nothing to roll back — the staged zone is inert. Afterwards, point the nameservers back at ns1.bluehost.com and ns2.bluehost.com, whose zone is untouched and immediately correct.

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 import the Bluehost zone file without editing it?

You can, and it will work — but the A record in it points at Bluehost, so your site would keep being served from the host you are leaving. It works right up until you cancel that account. Edit the address records before importing.

What does the Reset DNS Records button do?

It restores Hostinger's default records for the domain. Useful if an import has left the zone in a mess and you would rather start from a known state than unpick it — but it discards what is there, so export first.

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

Get Help With This MigrationMigration service details

← All Bluehost to Hostinger stepsMigration guide tool

CallTextMessage