How a Routine DNS Migration Took Down Email for 20 Hours: A Real Case Study From Nepal

TL;DR

• We migrated a client's website from an old hosting account to Cloudflare and Vercel. The website launch was flawless.
• The client had an active mail server on the old hosting account that nobody mentioned during scoping, and Cloudflare's automated DNS scan could not see it.
• The old hosting account was suspended for nonpayment. Suspension does not stop a mail server from running, but it did stop the old DNS server from answering mail-related queries during the scan.
• Email kept working for hours after the migration because DNS resolvers around the world were still serving cached records. Once those caches expired, inbound mail failed completely and silently.
• The outage lasted 18 to 20 hours before the client noticed missing emails.
• Recovering the mail server required tracing WHOIS records, a related client domain, and a set of old nameservers that were still holding the original zone data.
• We now run a mandatory pre-migration audit and a post-migration checklist on every domain move, and we have included both at the end of this article so you can use them too.

Why We Are Telling You This

Most agencies do not publish their incidents. We think that is a disservice to every business owner who is about to redesign a website, switch hosting providers, or move a domain to a new DNS platform. The failure described here is invisible at the moment it happens. It does not throw an error. It does not show up on a dashboard. It just sits there quietly until a client calls to ask why nobody has emailed them in a day.

This case happened to one of our own clients in April 2026, during a project that otherwise went well. We are publishing the full technical account, sanitized to protect client confidentiality, because the lessons in it apply to nearly every business that has ever changed its DNS provider, switched web hosts, or handed a domain to a new IT partner without a full inventory of what is actually running on it. If you are planning a website redesign or migration of your own, this is worth reading before you start, not after something breaks.

What Happened: A Website Migration With a Hidden Mail Server

The Engagement Scope

The client is a regulated financial services institution based in Nepal. For confidentiality, we refer to them here simply as the Organization. They engaged us to redesign and redeploy their public website on modern infrastructure. The agreed scope, as communicated to us, covered website development and DNS management. Nobody on the client side mentioned email.

Before the engagement, the Organization's domain sat on a shared cPanel hosting account with a local Nepali hosting provider. That account held both the old website files and a Postfix-based mail server on a dedicated mail subdomain, handling all of the Organization's corporate email. As far as anyone we spoke with knew, that mail server had been running without issue for years.

What nobody told us, and what nobody at the Organization seemed to know either, was that the hosting account had been suspended some time earlier for an unpaid bill. In a typical cPanel environment, suspension disables the website and the control panel login. It does not stop the mail transfer agent, which runs as its own server process. So the Organization's email kept arriving normally, even though the account behind it was technically dead in every other respect. Nobody had a reason to go looking, because nothing appeared to be wrong.

The Mail Server Nobody Mentioned

We built the new website on Vercel, added the domain to Cloudflare for DNS management, pointed the new A records at Vercel's infrastructure, and updated the nameserver delegation at the registrar. The new site went live and performed exactly as expected. From a website standpoint, the project was a clean success.

Here is the part that matters. When you add a domain to Cloudflare, it runs an automated scan of the existing authoritative nameservers and tries to import whatever DNS records it can find. This is a convenience feature, not a full zone transfer, and it only works if the old nameservers actually respond to the query at the time of the scan. Because the Organization's cPanel account was suspended, the old hosting provider's DNS server did not return mail-related records during that scan. Cloudflare imported the website's A records, because those resolved fine, and quietly imported nothing else. No MX record. No SPF record. No DKIM key. None of it made it into the new zone, and nothing in the process flagged this as a problem, because from Cloudflare's point of view there was nothing to import.

Why Nobody Noticed for Almost a Full Day

The Cache That Bought Borrowed Time

If the mail records had simply vanished the moment the nameservers changed, we would have caught this within minutes. Instead, DNS caching bought everyone a false sense of security.

When you change a domain's nameserver delegation, resolvers across the internet do not switch over instantly. Each one caches the previous records for as long as its TTL, or time to live, allows. In this case, the MX record itself had a TTL of four hours. For several hours after the migration, mail servers trying to deliver messages to the Organization's domain were still pulling the MX record from their own cache, not asking Cloudflare at all. Delivery continued exactly as normal. There was no visible signal that anything had changed, because for that window, nothing had.

Timeline: How the Outage Actually Unfolded

The table below lines up what was happening at the DNS layer against what a person watching the mailbox would actually have noticed. This is the core of why an 18 to 20 hour outage went undetected. Every layer of the problem was working correctly on its own. It was the combination of a missing record and a caching mechanism doing exactly what it is designed to do that produced total silence.

The takeaway here is simple and worth repeating to anyone who manages infrastructure. TTL caching means the effects of a DNS change are not fully visible for hours, sometimes longer. A migration that looks clean at the moment you make it can still be a slow-motion outage that has not reached you yet.

The Real Root Cause: A Suspended Account Cloudflare Could Not See Around

How Automated DNS Import Works

Cloudflare's onboarding scan is genuinely useful in the overwhelming majority of cases. It queries the domain's current authoritative nameservers for common record types and pulls in whatever it finds, saving a technician from manually retyping an entire zone. The catch is right there in how it is described: best effort, dependent on the old nameservers actually answering. It is not a guarantee, and it was never marketed as one.

Why the Scan Came Back Incomplete

In this case, the old hosting provider's DNS server would not return mail-related records for the domain while the associated cPanel account sat suspended. The scan completed without error. It simply came back with less than the full picture, and there was no indicator anywhere in the process that said "by the way, this domain used to have a mail server and it did not come across." A migration checklist that trusts the automated import as complete will miss exactly this kind of gap.

Tracing a Ghost Mail Server: The Forensic Recovery

Once the outage was reported, the actual problem became clear quickly: the mail server was running somewhere on the internet, fully operational, and completely unreachable by DNS. Its IP address was unknown. The old hosting provider's name was unknown. Nobody had login credentials for the suspended account. The Cloudflare zone contained nothing that pointed back to it. Recovering it meant reconstructing its location using nothing but public DNS tools and a bit of investigative reasoning.

The Dead Ends

A few paths seemed promising and were not.

Checking WHOIS on the two IPs currently in the Cloudflare zone confirmed they both belonged to the new hosting platform for the website, not the old mail provider. A historical IP lookup tool came back with only the same two current IPs, because the domain had originally used nameserver delegation rather than direct A records, and that kind of tool has no visibility into records that were never directly attached to an IP history. Attempting to reach the old cPanel control panel through the domain's usual URL failed outright, because the domain now pointed entirely at the new website infrastructure. Every one of these attempts made logical sense to try, and every one of them came back empty.

The Pivot Point

The detail that actually cracked the case was sitting in Cloudflare's own audit log the entire time. A second, related domain belonging to an affiliated organization had been added to the same Cloudflare account about 18 minutes before the primary domain. That second domain had not yet been migrated, which meant it was still delegated to the original hosting provider's nameservers.

Querying that second domain's NS records pointed us toward a hosting provider. Querying that provider's nameservers for the primary domain, however, returned Cloudflare's own SOA record rather than any original data, which told us the provider had already purged its old zone for that domain following the nameserver change. Close, but not the answer.

The actual original nameservers turned out to belong to a different provider entirely, one that predated the hosting arrangement everyone assumed was the only one. This is a detail worth sitting with: even people close to a domain's history do not always remember every provider it has passed through, and the DNS record itself is often the only reliable memory of that history.

Recovering the Zone

With the correct old nameservers identified, we queried them directly for the domain's mail records. Even though the domain was no longer delegated to them, the servers still held the original zone data and answered with an authoritative response, confirmed by the "aa" flag in the reply. That query recovered the MX record, the mail server's A record, the SPF TXT record, and the DKIM public key under the default selector, everything needed to rebuild a working mail configuration from scratch.

Restoring Mail Delivery: The Four Records That Matter

With the original records recovered, four DNS entries needed to go back into Cloudflare. Each one plays a distinct role, and getting the proxy setting wrong on even one of them is enough to break mail delivery all over again in a different way. The table below is close to what we actually added, with the specific IPs and key values replaced by placeholders since this is a live client's infrastructure.

The one setting that trips up even experienced engineers is the proxy toggle on the mail A record. Cloudflare's orange cloud proxy is fantastic for websites. It is actively harmful on a mail record, because it terminates the connection as if it were web traffic and never lets the actual SMTP handshake through. That record has to stay on DNS only, every time.

Proving the Fix Actually Worked

Adding the records back is only half the job. The other half is confirming, with evidence, that mail is actually flowing again, rather than assuming it is because the records are now visible in a dashboard.

Confirming DNS Propagation

Within a couple of minutes of saving the records, we queried a public resolver directly for each of the four record types to confirm they were live and returning the expected values: the MX record, the mail server's A record, the SPF TXT record, and the DKIM TXT record. All four came back exactly as expected within minutes, since Cloudflare's global network propagates changes quickly.

Confirming the Server Itself Was Alive

DNS records existing is not the same thing as a mail server accepting connections. Port 25, the standard SMTP port, is blocked by most consumer and business internet connections specifically to prevent spam origination, so a failed connection attempt on port 25 from a normal office connection does not mean the server is down. Port 587, the standard mail submission port, is typically open, and a successful connection there is solid evidence the server is alive and listening.

We also ran a full SMTP diagnostic directly against the mail server's IP address, checking things like the SMTP banner, reverse DNS matching, TLS support, and whether the server was configured as an open relay. Every check passed. One detail worth calling out for anyone else who runs this kind of diagnostic: querying by domain name instead of by IP address produced a misleading result, connecting to the website's hosting IP instead of the mail server. That happens because some diagnostic tools resolve a domain to its A record rather than following its MX record the way real mail servers do. Actual mail delivery software follows the MX record every time, so this was a quirk of the testing tool, not a real delivery risk, but it is exactly the kind of false signal that can send someone chasing the wrong problem if they do not know to test the mail server's IP directly.

Root Cause Breakdown: Four Failures, Not One

It is tempting to say the incident happened because of one bad DNS scan. That is technically true and also not the full story. Four separate gaps had to line up for this to become an 18 to 20 hour outage instead of a five-minute non-event.

None of these four failures alone would have caused an 18 to 20 hour outage. Together, they turned an invisible gap into a full day of missing client email.

What This Means for Your Business

If you run a business and you are not the one managing DNS day to day, the practical risk here is this: DNS changes can look completely successful while quietly breaking something nobody thought to check. A website that loads perfectly tells you nothing about whether your email is still working.

Questions to Ask Before Any DNS or Hosting Migration

Before you or your IT partner touches a domain's nameservers, make sure these questions have honest answers on both sides:

• Does this domain have an active mail server, whether hosted with you or with a separate provider?
• Are there subdomains in active use beyond the main website and the common www alias?
• Is there an existing hosting account tied to this domain, and is that account fully paid and in good standing?
• Are there third-party services connected to the domain, such as transactional email providers, CRM integrations, or marketing tools that rely on SPF and DKIM records?
• Who set up the current mail configuration, and does anyone still have login access to that provider?

A suspended account is a particularly sneaky risk because everything can look and feel completely normal from the client's side. Mail keeps arriving. Nobody checks the billing status of a hosting account they assumed was cancelled or replaced years ago. The only way to catch this ahead of time is to ask directly and to pull the DNS records yourself before you start, rather than relying on what anyone remembers.

A Post-Migration Checklist You Can Use Today

Whether you handle this in-house or hand it to an agency, this is the minimum verification we now run after every domain migration, and it takes a few minutes:

• Confirm the website loads correctly on the new infrastructure
• Confirm an MX record exists and points where you expect
• Confirm an SPF TXT record exists and lists the correct authorized senders
• Confirm a DKIM TXT record exists under the correct selector
• Confirm the mail server accepts a connection on port 587
• Send an actual test email to the domain and confirm it arrives

That last step matters more than it sounds. DNS records existing and mail actually arriving are two different facts, and only one of them proves the other.

Why This Risk Runs Higher in Nepal

A few conditions specific to the local hosting environment make this exact scenario more likely here than in markets with more consolidated infrastructure. Many small and medium Nepali businesses run on shared cPanel hosting with local providers, often set up years earlier by a previous vendor who is no longer involved. Billing lapses on old accounts are common and often go unnoticed for a long time, precisely because a suspended account does not always announce itself the way a business owner would expect. Domain history frequently passes through more than one hosting provider over a company's lifetime, and institutional memory of exactly who is hosting what tends to fade quickly, especially at organizations where the person who originally set up the mail server has since moved on.

None of this means DNS migrations are inherently risky. It means they deserve the kind of audit described above rather than trust in a single automated import.

How We Run Migrations Now

This incident changed our internal process permanently. Every domain migration we handle now starts with a manual audit of the live authoritative nameservers before anything changes at the registrar, and closes with the verification checklist above, signed off before we consider the work done. It is a small amount of extra time up front that has already saved us from repeating this exact mistake.

This is also part of why our discovery and scoping process asks more questions than clients sometimes expect before a project starts. A domain rarely does just one job. It usually carries a website, a mail server, sometimes a handful of subdomains and third-party integrations that nobody thinks to mention until something breaks. Our full range of services covers this end to end, from the initial technical audit through hosting, DNS, and post-launch support, precisely because website work and infrastructure work are rarely as separable as they look on a proposal document.

Final Thoughts

The most unsettling part of this incident was not the outage itself. It was how quiet it was. Nothing crashed. No error appeared anywhere. A mail server kept running exactly as it always had, faithfully waiting for mail that could no longer find its way to it, for the better part of a day, because of a single missing DNS record and a suspended account nobody remembered existed.

If there is one thing worth taking from this, it is that a clean-looking migration is not the same as a complete one. If you are planning to move a website, switch hosting, or hand your domain to a new provider, ask the uncomfortable questions about what else is riding on that domain before you make the change, not after.

If you would like a second set of eyes on an upcoming migration, or a technical audit of a domain you are not entirely sure about, get in touch with our team. We would rather run the audit now than trace a ghost mail server with you later.