Move from explanation to action with the matching DomainCheck.co.uk tools for this topic.
Check whether brand-critical variants are already registered or exposed.
Useful when registrar control and transfer readiness are part of the risk model.
Use a human review path when a hijack or control issue touches a live brand asset.
This article is the incident-response version of the topic. It assumes the worst has already happened and focuses on practical recovery actions. It should not overlap with prevention or warning-signs content, except where a quick explanation is needed to orient the reader.
If your domain has been stolen, speed matters. The first priority is not to argue about how it happened. The first priority is to stop further damage, preserve evidence, and regain control through the correct support channels.
The exact recovery path depends on the extension, the registrar, and the point of compromise. For some domains, the registrar can reverse an unauthorised action quickly. For others, you may need to go through additional dispute or registry processes. There is no single universal fix, and recovery is not always instant.
Secure email, hosting, and any connected admin accounts first.
Keep alerts, timestamps, screenshots, and support emails intact.
Contact the registrar with a clear incident summary and proof.
Start with the accounts that can be used to reset access. If the registrar login email is compromised, lock that down first. Change passwords, revoke active sessions, and enable stronger two-factor authentication on every relevant mailbox.
Also check:
If the attacker still controls one of those systems, they may be able to keep moving through the environment even if you recover the registrar account later.
| Action | Why it comes first | Expected outcome |
|---|---|---|
| Secure email | It is often used to reset other accounts | Cuts off an easy recovery path for the attacker |
| Contact registrar | They control the domain state | Starts the official recovery process |
| Preserve evidence | Supports escalation and dispute handling | Makes the incident easier to verify |
| Check DNS and hosting | The attacker may have changed service routing | Helps you restore the site safely |
Use the registrar’s security, abuse, or support channel as soon as possible. Be clear that the domain has been taken over without authorisation and that you need the case escalated urgently.
Have the following ready:
Be precise, factual, and short. Support teams work faster when they have a clear incident summary instead of a long explanation with no timeline.
Do not delete alerts, invoices, transfer emails, or login notices. Save screenshots, message headers, timestamps, and any public registration data that shows the change. If the domain was used for email or payments, keep records of service disruption as well.
Evidence matters because it helps the registrar, registry, or any dispute process verify what happened. It also helps you explain the incident internally if customers, staff, or partners were affected.
State the domain, the time you noticed the change, what changed, and why you believe it was unauthorised. Avoid speculation unless you can back it up.
A stolen domain can mean several different things. It might have been transferred to another registrar. It might still be at the same registrar but have different nameservers. It might simply have had its contact details changed to block recovery.
That distinction matters because the recovery route differs. A transfer issue may need registrar escalation or a formal dispute route. A DNS-only hijack may be reversed more quickly once access is restored. If you are unsure, ask the registrar to confirm the current status of the domain.
Once the registrar or registry confirms the domain is back under your control, review the DNS records carefully before putting traffic back to normal.
Check:
If the site or email was altered during the incident, restore from known-good backups rather than editing blindly. A rushed repair can leave behind hidden damage.
After recovery, change passwords and revoke sessions across every connected service. That includes the registrar account, email, hosting, DNS, and any third-party tools with domain permissions.
If the domain was stolen through social engineering or reused credentials, assume the attacker may have learned more than one password. Rotate credentials rather than only fixing the one that was obviously exposed.
If the domain handles customer email, payments, or live traffic, tell the relevant teams quickly. Depending on the impact, that may include support, sales, finance, legal, or management.
If customers or partners may have received suspicious emails during the incident, warn them not to trust messages sent from the domain while the compromise was active. The exact wording should be accurate and calm. Do not guess at facts you cannot confirm.
For business-critical domains or high-value brands, it may be sensible to involve legal counsel, cyber incident support, or your insurer if you have relevant cover. For a .uk domain, the registrar’s process and any registry-related support route may differ from a gTLD such as .com, so follow the provider-specific path rather than assuming a universal one.
This is not legal advice, and not every case needs formal escalation. But if the loss affects revenue, customer trust, or regulated communications, treat it as a serious business incident.
Once the immediate incident is resolved, use it to close the gap that allowed the takeover.
Typical follow-up actions include:
If a domain was stolen once, assume it will be targeted again if the same weaknesses remain.
Do not assume the problem will resolve itself. Do not keep changing settings without a record. Do not trust an email claiming to be from support unless you verify the sender through official channels. And do not publicise guesses about the attacker before you have the facts you need.
The objective is controlled recovery, not panic. A clear timeline, strong evidence, and rapid escalation usually matter more than making frequent changes in the first hour.
Use the incident to fix the weak point that made the takeover possible. If you only restore the domain and leave the process unchanged, you are likely to repeat the same failure.