Domain security advice usually stops at “turn on two-factor authentication and a transfer lock.” A recent GoDaddy incident is a blunt reminder that those controls protect you from outsiders — and do nothing about the one party that can move your domain with a few clicks: the registrar itself.

What happened

As reported by The Register and others, a Lancaster, PA nonprofit’s main domain — in continuous use for 27 years — was transferred out of its account and into a stranger’s, roughly 2,000 miles away, in a matter of minutes. By the early afternoon the domain sat in the wrong account and its DNS records were wiped, knocking the organization’s website and email offline.

The cause was almost absurdly mundane. An executive assistant named Susan had asked GoDaddy support to help recover an unrelated domain. Her email signature happened to contain a subdomain of the nonprofit’s address. A GoDaddy agent reportedly read the parent domain off that signature, decided it was the one she meant, and queued it for transfer to her account — no ownership check, no documentation. GoDaddy then “considered the matter closed.” The link Susan was later sent to upload supporting documents expired before she could even use it.

The security that didn’t matter

Here is the part worth dwelling on. The victim’s account was not poorly secured. It had dual two-factor authentication — both an email code and an authenticator-app code required to log in — and the domain had ownership/transfer protection enabled. Every control the security checklists tell you to turn on was on.

None of it mattered, because the transfer never went through the front door. It went through GoDaddy’s internal support tooling, which operates above the customer’s own security settings. 2FA stops someone from logging into your account. It does nothing when an agent moves your asset from the inside. The lesson is uncomfortable: for a domain, your registrar’s support process is part of your attack surface — arguably the weakest part — and you don’t control it.

The recovery was the second disaster

Getting it back was its own ordeal. The nonprofit’s IT firm reportedly made 32 calls, spent about 9.6 hours on hold, and sent 17 emails over four days, receiving a fresh case number each time and not a single callback. In the end, the stranger — Susan — had to call GoDaddy herself to reverse it. An accidental, unverified transfer took minutes to execute and days of escalation to undo.

The real lesson: treat your domain as critical infrastructure

A domain is not just a setting; it is the root of your website, your email, and often your identity and password resets. Protect it accordingly:

  • Set a Registry Lock, not just a registrar lock, for high-value domains. A true registry-level lock (EPP serverTransferProhibited / serverUpdateProhibited) requires out-of-band, multi-person authorization to change — it is designed precisely to stop a single support agent or a single compromised account from moving a domain.
  • Use a registrar that matches the stakes. Budget registrars optimize for volume and fast support actions. Critical domains belong at registrars with strict, documented verification and enterprise/registry-lock options.
  • Monitor your own DNS and WHOIS. Set alerts for nameserver, registrant, or DNS-record changes so an unauthorized move is caught in minutes, not when email stops.
  • Have a written recovery runbook — registrar abuse/legal contacts, proof-of-ownership documents pre-assembled, and an escalation path — before you need it. The time to find the emergency contact is not during the outage.

Bottom line

You can do everything right — 2FA, locks, a clean account — and still lose your domain to a tired support agent reading the wrong line of an email signature. The defenses that actually address that failure mode are registry locks and choosing a registrar whose process you trust, not another toggle inside an account that the registrar can reach around at will.

We cover the unglamorous infrastructure risks too. Have a registrar horror story or correction? Reach us via @mrtdnet on Telegram.