Prevent Domain Hijacking and Spoofing: A UK Business Playbook

Domain hijacking means someone gains unauthorised control of a domain's registration or associated management. Spoofing means an attacker imitates an identity, such as forging an email sender or operating a lookalike website. A business can suffer spoofing even while its own domain remains completely secure.

Separating these threats makes the response more effective. A password reset can help with a stolen account, but it will not remove every lookalike domain. DMARC can reduce exact-domain email impersonation, but it does not recover a stolen registration.

Know what you are protecting

Document the registrar, registrant, authoritative DNS provider, web host, email platform and recovery contacts for each important domain. Note the services that rely on it, including staff sign-in, payment notifications and password-reset email.

The business should control its own registration. If a developer or agency manages it, establish the registrant and access arrangements clearly. An account held solely under a former contractor's personal details can become an operational problem even without a criminal attack.

Maintain a secure copy of the zone and important account identifiers. These records help support distinguish an authorised change from an attempted takeover during a stressful incident.

How attackers gain access

Phishing can imitate a renewal notice, registry warning or hosting invoice and lead staff to a false login page. Reused passwords can turn an unrelated breach into registrar access. A compromised administrative mailbox can expose password resets and verification messages.

Social engineering may target the supplier's recovery process rather than the password itself. Expired registrations create another risk: once a name becomes available, a new registrant may acquire it through ordinary registration rather than hacking the previous account.

Do not assume published contact-data privacy prevents these attacks. It may reduce some exposed information, but it does not replace strong authentication or reliable renewals.

Secure the accounts that control the domain

Use a unique password stored in a reputable password manager and enable multi-factor authentication where supported. Protect the administrative email account at least as carefully as the registrar account, because it is often part of recovery.

Keep recovery codes securely outside the account they recover. Review who has access, remove former staff promptly and use named users or delegated roles where available. Shared administrator passwords make attribution and safe offboarding harder.

Use a recovery address that remains accessible if the domain itself stops resolving. A domain that can only be recovered through email hosted on that same failed domain creates a dangerous dependency.

Use the right locks and change controls

Registrar transfer locks and registry-level locks can restrict particular changes, but their scope varies by suffix and product. Ask what each lock blocks and how authorised changes are approved. A lock designed to restrict transfers may not prevent DNS edits made through a compromised account.

For critical domains, consider whether a supported higher-assurance change process is appropriate. Keep the approvals and emergency contact route documented so protection does not become an unmanageable obstacle during a legitimate repair.

As reviewed on 30 October 2026, .uk registrar changes still use the current Nominet legacy process. Future standardisation is announced for 9 February 2027. Use suffix-specific instructions rather than treating every domain as an ICANN EPP-code transfer.

Prevent expiry becoming an incident

Assign a renewal owner and a backup. Track the expiry independently, keep the payment method valid and verify that reminders arrive. Check the result of auto-renewal rather than assuming a saved card guarantees success.

Monitor domains used only for email, redirects or old product names as carefully as the main website. Their low web traffic can hide their importance to customer accounts or historic communications.

If a name expires, contact the registrar promptly. Recovery rights and timing depend on the namespace and current state. Do not rely on a generic worldwide “grace period” or assume the original name can always be recovered for an ordinary renewal charge.

Authenticate legitimate email

Configure SPF for authorised infrastructure, enable DKIM signing and deploy DMARC with alignment and reporting. Inventory all legitimate senders before enforcing a rejection policy, including e-commerce receipts, customer-support tools and newsletters.

Review reports and real message headers rather than simply checking that records exist. An authenticated message from a compromised authorised system can still be malicious; mail controls and account security support each other.

DMARC does not prevent someone registering a similar spelling or sending under an unrelated domain. Teach staff and customers to check the complete address, and verify unexpected payment-detail changes through an independently known contact method.

Monitor meaningful signals

Watch registration contacts, nameservers, DNS records and security notifications for unexpected changes. Check whether the supplier offers change logs and alerts, and route important notices to people who will act on them.

Website defacement, certificate errors, missing email and sudden traffic changes can be signs of several different faults. They are prompts to investigate, not proof of hijacking. Preserve the exact observations and compare them with authorised change records.

Use independent availability checks for critical services. A website monitor and a DNS monitor observe different layers; neither can fully explain a business-email incident on its own.

Prepare communications before a crisis

Keep supplier phone numbers, contract identifiers and the incident checklist somewhere accessible without the business domain. Decide who can approve urgent registration changes and who can publish a customer notice. A second person should know the process without needing to borrow the primary administrator's password.

For important payment workflows, maintain an independently verified callback procedure. Customers and staff should not rely only on a familiar display name, a padlock symbol or a convincing signature graphic. Each can appear in a fraudulent interaction.

Exercise the plan with a discussion rather than a disruptive live takeover test. Ask how the team would react if domain email failed, a registrar alert appeared, or the usual administrator was unavailable. Fix the missing access and unclear responsibilities discovered by that exercise before an attacker forces the issue.

If control appears to be lost

1. Use a trusted device and independently navigate to the registrar's genuine website.
2. Contact its urgent security or recovery channel and identify the affected domain.
3. Secure the administrative email account and other connected credentials.
4. Preserve registration evidence, notices, timestamps and unauthorised change details.
5. Ask the provider to restrict further changes and use its documented recovery process.
6. Restore verified DNS and service settings after control is re-established.
7. Review related accounts, sessions and payment workflows for further compromise.

For a .uk registration, involve the registrar and follow Nominet's current guidance where escalation is needed. For phishing content or suspicious messages, use the NCSC's current reporting routes. Do not publish customer data or account secrets when seeking assistance.

If the issue is impersonation instead

Capture the lookalike name, message headers, URLs and relevant screenshots without entering credentials or sending money. Report the abuse to the relevant hosting, email or registration provider through its published process.

Inform affected staff or customers through a channel you still control. A factual notice should identify the genuine contact route and explain how to verify requests. Avoid asserting a data breach or blaming a supplier before evidence establishes what happened.

After the incident, close the access path, review recovery arrangements and update the domain inventory. A provider such as telaHosting can be part of your domain administration, but resilience depends on the controls and responsibilities your business actually maintains.