The Website and the Email Went Down at the Same Time. Check the Domain Before Anything Else.

The call comes in about the website. It has been up for nine years and this morning it will not load, and while the owner is describing that, they mention almost in passing that nobody has had any email since about the same time either. They assume those are two problems. They are one, and it is not the website and it is not the email.

When a website and the email addresses on it stop working together, in the same hour, the fault is almost never in either of them. It is in the domain name underneath both — the yourbusiness.com part. That is the single highest-value tell in small-business IT and virtually nobody knows it, so people spend a day on the phone with a web host and a mail provider who each correctly report that nothing is wrong at their end.

Why "both at once" is the diagnosis

Your online presence sits on three separate things that people tend to think of as one. There is the website, which lives on a web host. There is the email, which lives on a mail provider — Microsoft 365, Google Workspace, or your host's own mail service. And there is the domain name, which is the entry in the global address book that tells the rest of the internet where to find both of those.

That structure makes the symptoms diagnostic, because each layer fails in its own shape. A web host having a bad day takes the website down and leaves your email completely untouched. A mail provider outage or a mailbox problem stops the email and leaves the website happily serving pages. Your office internet going down stops you reaching either one, but customers elsewhere can still load the site and mail still arrives in the mailbox waiting for you.

Only the layer underneath — the domain — takes the website and the email away from everyone, at the same moment, while your office internet is plainly fine and your computers are plainly fine. If that is what you are looking at, check the domain first. It costs two minutes and it is right often enough that we now ask about it before anything else.

The most common cause by a distance is the least dramatic one: the domain expired. Not hacked, not seized, not a hosting failure. A renewal did not go through, usually because the card behind the auto-renew expired, and nobody read the notices.

The outage is deliberate. It is meant to be the notice.

This is the part that reframes the whole problem, and we have never seen it explained anywhere a business owner would look.

When a domain expires, the resulting blackout is not an accident of the plumbing. It is a requirement. ICANN — the body that sets the rules every .com, .net and .org registrar has to follow — publishes the Expired Registration Recovery Policy, and that policy tells your registrar, in as many words, to break your domain on purpose. For registrations deleted within eight days of expiry it says "the existing DNS resolution path specified by the RAE must be interrupted by the registrar from expiration of the registration until its deletion." For domains the registrar holds on to longer, it requires the same interruption "for at least the last eight consecutive days" that you can still renew.

ICANN's own guidance for registrants explains why in plain language: the rules require registrars "to disrupt the domain name's DNS service for up to 8 days before deleting the domain name," notes that "the disruption will cause any services associated with the domain name such as a website or email service to no longer work," and then states the purpose outright — "this disruption is intended to be a last mechanism to inform you that your domain name has expired so that you can take action if you want."

So the sequence is not "the domain expired and then, unfortunately, everything broke." It is "you did not answer the reminders, so the system escalated to the only message it was confident you would read." Your website and your email going dark simultaneously is the notification. Once you know that, an otherwise baffling outage becomes a single sentence with a single fix.

There is a corollary worth knowing, because it explains something people find alarming. The policy says that if the registrar points your web traffic at a page during this period, that page "must conspicuously indicate that the domain name registration is expired and provide renewal instructions." So if your site has been replaced by a generic advert-covered placeholder, look closely at it before you assume you have been hijacked. Somewhere on that page there is usually a line saying the domain has expired and how to renew it.

Confirm it in two minutes, and find out which stage you are in

You do not have to take anyone's word for this, and you do not need the registrar login to check. Every domain's current state is public. Go to ICANN's own lookup tool at lookup.icann.org and type in your domain.

Two things in the result matter. The first is the registrar's name — which is worth writing down, because a surprising number of businesses genuinely do not know who they buy their domain from, and it is often not the company that built the website. The second is the list of status codes, which is the bit everybody scrolls past and which tells you exactly where in the process you are and how much time you have left.

The ones that matter here, in ICANN's own descriptions. clientHold means the registry has been told "not to activate your domain in the DNS and as a consequence, it will not resolve" — usually, ICANN notes, for "non-payment, or when your domain is subject to deletion." That is the mandated interruption above, and it is switched off again the moment you pay. autoRenewPeriod is an informative status "set for a limited time after your domain's auto-renewal by the registry." redemptionPeriod is the serious one: "your registrar has asked the registry to delete your domain," and it will sit there for 30 days. pendingDelete, when it appears on its own, means "your domain has been in redemptionPeriod status for 30 days and you have not restored it within that 30-day period."

A domain in clientHold is a bill. A domain in redemptionPeriod is a deadline. A domain in pendingDelete is close to an emergency. They look almost identical from your desk — the website is down and the email is down in all three cases — which is exactly why the lookup is worth doing before you start making calls.

The clock, stage by stage

The timetable is set by policy rather than by your registrar's mood, so it is worth understanding once. These are the rules for the generic domains — .com, .net, .org and the rest. Country domains such as .us or .co.uk run their own registries with their own timetables, so if yours is one of those, ask that registry rather than assuming this applies.

Before expiry. Your registrar is required to send at least two renewal reminders: one "approximately one month prior to expiration" and a second "approximately one week prior." They go to the registrant email address in the domain's contact record — remember that, because it is the whole problem, and we come back to it below.

At expiry. The domain does not vanish. The registrar may delete it "at any time after" it expires, but most do not do it immediately. What does happen is the interruption described above: the website and the email stop.

The auto-renew grace period. Many registrars offer one, and ICANN describes it as "a 1-45-day period during which you may renew an expired domain name." Note the range — one day at one registrar, forty-five at another, and the only way to know yours is to read its terms. ICANN also flags something most people would never guess: during this period "the domain name may be available to third parties for registration, depending on your registrar's terms of service," and you "may also run the risk of having your domain name auctioned to a third party by your registrar." Renewing in this window is normally just paying the bill, though it may cost more than an ordinary renewal.

Deletion, then the 30-day Redemption Grace Period. When the registrar does delete the registration, the registry is required to offer a Redemption Grace Period of 30 days "immediately following the deletion," during which "the deleted registration may be restored at the request of" the registrant "by the registrar that deleted it." During those 30 days the registry "must disable DNS resolution and prohibit attempted transfers." Your domain still exists and is still recoverable, but it is now a restore rather than a renewal — a different transaction with a different price.

Pending delete, then release. If nobody restores it, the domain goes into pendingDelete, and ICANN states that "after five calendar days following the end of the redemptionPeriod, your domain is purged from the registry database and becomes available for registration" on a first-come, first-served basis. At that point it is not your domain any more. There are businesses that watch for exactly this and register dropping names the second they are released.

Add it up and the outside edge is generous — a month or more of grace in most cases. The trouble is that the clock starts on a day you were not told about, in an inbox you were not reading, and the first thing you personally notice is the blackout, which happens near the end rather than the beginning.

Renewing is cheap. Restoring is a different price.

The honest thing to say about money here is that we will not quote you a figure, because the figures are set by each registrar and change. What we can tell you is the shape: a renewal is priced like an ordinary year of the domain, and a restore out of the Redemption Grace Period is a separate fee on top, and it is not in the same league. Businesses are routinely shocked by it, and the shock is the reason people delay, and the delay is the reason some of them lose the name.

You are entitled to know your own numbers in advance, and this is genuinely useful leverage. ICANN requires registrars to make "their renewal fees, post-expiration renewal fees (if different), and redemption/restore fees reasonably available" to registrants — "at a minimum, these fees must be clearly displayed on the registrar's website," and registrars must also ensure they are displayed on their resellers' sites. So before you get on the phone, find that page. If a reseller cannot tell you what a restore costs, that is a bad sign about the reseller rather than an unanswerable question.

One more right worth knowing, because it comes up the moment someone is annoyed at their registrar and wants to move. ICANN is explicit that you can transfer an expired domain: "Registrars are not allowed to deny a transfer due to expiration or non-renewal." But there is a hard limit on that — once the domain has reached the Redemption Grace Period, ICANN states "the name must be restored by your current registrar before it can be transferred." Fix it where it is first, then move it later if you still want to. Trying to escape mid-crisis just burns days you do not have.

And if your registrar simply will not let you redeem a domain that is inside the 30-day window, that is not a dead end either — ICANN publishes a domain renewal complaint form for precisely this, and notes that a registrar refusing "may be in breach of the Expired Registration Recovery Policy."

Why you never saw a single warning

Everyone we help with this says the same thing: nobody told us. Usually somebody did. Here are the four ways the message misses, in the order we see them.

The notices go to the domain's contact address, not to you. ICANN is specific that the reminders are "sent to the registrant email address listed in the official contact information of the domain name." That address was typed in once, years ago, possibly by somebody else, and it is frequently not an address anyone still opens.

That address is often on the domain that just died. This is the trap with real teeth. If the registrant contact is info@yourbusiness.com, then the moment the DNS interruption starts, the mailbox that is supposed to receive the rescue instructions is unreachable. And the policy requires an additional notice "within 5 days after expiration" that "must include instructions for restoring the registration" — sent, like all the others, to that same address. The single most valuable message in the sequence is the one guaranteed not to arrive. Put your registrant email on a completely different domain: a personal Gmail, an Outlook address, anything that does not depend on the thing it is warning you about.

The contact is the person who built the site. Web designers, agencies and the nephew who set it up in 2016 very often registered the domain in their own account with their own email. The reminders reach them faultlessly. Whether they still read that inbox, still work in that field, or still have any relationship with you is another matter. If the lookup shows a registrar you have never heard of, this is usually why.

The card behind auto-renew expired. Auto-renew was on and did its job for years, then the card was reissued with a new expiry date and the charge failed. The failure notice went to the address above. This is the same failure mode that catches seasonal businesses on every other subscription they own, and it is worth checking on the same afternoon as the rest of them.

What is happening to the mail people send you while this is going on

The website being down is visible and everybody understands it. The email is worse and quieter, so it is worth being clear about what is actually happening.

When the DNS entry for your domain is disabled, other mail systems can no longer look up where your mail is supposed to go. They are not "holding" your mail out of politeness. Depending on the sending system, the person who wrote to you gets a bounce message or a delayed-delivery warning, or in some configurations nothing obvious at all — but in no case should you assume a backlog is waiting to pour in once you fix it. Mail sent during the outage may simply not exist any more.

That is why this is a same-day problem rather than a this-week problem, even for a business whose website barely matters. Quote requests, purchase orders, appointment confirmations, invoices from suppliers and replies from customers are all failing silently at the other end, and the senders may conclude you have gone out of business rather than that you have a technical fault.

It also breaks the things that hang off email without anyone thinking of them as email. Password resets to a mailbox on that domain cannot arrive. Two-factor codes sent to those addresses cannot arrive. Any service whose account is registered to an address on the dead domain is, for the moment, unrecoverable. Which produces the worst version of this call: somebody spends the afternoon fighting with account recovery on five different services, when the only thing that needed fixing was one renewal, and the recovery emails would all have started working again the moment it went through.

The first hour, in order

Rule out the boring alternatives first, in about sixty seconds. Try the site from a phone on mobile data rather than the office Wi-Fi. If the site loads for someone on the other side of town but not for you, the problem is your own internet or DNS, not the domain.

Look the domain up at lookup.icann.org. Read the status codes and note the registrar's name.

Log in to that registrar directly — by typing its address yourself, not by clicking a link in any email about this. If you cannot log in, use the registrar's own account-recovery process, and be ready to prove you are the registrant. Expect this to be the slow part if the account was set up by someone else.

Pay whatever the domain needs — renewal if it is still in a renewal window, restore if it is in redemption. Do it before negotiating anything, moving anything, or arguing about anything. The clock does not pause while you sort out who was supposed to be handling this.

Then wait a bit, and check in the right order. Once the payment goes through, the registrar has to lift the hold and the registry has to publish the change, and the rest of the internet picks it up over the following minutes to hours. Email usually starts flowing before you can be sure the website is back, because your own browser may be holding a cached failure. Check from a device that has not tried the site recently.

Then verify the settings survived. This is the step people skip. After a restore in particular, check that the domain still points where it should: the records for the website, and — separately — the MX records that direct your email. If a restore came back with a registrar's default settings instead of yours, the domain will resolve perfectly while your email goes to the wrong place entirely, which looks like a brand new problem and is really the tail end of the old one. If you do not know what those records should say, your web host and your mail provider each publish theirs.

Do not, whatever else happens, buy a similar domain and start over. We have seen a business register yourbusinessinc.com in a panic, print it, and hand the original away for good. The old name still had three weeks of recovery left on it.

When both go down together and it is not the domain

Two other situations produce the same joint outage, and it is worth ruling them out so you are not paying to renew something that had not expired.

The first is a single provider running both. Plenty of small businesses have the website and the mailboxes on the same hosting account, at one company, on one server. If that server or that company has an outage, both go down together and the domain is entirely fine. The tell is that the domain's lookup shows no hold and a comfortable expiry date, and the provider usually has a status page saying so.

The second is a change somebody made. A website migration is the classic: the site is moved to a new host, the nameservers are switched over, and the email records do not come across, because MX records live in the same DNS settings and do not travel automatically. The website comes back on its new home looking perfect and the email quietly dies. If your outage started within a day or two of anyone touching the hosting, start there rather than with the domain.

The third, briefly, is the one nobody wants: an account compromise at the registrar, with the domain pointed somewhere else deliberately. It is far rarer than an expiry, and the lookup usually shows it — a changed registrar or changed nameservers with no expiry problem at all. If that is what you are seeing, treat it as a security incident, lock down the email account that controls the registrar login first, and call for help.

The scam that shows up on exactly this week

Domain expiry has an unusually large fraud industry attached to it, and the reason is simple: notices about your domain are the one category of message where a genuine version really does arrive, really is urgent, and really does ask you to pay.

So you will see official-looking "domain expiration notice" emails and even printed letters, some of them technically soliciting a transfer rather than a renewal, priced far above the going rate and addressed with information about your domain that is publicly available and therefore proves nothing. And in the week you are actually dealing with a real expiry, they land in a mind that is primed to believe them.

The rule is the same one that defeats every fake invoice: never act from the message. Go to the registrar you already have — the one the ICANN lookup named — by typing its address yourself, log in, and see what the account says you owe. If your real registrar wants money, it will be there. If it is not there, the letter is somebody else's business model.

One further reason to move quickly rather than to wait and see: a domain that completes the cycle and drops is registered by whoever wants it. Businesses have watched their name of fifteen years reappear a week later as an advert-covered parking page, or worse, as a copy of their own site. Recovering it at that point is a negotiation, not a renewal.

Making sure it cannot happen again

This is a solved problem, and the fix takes about twenty minutes once. Do it on a calm day.

Move the registrant email off the domain. The most important item on this list, for the reason explained above. Set the domain's contact address to something independent that a real person reads.

Turn auto-renew on and check the card behind it. Then check the card's expiry date, and if it expires before the domain does, fix that now. Consider paying the domain for several years at once, which is usually cheap and removes the annual failure point altogether.

Make sure the business owns the domain. The registrant should be the business and the registrar account should be in the business's name, with the owner able to log in. Your web designer can have access; they should not have sole possession. This is the single most common structural problem we find, and the moment to fix it is now, while everyone is on good terms — not during a redesign, a dispute, or a sale of the business.

Turn on the registrar's lock and put two-factor on that account. The registrar login is the master key to your entire online presence: whoever holds it can move your website and your email. It deserves better protection than your average shopping account.

Write the expiry date in the calendar — the actual calendar the business runs on, with a reminder a month out, owned by a named person. And keep the contact details accurate: ICANN requires registrants to maintain accurate contact information, and an out-of-date record is exactly how the notices go astray in the first place.

Finally, write down where everything lives. One page: who the registrar is, who the web host is, who the mail provider is, and which login controls each. They are three different companies more often than not, and the day you need that page is a day when nobody can think straight.

If it has already gone

If the lookup says pendingDelete, or the domain is showing as available to register, be straight with yourself about where you are. Inside the 30-day redemption window it is a fee and a phone call to your registrar, today. Past that, it is a race you probably cannot win by yourself, and the professional services that chase dropping names exist precisely because it is hard.

What we would do in that position: register the best available alternative immediately so the business has a working address again, get the mail flowing on the new name that same day, and then work through the list of accounts and logins that were tied to the old one — that part is real work and it is better started than delayed. Tell customers plainly what happened; "our domain expired" is a boring, forgivable explanation, and it is much better than customers concluding you have closed.

And keep an eye on the old name. Sometimes it is registered by a speculator and quietly expires again a year later.

If you would rather hand it to somebody

This is a good job to hand over, because most of it is unfamiliar and time-sensitive at the same time, which is the worst combination to be learning on. We do this for businesses across the San Gabriel Valley, Orange County, the Inland Empire and the Coachella Valley: work out which of the three layers has actually failed, deal with the registrar, get the website and the email back, then check the records afterwards so the fix does not come with a second problem attached.

And if nothing is wrong today, the twenty-minute version is worth more than the emergency one — find out who your registrar is, who the registrant is, and what address the reminders are going to, before it is the thing keeping you up. That visit is a lot cheaper than this article's worst-case ending.