How to reverse an unauthorized transfer of a .app domain

How to reverse an unauthorized transfer of a .app domain. UDRP and ccTLD domain recovery and defense across .app. Email the firm to assess your case.

Your .app domain disappeared overnight. The registrar's dashboard shows a transfer-out you never authorized, and someone else now controls a name tied to your application, your users, and your revenue. That is domain theft – and the window to act is narrow.

To reverse an unauthorized transfer of a .app domain, you typically pursue two tracks simultaneously: a registrar escalation to freeze the gaining registrar's account and document the compromise, and either a UDRP complaint at WIPO or a court action, depending on whether the domain now sits with an identifiable bad-faith holder or an unknown party. WIPO handles .app disputes under the UDRP because Google's registry for .app accepts ICANN-accredited arbitration; the standard filing fee starts at USD 1,500 for a single-member panel. Speed is decisive – most transfer windows close within a few days and evidence degrades fast.

This page covers the registrar mechanics, the UDRP and court routes, the evidence that determines which path fits, and the realistic next step if your .app was stolen.

Why .app transfers require special attention

.app is a restricted, HTTPS-only generic top-level domain operated by Google Registry – and that distinction matters the moment a transfer goes wrong. All .app domains require a valid SSL certificate to resolve, which means a thief who gains control can still operate the domain as a functional site almost immediately. Unlike some legacy zones where a hijacked name simply parks or redirects, a stolen .app can impersonate your application convincingly within hours.

Because .app is a gTLD registered through ICANN-accredited registrars, the full UDRP machinery applies. WIPO, the Forum, the Czech Arbitration Court, and ADNDRC all have jurisdiction over .app disputes. The standard inter-registrar transfer policy also applies, which means the 60-day transfer lock that ordinarily follows a registrar change is a rule your losing registrar can invoke – and a rule that worked against you if the thief exploited a registrar change to start that clock.

What sets .app apart from a .com theft is audience risk. Developers, startups, and SaaS companies use .app names as their primary application endpoint. A redirected .app domain can intercept login credentials, OAuth flows, and payment callbacks. The harm is not merely reputational. It is operational and potentially liability-generating. Speed is not merely advisable. It is essential.

What are the first steps after an unauthorized .app transfer?

The first 24 to 48 hours after discovering an unauthorized transfer are the period during which registrar-level remedies remain live. After that window, the trail cools and the procedural options narrow. Act in this order.

First, secure your registrar account immediately. Change your password and enable two-factor authentication, even if it was already enabled. Document every login event your registrar's interface can show you. Screenshot timestamps, IP addresses, and any anomalous activity. This record becomes exhibit A in a UDRP complaint or a court filing.

Second, contact your losing registrar's abuse or security team – not general support – and state explicitly that you are reporting an unauthorized transfer and requesting an emergency transfer freeze. Under ICANN's transfer dispute resolution policy, the losing registrar has a narrow window to raise a dispute. Filing a registrar-level complaint starts that clock in your favor. Request in writing that the registrar submit a Transfer Dispute Resolution Policy complaint or otherwise flag the transfer as unauthorized to ICANN.

Third, identify where the domain now sits. A WHOIS or RDDS lookup – bearing in mind that privacy protection may obscure the registrant – will show you the gaining registrar. Contact that registrar's abuse team as well. Registrars are obligated under ICANN's agreements to respond to credible abuse reports and can place a server-side lock on a domain while a dispute is pending.

Fourth, preserve everything: email headers, authentication logs, any ransom or sale demand you received from the thief, and any DNS change logs your DNS provider can export. This evidence maps directly to the bad-faith indicators under Paragraph 4(b) of the UDRP.

If you have just discovered an unauthorized transfer of your .app domain, the decisions made in the next 48 hours shape every available remedy. For an immediate assessment of your position, contact info@cognomenlaw.com.

How does WIPO handle a stolen .app domain claim?

A WIPO complaint over a stolen .app domain is a UDRP complaint – and it must satisfy all three elements of Paragraph 4(a) of the Policy: confusing similarity to a mark you hold, no legitimate interest on the registrant's part, and bad-faith registration and use. In a theft scenario, the third element is usually the strongest, because the transfer was unauthorized. The second element – legitimate interest – is typically easy to defeat where the domain had been yours and the "new registrant" acquired it through deception rather than a bona-fide registration.

The complication in theft cases is the first element. If your .app domain corresponds to an unregistered mark or a name that is purely descriptive, a panel may decline to find confusing similarity to a protectable right. This is why early legal advice on the trademark posture of your name matters before you file. In our practice, we assess whether a pending or registered mark, a trade name registration, or a combination of common-law rights is strong enough to anchor the complaint.

Theft mechanics also change the bad-faith analysis. A standard cybersquatting panel looks at whether the domain was registered in bad faith. In a theft case, the current registrant may argue it received the domain in good faith from a chain of resale. Panels have consistently addressed this by examining the full chain of transfer and asking whether the registration or use after the theft perpetuates the original bad faith. Respondents who acquire a stolen domain for value are not automatically shielded.

WIPO is our preferred forum for .app theft cases because of its global recognition, its depth of published decisions on domain theft, and its expedited option – which can deliver a decision in approximately one month for single-panel cases of up to five domains. Where the matter is straightforward and the evidence of compromise is documentary, the expedited path is worth requesting.

In a recent matter involving a .app name in the technology sector (spring 2025), we filed a UDRP complaint at WIPO within four days of the client discovering the unauthorized transfer. The registrant – who had acquired the domain after it was moved through two registrars in rapid succession – did not respond. The panel issued a transfer order approximately six weeks after filing, relying on the account-compromise logs and the client's prior registration history as dispositive evidence of bad faith.

When does a court action outperform UDRP for .app theft recovery?

The UDRP offers one remedy: transfer or cancellation. It cannot award damages, freeze assets, compel a party to disclose identity, or impose an injunction against further transfers during the proceeding. For some .app theft scenarios, those limitations make the UDRP insufficient on its own – and a court route, handled with local litigation counsel in the relevant jurisdiction, becomes the necessary complement or alternative.

Consider the decision matrix in practical terms. If the thief is identifiable and located in a jurisdiction with enforceable US anticybersquatting legislation or equivalent national law, a court action reaches money damages for the period of wrongful control. That matters for an application company that can quantify lost subscriptions, diverted payments, or breach of contract claims arising from the domain's unavailability. The UDRP cannot touch any of that.

If the gaining registrar is unresponsive to abuse reports – rare but not unknown – a court order directed at the registrar's corporate entity (where that entity has US connections) can compel cooperation faster than an ICANN complaint. US anticybersquatting litigation has produced injunctive relief against registrars in specific circumstances, and that precedent is known to counsel on both sides.

If the domain passed through multiple parties and you cannot identify the current registrant through RDDS, a court's discovery or pre-action disclosure process is the only mechanism that can compel a registrar to unmask the holder. WIPO cannot order disclosure. This is a structural limitation of the UDRP and a reason courts remain in the toolkit even for gTLD disputes.

The trade-off is cost and time. Court actions are substantially more expensive than UDRP proceedings and measured in months rather than weeks. For a .app domain that represents only modest commercial value, the economics may favor UDRP alone. For an application endpoint serving paying customers, the fuller remedy of a court action often justifies the investment. We assess this trade-off at the outset so you choose the right route from day one.

If you are weighing UDRP against a court action for your stolen .app, the choice depends on your evidence, your jurisdiction, and the value at stake. Email info@cognomenlaw.com for a direct assessment of which route fits your situation.

What evidence decides the outcome of a .app theft claim?

In a domain theft case, the evidence of account compromise is the spine of your claim. A panel or court will look for a documented break in the chain of authorization: proof that you, the legitimate registrant, did not approve the transfer. The standard of proof at UDRP is a balance of probabilities. Courts apply their own standard, but the underlying factual question is the same.

The most powerful evidence in our experience falls into four categories. First, authentication logs from your registrar showing login events from IP addresses or devices that are inconsistent with your normal access. Second, email security logs – particularly any phishing or credential-harvesting messages – that establish the vector of compromise. Third, your original registration history: the creation date, renewal records, and any prior transfer or lock instructions that demonstrate continuous legitimate control. Fourth, any communication from the thief or a broker acting for them, including demands for ransom or offers to sell you back your own domain.

What weakens a theft claim? Gaps in the evidence chain are the primary risk. If your registrar account lacked two-factor authentication and you cannot produce login anomalies, a respondent may argue the transfer was authorized or that you were negligent in account security. Panels have generally declined to treat registrant negligence as a complete defense for a bad-faith acquirer, but it can complicate the bad-faith finding and extend the proceeding. Courts may also examine contributory fault in some jurisdictions.

Secondary evidence matters too: WHOIS history showing the pre-theft registrant, DNS records from before and after the transfer, and any third-party services (CDN providers, DNS hosts, certificate authorities) that can confirm who was the authorized account holder at a given date. We work with clients to assemble this record systematically before filing, because a complete evidentiary package is the single largest predictor of a swift resolution.

In a separate matter involving a .app domain used as a primary API endpoint (late 2024), a client came to us after two weeks of attempting self-help with the gaining registrar. By the time we engaged, one layer of evidence – the registrar's access logs – was no longer retrievable because the registrar's retention window had closed. The case succeeded, but it took an additional submission cycle to compensate for the missing log data. The lesson is direct: preserving evidence is a task for the first 24 hours, not a task for after counsel is retained.

How does the registrar-lock and transfer-reversal process actually work?

The ICANN transfer framework creates several tools that, used correctly, can freeze a stolen domain before a full arbitration or court proceeding is necessary. Understanding how those tools work – and where they fail – shapes the speed of any recovery.

The Transfer Dispute Resolution Policy (TDRP) gives losing registrars the right to challenge a transfer they consider unauthorized. This is a registrar-to-registrar process, not a registrant remedy, but a registrant who places a timely written demand on the losing registrar can trigger that registrar's obligation to evaluate whether to file a TDRP complaint. In practice, this mechanism is underused because most general support teams at registrars are not trained to escalate it. Insisting in writing – citing the TDRP by name – changes the calculus.

Once a UDRP complaint is filed, WIPO notifies the gaining registrar and requests a registrar lock: the domain is held at its current registrar, status-locked, and cannot be transferred further during the proceeding. This interim lock is one of the most practical protections the UDRP provides. Filing quickly therefore serves two functions: it starts the adjudication and it freezes the domain in place.

For domains that have already passed through two or three registrars in rapid succession – a pattern designed to complicate recovery – the lock attaches to the current holder. The prior chain of transfers does not prevent the lock. It may, however, complicate service of the complaint if the current registrant identity is obscured. WIPO has procedures for commencement where WHOIS data is incomplete or privacy-protected, and panels have noted that deliberate concealment of registrant identity is itself a factor consistent with bad faith.

Where the gaining registrar is cooperative and the evidence of unauthorized transfer is documentary and immediate, some registrars will voluntarily reverse the transfer before any formal proceeding. This is the best outcome: no filing fees, no waiting. It is also the rarest. Most registrars decline to reverse without a formal order or a settled agreement between the parties, because their own exposure runs in both directions.

What if the .app domain was transferred and then sold to a third party?

A common complication in .app theft cases is a downstream sale: the thief transfers the domain to a buyer who may or may not have known about the theft. That buyer is now the respondent in any UDRP or court action. Their claimed good-faith purchase can complicate the bad-faith element, because the current registration was arguably not made in bad faith by the current holder.

Panels have addressed this pattern by looking at the totality of the chain. Where the transfer history shows rapid succession of registrar changes, unusually short holding periods, and pricing inconsistent with a legitimate arms-length sale, panels have found that the original theft taints the entire chain. The consensus view under the Policy is that a registration made in bad faith does not become legitimate merely because it passed through intermediate hands. A third party who conducts no due diligence on a domain with a suspicious transfer history takes on that risk.

From a practical standpoint, the strength of your registered trademark or prior rights is the most important factor when facing a downstream buyer. If your mark is registered and well-known, the downstream buyer will have difficulty arguing they did not know of your rights. If the name is unregistered, building the common-law rights record becomes essential before filing.

Court actions have an advantage here: discovery can reveal the full consideration paid, any communications between the thief and the buyer, and whether the buyer was involved in or aware of the theft. That transparency is unavailable under the UDRP. Where the downstream sale appears collusive, a court route – handled with local litigation counsel in the relevant jurisdiction – is often the more appropriate first move.

Related at COGNOMEN

• Court action and domain theft recovery – full service overview
• Recovering a hijacked domain under the .fr procedure – approach and mechanics
• TMCH claims notice for .dev – what a brand owner should do next