Common Domain Problems and How to Resolve Them

When a website stops loading, the domain is only one possible cause. The registration may be restricted, DNS may return the wrong address or the web application may be failing after a successful connection. Email adds its own routing and authentication requirements.

Start by recording the domain, affected service, error message, time and recent changes. Check registration status and authoritative DNS before editing settings. Avoid making several unrelated changes at once: each can create cached differences that make the original fault harder to isolate.

1. Understand serverHold and clientHold

For domains using EPP status codes, serverHold is set by the registry and clientHold by the registrar. Both can prevent activation in DNS. They are not interchangeable labels for any hosting suspension. ICANN's status-code reference explains their roles.

Use the registrar's status view or relevant registration-data lookup, then read legitimate account notices. Possible reasons depend on the actual domain and provider; do not assume every hold means an unpaid invoice or the same verification failure.

Contact the registrar through a known support route and ask for the specific reason and remedy. A registry-set restriction may require the registrar to work with the registry. Changing hosting or nameservers does not remove a hold. If the notice concerns a dispute or required documentation, follow the stated process rather than inventing a technical workaround.

2. Separate cached DNS from an incorrect zone

After a change, ask the authoritative nameservers for the relevant record. If they still show the old value, check whether you edited the active DNS provider and whether the change saved. A second DNS zone in an unused control panel has no effect on the live delegation.

If the authority is correct but a recursive resolver returns an earlier value, examine TTL and caching. Existing cached entries do not all expire simultaneously. Clearing a device cache affects that device, not every resolver used by your customers.

Lowering an appropriate TTL before a planned move may help future queries refresh sooner. It cannot retroactively shorten answers already cached, and a standard “wait 48 hours” message does not explain every failure. Keep a timestamped record and compare specific responses.

3. Investigate a domain that does not resolve

Check spelling, registration status, delegation and the requested record type. A missing A record is different from an NXDOMAIN response, a timeout or a DNSSEC validation failure. Inspect both IPv4 and IPv6: one can point to the new server while the other still reaches an old destination.

Review DNSSEC when nameservers have changed. A parent DS record that no longer matches the active signing setup can produce failures for validating resolvers. Follow the providers' migration instructions rather than copying or removing security records without understanding their role.

If DNS resolves correctly, inspect the web server, certificate and application. A wrong default page, HTTP error or certificate mismatch is evidence to follow into hosting configuration. Replacing nameservers at that point may break working services without repairing the actual fault.

4. Restore email using the mail provider's records

Check MX records against the actual email service, including priority and hostname. Do not assume every cPanel or DirectAdmin account should use the same MX target. The correct value is account- and provider-specific.

Then review related A or AAAA records where needed, SPF policy, DKIM selectors, DMARC and any provider verification entries. A copied zone can omit one of these even while the website continues working. Preserve existing values before changing them and avoid publishing duplicate SPF policies.

Read the bounce or delivery error. A full mailbox, authentication problem, rejected recipient or sending reputation issue may not be an MX fault. Check local-versus-remote routing settings where your hosting panel uses them, and test sending and receiving separately. Opening arbitrary ports is not a sensible first repair step.

5. Resolve registrar-transfer failures by suffix

A .uk or .co.uk registrar change currently uses the Nominet TAG workflow, while covered generic domains commonly use an authorisation code and applicable transfer checks. Do not apply a generic EPP-code tutorial to every suffix.

For a gTLD, inspect transfer status, the exact authorisation code and any applicable restriction. A client transfer lock is different from serverHold, and some restrictions cannot be removed with an ordinary dashboard switch. Request the stated rejection reason rather than repeatedly resubmitting.

As reviewed on 30 October 2026, Nominet's new standardised policies are scheduled for 9 February 2027. Future instructions should not be presented as the current procedure. Keep DNS and hosting active independently while resolving the registration move.

6. Act promptly on expiry

Expiry and recovery rules depend on the suffix, registry and registrar agreement. Check the exact registration and contact the provider immediately. Do not assume every domain has a thirty-day grace period or that every expired name is either transferable or permanently lost.

Under the current Nominet renewal procedure, an unrenewed domain is suspended after thirty days, renewal is possible up to the specified ninety-day expiry boundary, and deletion occurs at ninety-five days. Act well before any final boundary; registrar processing and the exact expiry timestamp matter.

Those are current .uk rules, not the future 2027 lifecycle and not a schedule for .com. For a generic domain in redemption, ask the registrar about the relevant restoration process and deadline. Waiting for public re-registration risks losing the name to someone else.

A symptom-to-action summary

Prepare a useful support request

Provide the domain, the exact hostname and the affected function: public website, administration, incoming email or outgoing email. Include the time and timezone, a plain description of what changed and the complete non-sensitive error text. If only some visitors are affected, record the resolver or network observations you can safely collect.

Attach relevant read-only query results with their type and responding server. Keep a record of the old configuration privately so a deliberate rollback is possible. Never post registrar passwords, mailbox credentials, private keys or transfer authorisation codes in a public forum.

Can renewing fix every failure? No. Renewal can address expiry when still permitted, but it does not correct a wrong A record, a broken application or an unrelated restriction. Should I transfer a failing domain immediately? A transfer is not a universal repair; identify the state and preserve working DNS and email before changing providers.

Prevent repeat incidents

Use monitored contact addresses, appropriate account protection and renewal reminders owned by the organisation. Keep payment and recovery details current. Auto-renewal is useful but still needs monitoring because a payment can fail or a domain can be excluded from the setting.

Maintain a compact record of registrar, DNS provider, website host and email service. Before a move, export the zone and confirm who will preserve each service. Give support the precise error and observed records while keeping authorisation codes and credentials private. If moving to telaHosting, use the receiving provider's actual instructions rather than guessing its TAG or nameservers.