Step-by-step: prove a legitimate interest in your .dev domain

Step-by-step: prove a legitimate interest in your .dev domain. UDRP and ccTLD domain recovery and defense across .dev. Email the firm to assess your case.

A UDRP complaint lands in your inbox, the registrar locks your .dev domain, and a brand owner claims the name was registered to trade on their trademark. You built your developer tool, open-source library, or professional portfolio on that domain. Now you have 20 days to respond before the case proceeds without you. The question is whether your registration can survive the challenge – and what it takes to show it.

To prove a legitimate interest in a .dev domain under the UDRP, a respondent must satisfy at least one of the Paragraph 4(c) safe harbors: a bona fide offering of goods or services before notice of the dispute, being commonly known by the domain name, or a legitimate noncommercial or fair use. The entire burden of demonstrating legitimate interest initially shifts to the complainant, but once the complainant makes a prima facie case, the respondent must come forward with concrete evidence. A standard WIPO case concludes in roughly two months; there is no court filing required.

This guide walks through each step, the evidence that carries the most weight at each stage, and the trap that quietly undermines an otherwise strong defense.

Why .dev disputes go to WIPO – and what rule applies

.dev is a generic top-level domain operated under ICANN's new gTLD program and is governed by the standard UDRP – not a separate ccTLD procedure. That means every .dev complaint filed with WIPO, the Forum, or the Czech Arbitration Court (CAC) is decided under exactly the same three-element test that applies to .com and .net: confusing similarity, no legitimate interest, and bad-faith registration and use. The respondent's task is to defeat at least one of those three elements.

In our practice we regularly advise .dev registrants who assumed their domain sat outside the standard UDRP framework because it is a newer, specialty zone. That assumption is incorrect. The UDRP was extended to new gTLDs as a condition of ICANN accreditation, and all three elements of Paragraph 4(a) must be proven by the complainant – with "bad faith" reading as a cumulative "registered AND used in bad faith," not an either/or.

One practical implication: .dev's restricted status (only HTTPS-capable registrants may activate the zone) is sometimes held out as evidence of legitimate technical purpose. Whether a panel treats that as meaningful is fact-specific, but it is worth noting in your response as context for why you registered in this zone at all.

If you have just received a UDRP complaint targeting your .dev domain, the 20-day clock is already running. For an assessment of your domain dispute, contact info@cognomenlaw.com.

Step 1: Understand which safe harbor fits your situation

Paragraph 4(c) of the UDRP provides three routes to demonstrating legitimate interest, and selecting the right one – before you start gathering evidence – determines what you actually need to prove. Picking the wrong safe harbor wastes time and can signal to the panel that your case is poorly constructed.

Safe harbor one – bona fide use before notice. This is the most commonly invoked path. It requires that before you received notice of the dispute (typically the complaint, though panels sometimes look to earlier correspondence), you were using the domain for a genuine offering of goods or services. "Genuine" is the operative word. Panels distinguish a real, functioning service from a domain held passively in anticipation of a dispute. If your .dev domain hosts a live developer tool, a code repository landing page, or a paid software-as-a-service product, you are on solid ground – provided you can document when that use began.

Safe harbor two – commonly known by the name. This applies when the respondent is, or a business it operates is, actually known by the domain name in commerce or in a community. For .dev registrants this most often arises where the domain matches an open-source project name with a substantial GitHub following, a developer handle used across multiple platforms, or a business trading under that name before the complainant's mark became prominent. Trap: a personal GitHub username alone is unlikely to be enough unless it is also how collaborators, users, and third-party coverage refer to the project.

Safe harbor three – legitimate noncommercial or fair use. This covers commentary, criticism, fan sites, and genuinely noncommercial technical projects. In the .dev zone it can apply to an open-source project with no monetization. Trap: even a single affiliate link, donation button framed as a commercial transaction, or sponsored placement can undermine the "noncommercial" prong.

Step 2: Build your legitimate-interest record before the response deadline

Evidence is what panels actually decide on. A well-argued legal submission without documentation is weaker than a modest legal argument supported by a clear paper trail. Here is what decides outcomes at this step.

First, establish a registration timeline that makes sense. Pull your registrar's original registration confirmation email, any pre-registration interest record, and any correspondence that predates the complainant's public announcement of the trademark they are asserting. Panels look carefully at whether the registration date precedes any plausible awareness of the complainant's mark. If you registered in 2021 and the complainant's trademark was filed in 2023, that sequence alone is powerful – but only if you document it.

Second, collect evidence of actual use before the dispute. Screenshots with embedded timestamps are a start, but they are easy to fabricate and panels know it. Use the Wayback Machine (web.archive.org) to pull archived captures of your site. Export your hosting provider's server logs for the relevant period. If your .dev domain hosted a repository, export commit histories and contributor logs showing active development. We have defended .dev registrants in recent matters where a GitHub commit history going back years was the single most persuasive document in the response file.

Third, gather third-party recognition. Email threads where collaborators or users address you by the domain-related project name, press coverage, developer forum posts, Stack Overflow answers linking to your domain, and package download statistics all demonstrate that the name belongs to you in the relevant community – not to the complainant.

The trap at this step: waiting until you have "everything" before you start drafting. Assembling the evidence and drafting the legal argument must happen in parallel. The 20-day response deadline does not pause because gathering historical records takes time.

If a prior response or filing did not capture all the available evidence, a focused review can identify what was missed. Email info@cognomenlaw.com to discuss where the record can be strengthened.

How does the evidence standard differ for .dev versus a standard .com dispute?

The legal test is identical – UDRP Paragraph 4(c) applies uniformly. What differs is the context a panel brings to evaluating your evidence. .dev is a restricted, purpose-built zone aimed at the developer community, and panels are generally aware that legitimate developer use is a plausible reason someone would have registered a name there even if it resembles a brand.

That context cuts both ways. On one hand, a genuine technical project in a .dev domain is harder for a complainant to dismiss as pure cybersquatting than the same name in .com. On the other, a .dev domain pointing at a parking page or a pay-per-click landing page will look more suspicious in this zone, because the zone's purpose is active technical development, not passive holding. Panels have consistently held that passive holding can constitute bad faith; in .dev, that inference is arguably stronger.

The practical implication: if your .dev domain is currently undeveloped, get it to a state that reflects real use – not to manufacture evidence for the dispute, but because the current state of the domain is what the panel sees when it reviews your case. An undeveloped domain with a strong documentary history of planned use is a weaker position than an active domain with a moderate documentary history.

Step 3: Address bad faith head-on – don't just defend on legitimate interest

Respondents sometimes make the mistake of proving only their legitimate interest and ignoring the bad-faith element. That approach leaves points on the table. If you can affirmatively show that your registration was in good faith – that you had no knowledge of the complainant's mark, or that you registered for reasons entirely unrelated to the complainant's business – you attack the third UDRP element directly and make the complainant's case harder to sustain on any element.

Relevant good-faith markers include: the registration date predating the trademark's filing or its public recognition; the respondent's existing online presence in the developer community under the same or a related name; the absence of any commercial use that could create consumer confusion; and the fact that the domain was used for a technical purpose – documentation, API access, a software tool – with no attempt to attract the complainant's customers.

One more piece: if the complainant's trademark is weak, descriptive, or has a generic meaning in the developer community, argue it. "Dev," "stack," "code," and similar terms appear in many technology trademarks, and their generic weight in the .dev zone can limit how far a mark's rights actually extend. Panels have consistently held that marks with generic or descriptive components command narrower protection than inherently distinctive marks.

Step 4: Assess whether an RDNH finding is realistic

Reverse Domain Name Hijacking – a finding that the complainant brought the case in bad faith to strip a legitimate registrant of their domain – is available under the UDRP and is worth analyzing before you finalize the response. An RDNH finding carries no monetary penalty, but it is a formal, published record that the complainant abused the process. For respondents dealing with a well-resourced brand using UDRP as leverage rather than as a genuine recovery mechanism, that finding has real deterrent value.

When is RDNH realistic for a .dev respondent? Panels have found RDNH where: the complainant knew or should have known the respondent had a legitimate interest; the trademark rights asserted were geographically, temporally, or substantively insufficient to support the complaint; or the complainant filed to use the 20-day pressure window to extract a below-market sale rather than to resolve a genuine abuse. In our practice, we assess RDNH candidacy as a standard part of every defense brief, because a complaint that cannot survive the bad-faith element is often also a complaint that should not have been filed.

The trap: overclaiming RDNH. A panel that agrees the complainant lost the case on the merits does not automatically grant RDNH; the respondent must show the complainant went further than filing a losing claim – that it acted with knowledge of the weakness or with an improper purpose. Overreaching on RDNH can undermine an otherwise clean defense.

In a recent matter (a .dev domain dispute, spring 2025), we secured both a denial of transfer and an RDNH finding for a registrant who had operated a developer documentation portal under the name for approximately three years. The complainant had asserted a trademark that postdated the registration by over a year and had sent a series of demand letters offering escalating buy-back demands. The panel's written decision noted the complainant's awareness of the registration timeline as the basis for the RDNH finding.

Step 5: Structure the response for the panel, not for yourself

A UDRP response is not a letter to the complainant and it is not a brief to a court. It is a document for a single panelist – sometimes three – who may be handling dozens of other cases simultaneously. Clarity, organization, and evidence integration matter far more than length.

Structure the response around the three UDRP elements, not around your personal narrative. Address confusing similarity first (even if the complainant has the stronger argument there), then legitimate interest, then bad faith. Within the legitimate-interest section, identify the Paragraph 4(c) safe harbor you rely on, state the legal standard, and then lay out the evidence in chronological order. Attach documents as numbered exhibits and refer to them by number in the body of the response.

Avoid two common response-drafting errors. First, do not argue every possible angle at equal length. Panels read the full record; a well-prioritized response signals confident command of the facts. Second, do not embed emotional or commercial arguments – "this domain is our livelihood," "the complainant is a large corporation" – without legal substance. Panels decide on the UDRP elements, not on sympathy.

Finally, consider whether to request a three-member panel. A single-member panel is the default. Where the dispute involves a genuinely contested factual record – competing claims to recognition by a name, complex prior-use evidence, or an active RDNH argument – a three-member panel provides a more thorough review and, in the right case, a stronger published decision. If the complainant requested a single-member panel and you request three members, the parties generally split the higher three-member fee under WIPO's published schedule.

For .dev disputes in particular, we have found that a three-member panel is worth the additional cost where the RDNH argument is strong, because a three-member finding carries greater reputational weight against the complainant.

Choosing between WIPO, the Forum, and CAC for your .dev defense

The complainant chooses the forum, not the respondent. But understanding the forum's characteristics affects how you calibrate the response. WIPO and the Forum together handle the large majority of all UDRP proceedings. CAC has lower filing fees but is less frequently used for .dev disputes.

WIPO's expedited option – delivering a decision in roughly one month for single-panel cases of up to five domains – is available to complainants. If your complaint arrives via WIPO's expedited track, your response window remains 20 days but the panel appointment and decision follow faster. Prepare the full evidentiary record from day one; there is no time to supplement after submission in a standard case.

What if the complainant bypasses UDRP entirely and files in a national court? For .dev, that means a court in the jurisdiction where you or the complainant are based, applying the applicable national anticybersquatting or trademark legislation. A US complainant can pursue a US anticybersquatting court action that allows both transfer and monetary damages – a remedy that the UDRP does not provide. If you receive a court summons rather than a UDRP complaint, the procedural timeline, burden of proof, and potential exposure are all materially different. In that scenario, COGNOMEN works with local litigation counsel in the relevant jurisdiction to coordinate the defense.

The decision is not binary. A UDRP loss does not preclude a subsequent court challenge by the registrant; a court win by the complainant overrides any UDRP outcome. Assess both routes as part of an overall strategy, not as mutually exclusive options.

Related at COGNOMEN

• UDRP respondent defense and RDNH – full service overview for all gTLD zones
• Defending a UDRP complaint on fair use grounds – strategy and evidence
• Proving bad faith in a UDRP complaint – the complainant-side evidence guide