Your website, your email and your password resets all die together

It’s mid-morning and the website won’t load. You try your email to warn a client, and that won’t send either. So you go to log in to the hosting company’s control panel, which wants a password reset, which it will kindly send to your email address. On your domain. Which is down.

Nothing has been hacked and nothing is misconfigured. Your domain name, your website, your email and the account you’d use to fix them all simply live with the same company, and that company is having a bad day. Everything you’d reach for to route around the problem is inside the problem.

This is the quiet failure: not a weak setting, but a single thread that everything hangs from, and a way back in that runs through the thing that’s broken.

Why it stays invisible

On 13 August 2026 a storm knocked out the cooling at the Phoenix data centre that runs a large part of Namecheap’s operations, and the operator instructed Namecheap to power its equipment down before it overheated. According to Namecheap’s own account of the outage, that took out Namecheap.com, shared, VPS and dedicated hosting, EasyWP, Private Email and DNS management at once, and left the support helpdesk unable to answer by chat or email. Websites, inboxes, the controls you would use to move them, and the people you’d ask for help: one building.

It’s worth being precise about what survived. Namecheap says DNS resolution itself stayed up, which is DNS doing exactly what it was designed to do. But DNS management did not, so anyone who wanted to point their website or mail somewhere else for the afternoon couldn’t change a single record until the building cooled down.

The other version of this story goes further. In February, the sign-in company Clerk lost its DNS provider entirely for two and a half hours. Clerk’s postmortem is refreshingly candid: the provider ran four nameservers across two separate networks, and all four failed together. Because SPF and DKIM records (the DNS entries that prove your mail is really from you) couldn’t be looked up, sign-in emails went undelivered or into spam. And because one critical domain was registered with the same company, Clerk couldn’t even change its nameservers to escape. Their own monitoring didn’t notice promptly either, since cached answers kept making things look healthy.

That last detail is the heart of why this stays invisible. “We have four nameservers” sounds like redundancy. It usually means four addresses belonging to one company, which is redundancy against a disk failing, not against that company having a bad day.

It’s also completely normal. Across 14,966 domains we measured on 22 September 2026, 94.01% had every nameserver with a single provider. For UK small companies it’s 97.38% of 954. To be fair to all those companies, we rate this low severity: a single DNS provider is a perfectly reasonable choice for a small business. The problem isn’t the one provider. It’s when that provider is also your web host, your mail host and your registrar, and the only way back into it is an email address it hosts.

Find it yourself

You need about ten minutes and, ideally, the logins you’re about to discover you’ve mislaid. Swap yourdomain.co.uk for your own domain throughout.

1. See who answers for your domain. On a Mac or Linux machine, open Terminal and run dig NS yourdomain.co.uk +short; on Windows, run nslookup -type=ns yourdomain.co.uk. You’ll get two or more nameserver names. Look at the part after the first dot: if they all end in the same company’s name, that’s one provider, however many lines there are. (If you’d rather not use a command line, any online “DNS lookup” or “NS lookup” tool shows the same thing.)
2. See where your mail goes. Run dig MX yourdomain.co.uk +short (or nslookup -type=mx yourdomain.co.uk). Names ending in google.com or outlook.com mean Google Workspace or Microsoft 365; anything else is often your web host’s own mail service.
3. Write down four names. Who is your registrar (the company you pay for the domain itself, shown by any WHOIS lookup), who runs your DNS (step 1), who hosts your website, and who hosts your email (step 2). If the same name appears three or four times, one outage takes all of it.
4. Check the way back in. Log in to your registrar and your DNS provider, if they differ, and look at the email address on the account and where two-step verification codes go. If that address is @yourdomain.co.uk, then losing your domain also loses your route to rescuing it.
5. Find the break-glass kit. Ask yourself who else could log in to these accounts if you were on a plane, and where the backup codes for two-step verification actually are. “In my inbox” doesn’t count.

Step 4 is the one that tends to produce a small, thoughtful silence.

The fix

You don’t need to rebuild anything, and for most small firms you shouldn’t. The aim is to make sure one company’s bad day is an inconvenience rather than a lock-out.

Move your recovery address off your own domain first. This is the cheapest fix and the most important. Change the account email on your registrar and DNS provider to an address that doesn’t depend on your domain: a personal address you control, or a mailbox at a different provider. Do the same for your hosting account. It takes five minutes and breaks the loop entirely.

Keep your backup codes somewhere that isn’t your email. A shared password manager that two trusted people can open, or a printed copy in the office safe, is fine. The point is that your break-glass access doesn’t live inside the glass.

Separate DNS from your web host when you next have a quiet afternoon. Most registrars and dedicated DNS services will host your records for free or for very little, so a web hosting outage leaves your mail and your records under your control. Be careful here, because this is the one step that can cause the outage it’s meant to prevent: copy every existing record across before you switch nameservers (the MX and TXT records for mail are the ones people miss), then check your mail and website still work. If that makes you nervous, it’s a sensible job to hand to whoever built your site.

Think twice about keeping the registrar and DNS together. Clerk’s lesson was that when the DNS company is also the registrar, you can’t change nameservers during its outage. For a small business, simply making sure you can always log in to the registrar gets you most of the benefit.

Only then consider a second DNS provider. Running two providers side by side genuinely survives the Clerk scenario, but it means keeping two sets of records in step for ever, and for most small firms that’s more moving parts than the risk justifies. If your website or email going dark for a day would cost you real money, it’s worth the conversation; if not, the steps above are enough.

Write it down. One short page: registrar, DNS, web host, mail host, who can log in to each and where the codes are. Look at it once a year, and whenever someone who held a login leaves.

None of this stops your provider having a bad day. It just means that when they do, you can still get in, still send an email, and still point things somewhere else, rather than refreshing a status page and waiting.

A nameserver change you didn’t make, or a site that quietly stops responding, is exactly the sort of thing that goes unnoticed until a customer mentions it. DomainOps keeps an eye on your nameservers and registrar for changes and checks that your website is actually up, so you hear first. But the check above costs nothing but ten minutes, and moving that recovery address costs five, so do that first, today, whether or not you ever automate it.