Website down after a move? Understanding and fixing DNS problems
5 min read
by Marcel, Senior software engineer
Hardly any topic causes website owners as much stress as DNS: the site got moved, and suddenly it's unreachable. Or worse — the site works fine, but no email has arrived since the move. Cases like this land on our desk regularly, often with the line "but the move was three days ago". So you know where to look when it happens to you, here are the typical pitfalls — and how to fix them.
The short version
- Website and email are separate: In DNS they're different records — a move breaks email if only the site moves.
- Most common fix: Change just the A record to the new server and leave the nameservers (and mail records) untouched.
- "Works for me, not for them": That's TTL caching — lower the TTL before a move so changes take effect in minutes.
- SSL warning after a move: Have the certificate re-issued once the DNS change has propagated everywhere.
- Golden rule: Document every DNS record before you change anything, then test website and email.
Document every DNS record
Before you change anything, capture the current state of the DNS panel — a screenshot is enough. Pay special attention to the A record, the MX records and the TXT records with SPF and DKIM.
Lower the TTL ahead of time
Set the TTL of the records you plan to change to 300 seconds, at least a day before the move while the old TTL still applies. Then the actual switch takes effect in minutes instead of hours.
Change only what has to change
If just the website is moving, point the A record at the new server and leave the nameservers alone. That keeps all your mail records untouched, which is where most migration disasters start.
Check the www variant too
Your domain and the www version are two separate names with their own records. Update both and make sure the server redirects one variant to the other.
Verify what the world sees
Use a free DNS checker to see which IP address your domain returns from different parts of the world. That tells you whether the change has propagated or you still need to wait.
Re-issue the SSL certificate
Once the DNS change has taken effect, have the certificate issued on the new server. With most hosts that is one button; sometimes it just needs a second attempt a few hours later.
Test the website and the email
Open the site with and without www, then send a mail to yourself and reply to it. Only when both work is the move actually done.
Quick explainer: what DNS actually does
DNS is the address book of the internet. When someone types your domain, their device asks DNS: "Which server belongs to this address?" The answer lives in your domain's DNS records. The most important ones:
- A record: points to your web server's IP address — it decides where your website lives.
- MX records: define which server accepts your email — independent of the website.
- CNAME: a pointer to another name, often used for subdomains like www.
- TXT records: contain SPF and DKIM for sending mail, among other things.
The crucial point a lot of people don't know: website and email are separate concerns in DNS. That's exactly where the most common migration disaster comes from.
Pitfall 1: the website moves — and drags the email with it
By far the most common problem we see on websites we take over: during a hosting switch, the domain's entire nameservers get pointed at the new provider. From that moment on, that provider's DNS records apply — and they know nothing about your email setup. The website runs beautifully after the move, but the MX records point nowhere or at the new host's default. The result: mail doesn't arrive for days, and senders get a bounce message at best.
The fix — better yet, the prevention: document all existing DNS records before any move (a simple screenshot of the DNS panel is enough). If only the website is moving, it's usually enough to change the A record to the new server — the nameservers, and with them all mail records, stay untouched. If the damage is already done: re-enter the old MX, SPF and DKIM records at the new provider. By the way, the mail from that window is rarely lost — reputable mail servers keep retrying delivery for several days.
Pitfall 2: "works for me, not for the client" — TTL
Every DNS record has a lifetime, the TTL (time to live). It tells the servers asking: "Remember this answer for X hours." When you change a record, some visitors see the change immediately, others only after hours — depending on when their provider last checked. That explains the familiar phenomenon where the moved website already works on your phone but the office still gets the old one.
The fix: lower the TTL of the affected records well before a planned move — to 300 seconds, say, and at least a day ahead while the old TTL still applies. Then the actual switch takes effect in minutes instead of hours. After the move you can raise the TTL again.
Pitfall 3: the domain works without www — but not with it (or the other way around)
From a DNS point of view, your domain and the www variant are two different names, each with its own record. If only one of the two gets updated during a move, the other still points at the old server — and depending on what visitors type, they land on the new website, an error page or the old version.
The fix: check both records and point them at the new server. On the server itself, a redirect should then make sure only one of the two variants is the "real" one — that matters for Google too, so you don't end up with two identical websites competing. We covered how to set this up cleanly in our piece on technical SEO basics.
Pitfall 4: the site loads, but the browser warns about the connection
After a move, an SSL warning likes to show up: "This connection is not secure." The cause is almost always that no certificate for your domain has been set up on the new server yet — or that one couldn't be issued because the DNS change hadn't propagated everywhere when the server tried.
The fix: have the certificate (re-)issued on the new server once the DNS change has taken effect. With most hosts that happens at the push of a button or automatically — sometimes it just needs a second attempt a few hours later.
Top tip
With free online tools like a "DNS checker" you can see which IP address your domain is currently returning from different parts of the world. That tells you right away whether a change has propagated everywhere — instead of guessing blind about whether you still need to wait or something is genuinely broken.
Our advice: never do DNS changes "real quick"
Almost every DNS emergency we handle has the same backstory: a change was made on the side, without capturing the current state and without knowing which records exist for what. Half the battle is simply care — document, change only what's necessary, then test the website and the email.
If your website is down after a move, your email stops arriving, or you'd rather not handle an upcoming switch on your own: we'll take care of it — from taking stock to the clean cutover to testing afterwards. For Weblication websites in particular we do this regularly as part of ongoing care, so a case like this doesn't come up in the first place. Get in touch and we'll look at it together.
Frequently asked questions
Why is my website not loading after a hosting move?
In most cases the A record still points at the old server, or the domain’s nameservers were switched to the new provider whose DNS knows nothing about your old setup. Check both: which IP address your domain returns, and whether the www variant points to the same place. A free DNS checker shows you what the world currently sees.
Why does my email stop working after a website move?
Because website and email are separate concerns in DNS. If the whole nameservers get pointed at the new host during a hosting switch, the MX records go with them — and the new host doesn’t know your mail setup. Re-enter the old MX, SPF and DKIM records and it works again. The good news: mail from that window is rarely lost, since reputable mail servers keep retrying for several days.
How long does a DNS change take to take effect?
That depends on the TTL, the lifetime each record carries. Until the old TTL expires, some visitors still see the old answer — which is why the moved site already works on your phone while the office still gets the old one. Lower the TTL to 300 seconds at least a day before a planned move, and the actual switch takes effect in minutes instead of hours.
Why does the browser warn about SSL after a move?
Almost always because no certificate for your domain has been set up on the new server yet, or one couldn’t be issued because the DNS change hadn’t propagated everywhere when the server tried. Have the certificate re-issued once the change has taken effect — with most hosts that’s one button, and sometimes it just needs a second attempt a few hours later.