Summary. This checklist turns domain name security and hijacking recovery into ordered, check-off tasks for in-house counsel, IT and security teams, and outside lawyers. The prevention phases cover building an inventory with clear ownership, securing the registrar, email, and phone accounts that control each name, using registry and registrar locks, managing renewals and expiration windows, and putting domain control terms into vendor and employee agreements. The response phases cover the first hours after a hijacking, evidence preservation, notifications, and each recovery channel from registrar reversal and the Transfer Dispute Resolution Policy to the UDRP, the in rem ACPA action with a temporary restraining order, and claims against an identified person. Red-flag boxes, a deadlines table, a short worked example, and common failure points round out the checklist. Each item links to governing authority where one exists and to related MC Law guidance.

A company's domain name is the address for its website, the identity behind its email, and the anchor for password resets across dozens of other services. Losing control of it, even for a day, can mean diverted payments, phished customers, and a business that cannot send an invoice. Most domain thefts exploit ordinary weaknesses: a registrar account protected by a text message, a registrant email address on a domain that expired years ago, or a developer who registered the name in a personal account. Each of those weaknesses has a specific fix, and each is on this list.

How to use this checklist

The checklist has two halves. Part A (Phases 1 to 6) is prevention: work through it once for the whole portfolio, then review it annually and whenever a domain, vendor, or administrator changes. Part B (Phases 7 to 12) is response: keep it printed or offline, because during a hijacking you may not have access to your own email or intranet.

Assign an owner to each item. In most companies, IT or security owns the technical items, legal owns the contract and dispute items, and finance owns renewals and payment methods. Items marked [Legal] need a lawyer's judgment.

For the doctrine behind the recovery items, see Stolen Domain Names: How Domain Hijacking Happens and the Legal Paths to Getting One Back. For the full step-by-step narrative with timing and cost, see Recovering a Hijacked Domain Name: A Practical Guide. The letters, declarations, policies, and pleadings referenced below are in Domain Recovery Toolkit: Registrar Demands, Transfer Dispute Filings, and In Rem Complaints.

Part A: Prevention

Phase 1: Inventory and ownership

  • List every domain the organization uses or owns. Include primary brand names, product names, defensive registrations, typo variants, country-code names, campaign microsites, email-only domains, and names used by subsidiaries. Pull lists from every registrar account, from DNS hosting, from certificate transparency logs, and from finance records of registrar charges.
  • Record, for each name: registrar, reseller (if any), registrar account holder, registrant of record (name, organization, email), administrative and technical contacts, creation and expiration dates, status codes, name servers, DNS host, and whether registry lock is active.
  • Rank each name by criticality. Tier 1: names that carry email, customer logins, payments, or the primary brand. Tier 2: active marketing and product names. Tier 3: defensive names. Tier 1 names get every control on this list.
  • Confirm that the organization, not an individual, is the registrant of record. [Legal] If a founder, employee, contractor, or agency is listed, obtain a written assignment or confirmation that the name was registered for the organization, and update the registrant record. A domain registration is not a copyrightable work, so the work-made-for-hire definition in 17 U.S.C. § 101 does not settle ownership; contract and agency principles do.
  • Match domains to trademarks. [Legal] For each Tier 1 and Tier 2 name, note whether the organization owns a registered or common law mark that matches. The UDRP and the in rem action under 15 U.S.C. § 1125(d)(2) are available only to mark owners. Consider registering key marks to open those paths. For foreign coverage, see International Trademark Filing Strategy Checklist: A Practical Checklist.
  • Keep ownership evidence in one place. Registration confirmations, renewal invoices, account statements, historical registration records, and trademark certificates. This file is what a registrar, panel, or judge will ask for.
  • Consolidate registrars. Fewer registrars means fewer accounts to secure. Choose registrars that offer registry lock, hardware-key authentication, named account roles, and a reachable security team.

Red flag: the registrant email is on a domain you do not control. If the registrant or account email for a valuable name is at a former agency's domain, a personal webmail account, or any domain that could lapse, a stranger who registers or takes over that email domain can reset your registrar password. Fix this first.

Phase 2: Account security for the registrar, email, and phone

  • Use a company-owned registrar account with named individual administrators (at least two) and role-based permissions. No shared logins.
  • Require phishing-resistant multifactor authentication (hardware security keys or passkeys) on the registrar account. Disable SMS and voice codes as both a second factor and a recovery method.
  • Secure the email accounts that receive registrar notices and resets with the same strength of authentication. Remove unknown forwarding rules and recovery addresses. Review admin audit logs quarterly.
  • Use a role address on a company-controlled domain (for example, domains@yourcompany.com) as the registrant and account email, routed to more than one person, and never let that domain lapse.
  • Add carrier protections to any phone number tied to the accounts. Request a port-out freeze or account PIN from the mobile carrier. The FCC's 2023 SIM-swap and port-out rules in its customer privacy regulations at 47 C.F.R. Part 64 require carriers to authenticate SIM change and port-out requests securely and notify customers, but the FCC waived the compliance deadline in 2024, so ask your carrier what it actually does.
  • Store registrar credentials and recovery codes in an enterprise password manager with access logging.
  • Enable all registrar notifications for logins, contact changes, auth code requests, lock changes, and transfer requests, and route them to the role mailbox.
  • Restrict API keys at the registrar and DNS host to named systems and IP addresses, and rotate them on staff departures.
  • Remove departed staff and vendors from registrar, DNS, and email admin access the day they leave. Add this to offboarding checklists.

Red flag: registrar support will reset your account by phone. If your registrar's support team will change the account email or disable multifactor authentication on a phone call with a few security questions, that is your weakest point. Ask the registrar to flag the account for enhanced verification, or move the name.

Phase 3: Registry and registrar locks, DNS integrity

  • Turn on registrar lock (clientTransferProhibited, and where available clientUpdateProhibited and clientDeleteProhibited) for every name.
  • Turn on registry lock for Tier 1 names where the registry and registrar offer it. Registry lock sets server-level statuses (serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited) that cannot be removed from the customer account; changes require out-of-band verification with named individuals. Record the verification contacts and passphrases securely.
  • Verify lock status quarterly using an RDAP lookup and record the result.
  • Enable DNSSEC where the registrar and DNS host support it, and document key management.
  • Monitor DNS records for unexpected changes to name servers, MX, and other key records, with alerts to security.
  • Audit for dangling DNS records (subdomains pointing to decommissioned cloud resources or third-party services) and remove them.
  • Limit who can change name servers at both the registrar and DNS host.

Phase 4: Renewals and expiration

  • Turn on auto-renew for every name you intend to keep, with a valid corporate payment method and a backup method.
  • Register Tier 1 names for the maximum available term (often ten years for .com).
  • Calendar expiration dates in a system that does not depend on one person's inbox.
  • Know the post-expiration windows. ICANN's Expired Registration Recovery Policy requires registrars to send reminders before and shortly after expiration and to interrupt resolution after expiration so the registrant notices, and it preserves a renewal window. Many generic top-level domain registries then offer a Redemption Grace Period (commonly 30 days) for restoration at a higher fee, followed by a short pending-delete period. After the name drops, drop-catching services re-register it within seconds, and a registrar that simply registered it to a new customer is generally not liable, Rigsby v. GoDaddy Inc., 59 F.4th 998 (9th Cir. 2023).
  • Check renewal payment failures immediately. Treat a failed renewal charge as an incident.
  • Do not let old email domains lapse if any account (registrar, bank, cloud, social media) still uses an address on them.

Red flag: a domain you sold or retired still appears in account records. Any account that resets through an email address on a domain you no longer control is exposed. Change the address before you let the domain go.

Phase 5: Contracts with vendors, developers, and employees

  • Add a domain control clause to every web development, agency, hosting, and marketing agreement. [Legal] It should require registration in the client's name and account, state that any domain the vendor registers for the client is held as the client's agent and is the client's property, require transfer and delivery of auth codes on request and at termination within a short period, prohibit using the domain as security for fees, and require cooperation in recovery. The toolkit contains a model clause.
  • Add domain and account return obligations to employee and contractor agreements and offboarding. [Legal]
  • Review existing vendor-held names and move them into the company's account now, while relationships are good.
  • Require vendors with registrar or DNS access to meet your security standards (hardware-key MFA, named accounts, prompt revocation). See Vendor Cybersecurity Diligence Checklist: A Practical Checklist.
  • In acquisitions, diligence the target's domains (registrant of record, registrar accounts, locks, vendor-held names) and require transfer at closing.

Phase 6: Incident readiness

  • Write a one-page domain incident playbook with the registrar's security and abuse contacts (phone and email), registry lock verification contacts, DNS host contacts, the insurer's notice contact, outside counsel, and a forensic firm. Keep a printed copy.
  • Read the cyber and crime insurance policies for notice deadlines, panel vendor requirements, and coverage for cyber extortion, social engineering, funds transfer fraud, and business interruption. [Legal] See D&O and Cyber Insurance Review Checklist.
  • Pre-draft the registrar demand letter and ownership declaration from the toolkit, with the ownership evidence attached, so they can be sent within an hour.
  • Identify counsel admitted or able to appear in the registry's district (for .com and .net, the Eastern District of Virginia) for an in rem action. [Legal]
  • Decide in advance who may approve a buy-back payment, and require insurer notice and a sanctions screen before any payment. See Ransomware Readiness and Response Checklist: A Practical Checklist for the parallel payment controls.
  • Tabletop the playbook annually, including a scenario where the registrar account email itself is compromised.

Part B: Response

Phase 7: The first hours

  • Classify the event using the table in Recovering a Hijacked Domain Name: A Practical Guide: DNS hijack, account takeover before transfer, pending transfer, completed transfer, lapse and re-registration, or insider holding.
  • Secure the email account that resets the registrar account: new password, phishing-resistant MFA, sign out all sessions, document and then remove unknown forwarding rules and filters.
  • Secure the phone number: call the carrier, report any SIM swap or port, restore the number, and add a port freeze.
  • Call the registrar's security, abuse, or fraud team (not general support). Ask them to freeze the account, restore registrant data and locks, deny any pending transfer on fraud grounds, and preserve logs. Get a ticket number and written confirmation.
  • If the DNS was changed, restore the records from a known-good copy and lock the DNS host account.
  • Warn people at risk. Customers, vendors, and banks should not act on payment instructions or links from the domain until further notice.
  • Start an incident log with times, people, calls, and actions.

Red flag: a transfer is pending. A pending inter-registrar transfer can often still be denied by the losing registrar within the Transfer Policy's short window. This is the single most valuable call you will make. Make it before anything else on this list except securing the email.

Phase 8: Evidence preservation

  • Capture the current RDAP record (registrar, dates, statuses, name servers) with date and time.
  • Obtain historical registration records showing the organization as registrant before the theft.
  • Capture DNS records and passive DNS history showing when records changed.
  • Collect all registrar notices (login alerts, contact changes, auth code requests, transfer confirmations), including from trash, with full headers.
  • Export email and identity provider security logs showing unauthorized logins.
  • Request carrier records of SIM changes or ports.
  • Capture the hijacked site (URL, date, time, capture method) and Internet Archive captures of the legitimate site.
  • Assemble ownership proof from Phase 1.
  • Document harm: phishing reports, diverted payments, lost sales, response costs (needed for the CFAA's loss threshold, 18 U.S.C. § 1030(g)).
  • Hash and log every item, recording who collected it and how, so it can be authenticated under Fed. R. Evid. 901 or certified under Fed. R. Evid. 902(14). See Authenticating Website Evidence: A Practical Checklist.
  • Send written preservation requests to the losing and gaining registrars, the email provider, and the carrier.
  • Issue an internal litigation hold. [Legal] Loss of relevant electronic information after litigation is anticipated can bring measures under Fed. R. Civ. P. 37(e). See Litigation Hold and Evidence Preservation Checklist: A Practical Checklist.

Phase 9: Notifications

  • Notify the cyber and crime insurers within the policy's notice period, before incurring significant costs or making any payment. [Legal]
  • Use insurer-approved vendors where the policy requires them.
  • File an IC3 complaint with the FBI and keep the confirmation. If customers wired funds, give them the complaint number for their bank recall requests.
  • File a local police report if a report number is needed.
  • Assess breach notification duties if the intruder accessed email or systems containing personal information. [Legal] See Responding to a Data Breach: The First Seventy-Two Hours.
  • Prepare a holding statement for customers and staff that describes what you know and what they should do, without speculation.

Phase 10: Recovery channels

Work these in parallel where the facts justify it.

Registrar channel

  • Send the losing registrar a written demand with an ownership declaration and evidence index, asking it to contact the gaining registrar through its Transfer Emergency Action Contact (TEAC) and request reversal. [Legal]
  • Send the gaining registrar an abuse report with the same evidence, asking for a hold pending review.
  • Contact any reseller between you and the registrar.
  • Escalate to ICANN Contractual Compliance if a registrar ignores abuse reports or TEAC communications.
  • Ask the losing registrar to file a TDRP request if reversal is refused. Only registrars may file; requests generally must be filed within twelve months of the alleged violation. Offer to prepare the record and cover fees. Cite the version of the Transfer Policy and TDRP in force on the transfer date.

UDRP channel

  • Confirm trademark rights (registered or provable common law) matching the domain. [Legal] No mark, no UDRP.
  • Draft the complaint around the theft: no rights or legitimate interests in a name obtained by unauthorized access; the current registrant's acquisition as the relevant bad-faith registration; use for phishing or sale as further bad faith. See Filing a UDRP Domain Name Complaint: A Practical Checklist.
  • Watch for the registrar lock after the provider's verification request, and report any movement of the name.
  • Calendar the ten-business-day implementation period after a decision, during which the respondent may file suit under UDRP paragraph 4(k). A court gives the panel's decision no preclusive effect, Dluhos v. Strasberg, 321 F.3d 365 (3d Cir. 2003).

In rem channel

In personam channel

Buy-back channel

  • Get insurer consent and run a sanctions screen before any payment; OFAC's cyber-related sanctions are at 31 C.F.R. Part 578. [Legal]
  • Pay only through reputable escrow that releases funds after the name is in your account.
  • Document the transaction and obtain a release from any purported good-faith holder.

Phase 11: After recovery

  • Move the name into the company-owned account and confirm registrant data.
  • Apply every Phase 2 and Phase 3 control, including registry lock.
  • Rotate all credentials and API keys for registrar, DNS, and email.
  • Audit the rest of the portfolio for the same weakness that allowed the theft.
  • Submit loss documentation to the insurer and, if there is a prosecution, a restitution request under 18 U.S.C. § 3663A. See Crime Victim Toolkit: Notice Requests, Impact Statements, Restitution, and Claims.
  • Write a post-incident report and update the playbook.

Phase 12: If you are on the other side

  • Registrar receiving a theft report: route to abuse or compliance, respond to TEAC requests on time, preserve account records, place the name on hold pending review, and comply with court orders.
  • Buyer of a name later claimed as stolen: preserve purchase records, do not move the name, evaluate a return for a release, and pursue the seller.
  • Developer or agency holding a client's name: transfer it and pursue any unpaid invoice separately.
  • Registrant accused of theft who lawfully acquired the name: preserve records, respond promptly, and in a UDRP proceeding document rights or legitimate interests; consider a reverse domain name hijacking request if the complaint is abusive.

Deadlines and timing table

Event Deadline or typical timing Source
Losing registrar's window to deny a pending inter-registrar transfer Five calendar days ICANN Transfer Policy
TEAC response to another registrar Four hours ICANN Transfer Policy
TDRP filing Generally within twelve months of the alleged violation Transfer Dispute Resolution Policy
Redemption Grace Period after deletion Commonly 30 days where the registry offers it Registry agreements and ERRP
UDRP implementation after decision Ten business days, unless suit is filed UDRP paragraph 4(k)
Ex parte TRO duration Fourteen days unless extended for good cause Fed. R. Civ. P. 65(b)(2)
CFAA civil action Two years from the act or discovery of damage 18 U.S.C. § 1030(g)
Stored Communications Act civil action Two years from discovery or reasonable opportunity to discover 18 U.S.C. § 2707(f)
Cyber insurance notice Per policy; often "as soon as practicable" Policy terms
Service of process after filing (domestic) 90 days Fed. R. Civ. P. 4(m)

ICANN policy periods will change: the GNSO Council approved Transfer Policy Review recommendations in March 2025 (including a mandatory 30-day post-transfer restriction and the end of the 60-day change-of-registrant lock), and they take effect only after ICANN Board adoption and implementation. Check the current Transfer Policy before relying on any period in this table.

Short worked example

Northfork Analytics, a 40-person software company, runs this checklist in January. Phase 1 shows 22 domains across four registrars. Its primary domain, northfork.ai, is registered to a former co-founder personally, and two product domains list an email at the design agency's old domain, which expired last year. Phase 2 shows SMS codes on the main registrar account.

Northfork's general counsel gets a signed assignment from the former co-founder and has the registrant updated. IT re-registers the agency's old email domain defensively (cheaper than the risk), changes the contact email on the two product domains to a role address, consolidates all names at one registrar that offers registry lock, and issues hardware keys to two administrators. Finance turns on auto-renew with a corporate card and a backup. Legal adds the domain control clause to the agency's renewal agreement and to the website vendor template. The playbook goes in a binder.

In August, a phishing email imitating the registrar captures an administrator's password. The attacker cannot complete login without the hardware key, and the registrar's login alert goes to the role mailbox. IT rotates the password within the hour. Nothing else happens, which is the point.

Common failure points

  • No one knows who the registrant of record is until the day the name is gone.
  • SMS-based authentication on the registrar or the email that resets it.
  • Registrant email on a lapsed or third-party domain.
  • Registry lock skipped on the one name that carries email and payments.
  • Calling general support during an incident and waiting in a queue while a transfer completes.
  • Evidence not preserved before the registrar purges logs or the thief changes the site.
  • Filing the UDRP without a mark, or filing in rem in the wrong district.
  • Paying a thief without insurer notice, a sanctions screen, or escrow.
  • Recovering the name and changing nothing, so the same weakness is exploited again.

This document is general information, not legal advice for any particular situation; ICANN policies are being revised, and registrar and registry practices differ.

Related Documents

Related Articles

Related Guides

Related Checklists

Related Toolkits