ICANN 2026 applications: what to expect after submitting your application

A structured and transparent evaluation phase

Following the close of the application period, a central phase of the programme begins: ICANN’s evaluation. This stage, which is strictly governed by the Applicant Guidebook 2026, is primarily intended to ensure the stability, security and resilience of the DNS, a core mission of ICANN.

This is not a traditional competitive process but rather a rigorous verification process designed to ensure that each registry project is legitimate, reliable, sustainable and aligned with the broader interests of the Internet ecosystem.

1. Reveal Day: a first milestone in programme transparency

Once the initial administrative checks have been completed, ICANN publishes the full list of submitted applications on “Reveal Day”, scheduled for October 2026.

This publication formalises the character strings that have been applied for (the exact name of your future TLD). It enables all stakeholders (businesses, rights holders, governments and the technical community) to review the submitted applications ahead of their full evaluation. In cases where the same TLD has been requested by multiple applicants, ICANN has provided for a string replacement process (the inclusion of replacement strings is optional in your application) aimed at simplifying the resolution of competing applications.

This “reveal” helps to streamline the process by exposing applications to public review at an early stage.

2. A public comment phase integrated into the evaluation

Following the publication of applications, a formal public comment period allows any interested party to submit observations on a given application .

These contributions are explicitly considered to be part of the evaluation process and may inform ICANN’s assessment.

This mechanism ensures that an application’s review is not solely based on administrative analysis, but also takes into account input from across the ecosystem, increasing the legitimacy of the decisions made.

3. Objection rights, particularly for brand owners

The programme provides for several reasons for objection, allowing third parties to intervene when they determine that an application infringes on their rights or poses a risk to the public interest.

These reasons include infringement of third-party rights, which is a critical mechanism for brand owners who want to challenge a character string that may cause confusion or undermine their rights.

Specialised dispute resolution providers handle such objections in accordance with clearly defined procedures, which include specific admissibility criteria and administrative steps.

The availability of these avenues of recourse adds to the programme’s overall legal safeguards by providing a structured framework for dispute resolution rather than relying on reactive measures.

4. A multidimensional evaluation of the applicant and the project

ICANN’s review covers both the applicant and the requested character string.

Specifically, it includes:

• applicant background checks;
• a financial and operational assessment;
• a review of the applicant’s technical capabilities, which are often supported by a previously evaluated registry service provider; and
• an analysis of the string’s compliance (similarity, reserved names, geographical considerations, public interest commitments, etc.).

ICANN may also issue clarification requests to applicants during the evaluation process in order to supplement or clarify specific aspects of their applications.

5. Signing of the registry agreement with ICANN

Once ICANN has approved your application, you will be invited to sign a Base Registry Agreement. This is a formal step that authorises your organisation to operate a top-level domain (your TLD) for a term of 10 years, renewed automatically.

This standard agreement lays out the registry operator’s technical, operational and financial obligations, as well as the security and availability standards that must be met. It commits the registry operator to following ICANN policies on domain name management and end-user security. Submitting an application involves long-term responsibilities, which include:

• compliance with the commitments outlined in the application;
• the establishment of appropriate governance;
• the ability to ensure service continuity; and
• compliance with applicable rules throughout the life of the TLD.

Once the agreement is signed, the registry operator can begin technical preparations for the TLD’s launch.

Integration of the TLD into the DNS root

The TLD is not immediately usable after the evaluation phase and application approval. It must first be integrated into the root zone of the domain name system (DNS), which is a critical step in how the Internet operates.

The strategic benefit of using an ICANN pre-evaluated RSP

The Applicant Guidebook 2026 includes a key mechanism that allows applicants to rely on a registry service provider (RSP) that has been pre-evaluated as part of the programme. ICANN conducts this pre-evaluation in advance to ensure that the technical provider already meets the operational, security and continuity requirements for operating a registry in accordance with ICANN standards.

In practice, this means that critical components such as name server operations, security mechanisms, service continuity and operational capabilities are built on a validated foundation, significantly lowering the level of risk in evaluating your application.

This model also clarifies the programme’s role allocation. Specifically, the applicant retains responsibility for the TLD’s strategy, commitments and governance, whereas the technical operator is responsible for the day-to-day execution of registry functions in accordance with contractual requirements and applicable policies.

It therefore allows an organisation, particularly a brandTLD, to focus on its use, protection and long-term development goals without having to internalise complex technical expertise not central to its core business.

Designation of ICANN points of contact

Prior to the technical integration of the domain TLD into the DNS root, the applicant must provide ICANN with a list of operational contacts who are authorised to oversee the TLD’s launch. Specifically, this includes the following points of contact, thereby ensuring a clear chain of responsibility before the TLD is entered into the root:

• A primary contact, designated as the main point of contact for coordinating all communications and acting on behalf of the applicant organisation.
• An administrative contact, responsible for managing contractual and compliance matters and for finalising the Base Registry Agreement.
• A technical contact, in charge of technical validations (pre-delegation testing, DNS configuration, security and interoperability).
• An operational contact, who oversees the day-to-day operations and service continuity.
• A financial contact, who tracks the costs and billing.

Integration of the TLD into the DNS root zone

To complete this final stage, the registry operator must supply ICANN with complete information on its DNS servers and guarantee that DNSSEC standards are met. ICANN verifies that the TLD, a brandTLD in this case, adheres to the registry policies specific to brandTLDs and is properly integrated into the root zone. The registry operator must also publish its registration policies and an operational plan for name management and potential dispute resolution. After validation, ICANN formally adds the TLD to the root zone, making domain names ending in “.brand” active and resolvable on the Internet.

Deployment of initial use cases under your .brand

A .brand constitutes a strategic digital asset capable of responding to both current and future organisational challenges.

However, one important point should be made clear: creating a TLD does not guarantee its immediate use. The deployment strategy is specific to each organisation. The brand retains its existing assets and has no obligation to ICANN to register a minimum number of domain names under its TLD.

In practice, use cases for this TLD may be:

• progressive;
• limited to certain scopes; and
• variable over time based on the organisation’s needs.

This distinction between the decision to apply and the subsequent use of the TLD should be considered from the start to ensure that organisations do not pass up the rare opportunity presented by the upcoming application window.

In conclusion

Submitting an application to create a TLD initiates a structured process, with operational launch anticipated in 2028.

Understanding the evaluation stages, timelines, stakeholder roles and associated responsibilities allows applicant organisations to:

• optimise their application;
• develop a realistic view of the timeline;
• clarify their objectives; and
• integrate their approach into a long-term digital strategy.

It may therefore be beneficial to seek expert advisory assistance to help you understand the process and its challenges.