Pointing a Domain to a New Host Without Breaking Anything

Almost every DNS incident traces back to the same mistake: someone changed a record without first knowing what the old one was. Before making any change, look up and write down every existing record for the domain, including A, AAAA, CNAME, MX, TXT and NS. If the new setup goes wrong, this is what lets you put things back the way they were in minutes rather than hours.

Run the domain through Frabs' DNS Lookup tool and keep a copy of the result somewhere safe. It takes two minutes and it is the single most useful thing you can do before starting.

If the migration is planned rather than urgent, reduce the TTL on the records you are about to change to something short, like 300 seconds, at least a day before the move. This means fewer resolvers around the world will be holding a long cached answer at the moment you actually switch the record, so the new value shows up faster for more visitors. You can raise the TTL back to a normal value once the move is confirmed stable.

The root domain (example.com, not www.example.com) almost always needs an A record pointing directly at an IP address, because many DNS providers do not allow a CNAME on the root. Subdomains like www are usually a CNAME pointing back at the root domain, or occasionally a second A record of their own. Update the root A record first, confirm it resolves correctly, then update any subdomain records that depend on it.

Website hosting and email hosting are frequently handled by entirely different providers, and it is easy to forget that moving one does not require touching the other. Before changing anything, check whether the domain's MX records point at your website host or at a separate mail provider such as Google Workspace or Microsoft 365. If email is separate, leave the MX, and any related TXT records for SPF and DMARC, completely alone. Touching them unnecessarily is one of the more common ways a migration accidentally breaks email delivery for days.

Once you have made the change, do not just check it from your own computer. Your resolver may have cached the old answer from before you started, which can make everything look fine locally while other visitors are still landing on the old server. Run the domain through a lookup tool that queries fresh, and check the site itself loads correctly from the new host with the correct SSL certificate before considering the migration finished.

dig @1.1.1.1 example.com A +short