Tutorial · migration-hosting · Published 2026-08-15 · 3 min read
Moving DNS records when the site moves house
Moving DNS records between hosts and providers: export the zone first, re-create forwards, and check TTL, mail, subdomains, SPF and SPF.
Moving DNS records is three jobs in one
A DNS move hides behind the "host move" headline. When you change hosting or registrars, the DNS zone moves with the domain: the site's A record, the email's MX and SPF, and the subdomains, wildcard and verification records. Copying the site files but forgetting the zone is how a migration produces working pages and dead email.
Step 1: export the whole zone, not the A record
From the current DNS provider (or the domain registrar's panel), export the full zone:
| Record type | Why it matters |
|---|---|
| A / AAAA | The site IP and www host |
| CNAME | Subdomains, often www or the mail host |
| MX | Mail server the domain sends and receives from |
| TXT | SPF, DKIM, DMARC, domain verification (Site verification is a common TXT use) |
| SRV | VoIP, XMPP, configuration for some clients |
The lines you could miss: the SPF (which must include the exact mail provider entry), the DKIM selector record (often named after the provider), and the verification records from Search Console and third parties. The DNS record reference lists what each type does.
Step 2: rebuild the zone on the new side
Create the new zone and paste your export in, adjusted for the new host's nameserver addresses if the nameservers themselves change. Adjustments to watch:
| Record | What to fix in a move |
|---|---|
| A | New host IP (the whole point) |
| MX | Often stays the same provider, confirm |
| SPF/TXT | A mismatch where a provider changes breaks mail filters |
| DMARC | A copied policy that still references the old SPF domain misreads |
Step 3: the mail question
Mail hangs on MX and SPF/DKIM. On the migration day, run a mail-check tool (or send-test through outlook/gmail to a second address) that validates SPF, DKIM and DMARC for the new setup. Breakage shows as "5.5.0" style failures or messages to spam. The fix is the exact SPF line, not retrying.
Step 4: lower TTL and cut over
- Set the TTL low once on the current zone (300 seconds for the records that will change) at least 24 hours before.
- Update the registrar's nameservers or the DNS provider to the new zone.
- Wait for propagation with the local termination caveat: your own resolver caches. Test through a public lookup that bypasses your ISP cache.
Step 5: verify like a post-mortem
- A record answers for
@andwwwfrom a fresh resolver. - MX record order correct, SPF passes (the mail headers show an SPF=pass line).
- The SSL and redirect setup is separate but test it immediately after, because the certificate on the new host must serve the same domain.
The host migration checklist treats the zone as an inventory item so the mail and the site never detach. When the change is only a domain change and not a host change, use the domain-change checklist instead.