A site goes down completely. The server is fine, hosting is paid, the domain is not expired. Nothing in any log explains it.
This is one of the causes people do not think to check: the domain has been suspended because the registrant's email address was never verified.
Why it happens
Registrars are required to verify that the registrant's email address is real and reachable. It is triggered when a domain is registered, and again whenever the registrant email is changed, including changes people make casually while tidying up contact details.
A message goes to that address containing a link. If nobody clicks it within fifteen days, the domain is suspended.
Why it gets missed
The message is automated, comes from a registrar or a verification service instead of a person, and reads exactly like the notices everyone ignores. It is also filtered as spam more often than most legitimate mail.
Reminders follow, and they look the same as the first one.
Meanwhile nothing else warns you. The control panel shows the domain as active, the site works, and everything appears normal right up to the day it stops.
What suspension actually does
Not a warning page. The domain stops resolving.
The website is unreachable, and mail to the domain stops arriving, which means the notice explaining what happened cannot reach a mailbox on the same domain. If the registrant address was [email protected], the only route back is one you can no longer receive.
That circularity is why this fault is so much worse than its cause deserves.
Recognising it
dig example.com NS whois example.com | grep -i status
If the domain has no working nameserver answer and the status mentions a hold or suspension, this is what you have. A status such as serverHold or clientHold is the direct evidence.
It rules out the alternatives quickly: hosting problems do not stop a domain from resolving, and expiry shows differently in the registration dates.
Fixing it
Log into the registrar and look for a verification prompt. Most show one and can resend the message.
If the registrant address is unreachable, change it to one that works, which triggers a fresh verification to the new address.
Click the link. Restoration is usually within the hour, sometimes minutes, and no data is lost.
Preventing it
Keep the registrant address off the domain it registers. A separate address, at a provider you do not host, breaks the circularity entirely. This is the single most effective precaution.
Check after editing registration details. Changing the registrant email starts a new verification, and the risk window opens again at a moment nobody associates with risk.
Do not filter registrar mail. There is very little of it and all of it matters: verification, expiry, transfer approvals.
Confirm the address is monitored. A registrant address belonging to someone who left the company is the same problem with a longer fuse.
Related failures that look identical
A domain can also be suspended for expiry, or held for other registrar-side reasons. All of them present as a domain that stopped resolving, and the WHOIS status distinguishes them.
What happens when a domain expires walks through that path, and enabling auto-renewal goes over preventing it, though auto-renewal does nothing about verification, which is a separate requirement with its own timer.
Both are worth checking on every domain you manage, in the same sitting, once a year. The yearly maintenance checklist is where it belongs.
Reading the status precisely
The registry status distinguishes cases that all look like a domain that stopped working, and the distinction decides who can fix it.
whois example.com | grep -i 'status'
serverHold is applied by the registry: frequently the verification case, and it cannot be lifted by your registrar without the underlying issue being resolved.
clientHold is applied by the registrar, usually for non-payment or an account matter, and they can lift it directly.
pendingDelete or redemptionPeriod is expiry rather than verification, with a fee attached. There is more on that path in what happens when a domain expires.
Reporting the exact status when contacting the registrar shortens the conversation considerably, because it tells them which process applies.
Where the verification message goes
Not necessarily to the address you think.
The message is sent to the registrant contact, which on a domain with privacy protection may be a forwarding address maintained by the registrar, and forwarding can fail silently, particularly to addresses that filter automated mail aggressively.
whois example.com | grep -iE 'registrant.*email|admin.*email'
If that shows a privacy-service address, the verification chain has an extra link that can break. Turning privacy off briefly during a registration or a contact change removes that link at the moment it matters most.
Re-verification is triggered by more than you expect
People associate this with registering a domain. Several other actions restart the clock.
Changing the registrant email address. Changing the registrant name or organisation. Transferring the domain to another registrar, on some. And in some cases simply correcting a typo in the contact details.
So a routine tidy-up of contact information can suspend a working domain fifteen days later, with nothing connecting the two events in anyone's mind.
After any edit to registration details, watch for the message and act on it the same day. Managing a portfolio of domains and renewals goes into the record that makes this a checklist item in place of a memory.
What it costs while suspended
Worth stating because it changes how urgently people treat it.
The website is unreachable and mail stops, but two further effects last beyond the suspension. Certificate renewal fails during the period, because validation cannot resolve the domain, so a certificate may expire while the domain is on hold. And mail sent to the domain during the suspension is rejected rather than queued indefinitely, so correspondence is genuinely lost rather than delayed.
Neither is repaired by lifting the hold. Check the certificate immediately afterwards, and expect to ask senders to resend. Checking a certificate from the command line goes into confirming it.