Digital Sovereignty & Network Governance  ·  28 July 2026

The Nominated Contact

A Douglas restaurant lost the web address it had used since 2021, not to a hacker or a squatter, but somewhere inside its own renewal chain. The registry's own rules, read properly, explain exactly what happened and whose inbox was supposed to catch it.
By Alan Wright  ·  The Haunted Lighthouse Limited  ·  Peel, Isle of Man

Refuge Bistro & Bar in Douglas had used refuge.im since 2021 for bookings, menus and contact details. The business name "Refuge" was formally registered in September 2021, and payments for website and domain services had been going to Yellowbush, a local web agency, the whole time.

In May 2026, a renewal invoice from Netcetra, the underlying registrar, came due. The exact date isn't public, but the sequence is clear enough: the invoice was paid, just late enough to miss the deadline, and the domain became available before that payment cleared. Someone else registered it.

On 29 June 2026, NIC.IM published its dispute decision. Owner Robert McAleer had a clean paper trail: years of use, a registered business name, evidence of payment. NIC.IM ruled against him anyway. Under the .im Dispute Resolution Procedure, a complainant has to prove the new registrant's holding is an "abusive registration": squatting, blocking, extortion, deliberate disruption. Prior use and payment only carry weight when the domain lapsed because of a relationship between the two parties, an ex-employee or an ex-agency who owed the domain back, say. A stranger picking up a lapsed domain in good faith doesn't meet that bar, however unlucky the timing. Refuge moved to refuge.co.im.

A follow-up report on 8 and 9 July added a detail the original story didn't have. The Department for Enterprise, responding publicly to the case, pointed out that .im has a 30-day protection window for domains that simply expire, but said this case looked different. Based on what was known, the department said the domain appeared to have been explicitly deleted by the reseller managing it, rather than left to run out the clock. That kind of deletion can stem from non-payment on the reseller's own account with the registrar, a customer instruction, a contractual issue between the reseller and the registrar, or another account-level matter, and none of it is protected by the ordinary expiry grace period, because it isn't an ordinary expiry.

Nobody in this chain has been shown to have acted in bad faith. Yellowbush didn't defraud anyone. Netcetra processed a real payment. NIC.IM applied the rule as written, and the Department for Enterprise gave a straight, technically precise answer when asked. That's what makes it worth writing about a month on rather than as breaking news: this isn't a fraud story, it's a structural one, and the structural part got more specific once the department weighed in.


Why the extra layer is the actual risk

For an ordinary expiry, NIC.IM's own rules (Rule 10.1) are fairly generous: four separate email warnings to "all the nominated contacts" at 60, 30, 5, and 1 day before a domain lapses, plus a full month's grace after expiry before anyone else can register it. That's real protection, over roughly ninety days, but it only works if it's warning the right inbox, and only if what actually happened was an ordinary expiry.

The Department for Enterprise's own account suggests this wasn't one. An explicit deletion, triggered by something on the reseller's side (Yellowbush's account standing with Netcetra, a billing dispute between the two companies, an internal process no customer ever sees), skips past the standard expiry safety net entirely. If that's what happened, Refuge wasn't racing a countdown clock it could have watched from the outside. It may have lost the domain to an action taken on infrastructure it had no visibility into and no ability to monitor, for reasons that had nothing to do with whether its own invoice eventually got paid.

That's the sharper version of the lesson. The risk of delegating a domain isn't only that a renewal reminder might not arrive in time. That version has a fix: better notifications, a tighter internal process. The deeper risk is that the account holding the domain has its own internal life: its own billing relationship with its own upstream registrar, its own account status, its own contractual terms with that registrar. None of that is visible from outside, and any of it can end a registration for reasons that have nothing to do with anything the actual business did or paid.

None of this is specific to .im, either. The UDRP, the policy behind almost every generic top-level domain including .com and .net, uses the same core test: bad-faith registration and use, not who paid longest. Nominet's Dispute Resolution Service for .uk domains, which NIC.IM's own DRP is modelled on closely enough to share most of its section headings, calls it "Abusive Registration" and applies the same logic. A domain that lapses into a good-faith third party's hands, however it lapses, generally isn't recoverable through dispute resolution, in any of these systems. This is a structural feature of how domain disputes work almost everywhere, not a quirk of the Manx registry.

There's a second, quieter lock-in too. NIC.IM's transfer process (Rule 12) requires the current registrant to log into the nic.im account and manually "Unlock" the domain before it can move anywhere. Whoever holds that login is the only party who can act, regardless of who's been paying the invoices. If that account belongs to an agency, the business itself has no direct lever to pull even once it notices something is wrong.

It isn't only a practical gap either. It's written into the contract. NIC.IM's Terms and Conditions (condition 3.4) state that when registering through an agent, "any communication to or from your agent is taken as being to or from you." That's not a courtesy assumption, it's the legal position: a renewal notice delivered to the agent's inbox counts as delivered to the business, whether or not the agent ever passes it on. There's no "we never got it" defence once an agent is on record; the deeming happens at the contract level, before any question of whose fault the actual missed forward was.


Not property, only a registration

There's one more thing worth sitting with in NIC.IM's contract, because it reframes the whole episode. "A domain name is not an item of property and has no 'owner'. It is an entry on our register database" (condition 8). Nobody owns refuge.im, or any other .im domain, in any legal sense; what exists is a registration, maintained under a contract that can be renewed, transferred, or lost according to its own terms.

That distinction has teeth. The same contract excludes NIC.IM's liability for "loss of registration or use... of the domain name, for whatever reason" (condition 25.4.2), and caps any liability that does survive at £5,000 total (condition 27), regardless of what the domain is actually worth to the business running on it. There's no property claim to fall back on, no breach-of-ownership argument, nothing beyond the DRP's narrow abusive-registration test. If a registration lapses, contractually, that's simply what registrations sometimes do.


The case for direct registration

None of this requires running a private DNS setup or writing a bespoke web server; the fix is much narrower than that. It's about who is listed as the registrant and who controls the renewal, independent of who builds or hosts the site.

The clearest benefit is seeing the actual deadline rather than a relayed invoice. Under NIC.IM's own rules, the registry emails the nominated contacts on a domain at 60, 30, 5, and 1 day before expiry. Where that contact field points at the business itself, those four warnings land directly from the registry, not repackaged, delayed, or dependent on a third party's billing cycle passing them on. Auto-renew then becomes a genuine safety net rather than a formality: set against the business's own card, at the registrar, a late invoice from a third party stops being able to sink the domain at all. Worst case, a charge lands that can be queried afterwards.

There's also one fewer markup and one fewer point of failure. Agencies typically resell domains at a margin for the convenience of a single bill, and that convenience carries a cost beyond money: it's one more party whose internal process has to work correctly, on time, for the registration to stay intact. The dispute process, as the Refuge case shows, protects before the fact rather than after it. The .im DRP, like most ccTLD equivalents, is built to catch bad-faith registrations, not to unwind an honest lapse. Once a domain has gone to a good-faith third party, "it was paid, just late" doesn't reliably get it back anywhere, not only under .im. The only real defence is not lapsing in the first place, and that defence is available to anyone willing to spend five minutes registering directly with a registrar, or transferring an existing domain into an account they actually control. It doesn't require dropping a web agency; it just means the domain and the website become two separate relationships, which is what they actually are.


The practical version

Checking who's listed as the registrant on a domain takes a few clicks with most registrars, or is visible via WHOIS. Where it's an agency's name rather than the business's own, that isn't necessarily a problem today, but it's worth knowing before it becomes one. The domain can be transferred into an account the business controls while the same people carry on managing the website, if that arrangement is working well; the two are separable. Put the renewal date somewhere it will actually be seen. That's the whole exercise: no infrastructure change required, just making sure the one date that matters doesn't have to travel through a second company before it reaches the person who needs to see it.


Sources


Cross-reference: The Widgits Pty Ltd Firewall


Questions about this analysis, or interested in working with The Haunted Lighthouse?
consultancy@haunted.lighthouse.co.im

The Sovereign Auditor covers digital sovereignty, cybersecurity governance, and data protection policy, with particular focus on Isle of Man jurisdiction and Crown Dependency issues.

Support independent analysis. Subscribe directly, or scan on your phone.

Payments via PayPal. Credentials delivered by email. No Substack. No Stripe. No middlemen.