Module 2 General Information

ICANN acknowledges the complexity of the New gTLD Program: 2026 Round and has compiled guidance to address potential applicant questions. This module provides direct access to essential information and links to additional resources, enabling applicants and stakeholders to gain a deeper understanding of the Program.

Module 2 provides an overview of key topics, including:

• Information on languages and supporting documentation.

• Universal Acceptance.

• Security and stability.

• Legal compliance.

This module should serve as the primary reference point for applicants with general inquiries.

2.1 Resources and Help

There are a number of resources available for answering questions about the New gTLD Program: 2026 Round and the application process, as described below.

2.1.1 Frequently Asked Questions

ICANN has compiled a database of frequently asked questions (FAQs) to serve as a valuable resource for applicants. Access these FAQs by visiting the FAQ page on the New gTLD Program website.¹

2.1.2 Support for General Inquiries

For general inquiries about the New gTLD Program: 2026 Round, contact ICANN Global Support² or send an email to: globalsupport@icann.org.

ICANN Global Support has also put into place a dedicated Applicant Counselor to help answer questions about the application process and provide guidance on where to find available resources.

2.1.3 System and Application Specific Questions

To protect the security and privacy of applicant data, applicants with questions specific to their applications must submit an inquiry in TAMS. To submit an inquiry in TAMS, click the “View My Organization” link on the left side of the homepage. This will take you to the “Organization Summary” page where you can click the “Create Inquiry” button at the top right.

To learn how to create an inquiry and for other helpful system related information, refer to the TAMS User Guide on the New gTLD Program website.³

As noted in Section 2.1.2, general inquiries regarding the New gTLD Program must be submitted via ICANN Global Support (globalsupport@icann.org).

2.2 Languages and Supporting Documentation

2.2.1 Applicant Guidebook and Materials

The Applicant Guidebook will be available in the ICANN languages: Arabic, Chinese, English, French, Russian, and Spanish.⁴ The different language versions can be found on the Applicant Guidebook Homepage.⁵ The English version is considered authoritative for the Applicant Guidebook and other documentation.

2.2.2 Language of New gTLD Applications

English is the primary working language for all ICANN business. All application materials must be submitted in English, except where expressly stated otherwise within an application question.

2.2.3 Language for Supporting Documentation for New gTLD Applications

For supporting documentation, applicants are requested to provide the original documentation. When submitting original documentation in a language other than English, applicants must provide:

1. Original documents.

2. English translations for each document.

3. A certificate of translation accuracy for each document.

The certificate of translation must be written in English and include:

1. Translator’s qualifications.

2. A statement affirming the completeness and accuracy of the translation.

3. Identification of the translated document and its original language.

4. Translator’s name, signature, and date.

Most professional translators and translation agencies can provide a certificate of translation, which does not need to be notarized. A sample certificate of translation accuracy can be found on the American Translators Association website.⁶

Properly submitted certified translations may expedite the review and processing of materials.

2.3 Universal Acceptance of Domain Names and Email Addresses

Universal Acceptance (UA) is a critical concept that aims to ensure that all Internet-enabled applications, devices, and systems should accept all domain names and email addresses, regardless of script, language, or TLD length. This approach allows Internet users to navigate and communicate online using domain names and email addresses that reflect their cultural and linguistic preferences.

2.3.1 Notice Concerning Issues related to the Universal Acceptance of Domain Names and Email Addresses Using New gTLDs

All applicants should understand that obtaining ICANN approval and entering into a Registry Agreement does not guarantee immediate, comprehensive Internet functionality. Past experience indicates that network operators may not immediately fully support new top-level domains, even when these domains have been delegated in the DNS root zone, as implementing changes may require third-party software modifications. Similarly, software applications sometimes attempt to validate domain names and may not recognize new or unknown top-level domains.

ICANN cannot mandate software acceptance of new top-level domains but does provide resources to help. ICANN publicizes valid top-level domains and has developed a basic tool to assist application providers in using current root zone data. ICANN encourages applicants to familiarize themselves with these potential integration issues and account for them in their startup and launch plans. Successful applicants may find themselves expending considerable efforts working with providers to achieve acceptance of their applied-for gTLDs.

For more detailed information, applicants should review the Universal Acceptance webpage⁷ for background. Internationalized Domain Name applicants are encouraged to review the material concerning experiences with IDN test strings in the root zone.⁸

2.3.2 More Detailed Information on Universal Acceptance

ICANN and the community continue to advance UA readiness across the Internet ecosystem. ICANN publishes recent detailed information on Universal Acceptance on the Universal Acceptance webpage, including the latest annual UA-Readiness Report. This report covers the status of UA support in technology, including programming languages, email tools and services, network utilities, social networking applications, content management systems, authentication tools, and others. The report also includes information on the bug reporting and bug fixing efforts currently being conducted. Reporting on UA as well as technical training materials and guidance for making systems UA-ready can be found on the Universal Acceptance webpage. A provision on the technical feasibility of strings is included in Section 1.2 of the Base Registry Agreement (Appendix 4).

2.4 Applicant Freedom of Expression

ICANN respects applicants’ freedom of expression rights as protected by internationally recognized legal principles, including those defined in the Paris Convention for the Protection of Industrial Property, the Universal Declaration of Human Rights, and the International Covenant on Civil and Political Rights.

While applicants may apply for available strings, this must be balanced against certain restrictions based on technical standards, Reserved Names lists, and other prohibitions detailed in the Guidebook, while being mindful of limitations to free expression. When assessing whether or not to file a Limited Public Interest Objection (Section 4.5.1.3), the Independent Objector(s) will consider freedom of expression alongside other relevant factors. Applications may be unsuccessful if the proposed string violates applicable laws or other rights, requirements, or prohibitions.

2.5 Security and Stability

The number of TLDs delegated in the DNS root zone should not increase by more than approximately five percent per month.⁹

Applications will proceed based on the application priority order. The delegation process of a new gTLD into the root zone starts when the registry operator submits a delegation request once the new gTLD is ready.¹⁰ Absent extraordinary circumstances, delegation requests will be processed in a first-come-first-served order until such time as any root zone change limits are reached. However, delegation requests of other types of TLDs¹¹ will have precedence over delegation requests of new gTLDs.

ICANN reserves the right to change the delegation rate in case of actual or potential DNS service instabilities as determined in ICANN’s sole and reasonable discretion. Should such a change in the delegation rate be required, any affected applicants will be notified. Any delay on ICANN’s part in a string’s delegation shall not be counted against the registry operator's obligation to complete pre-delegation testing and procedures within the timeline as outlined in Article 2.20 of the Base Registry Agreement (Appendix 4).

2.6 Legal Compliance

Applicant acknowledges that ICANN must comply with all applicable laws, including U.S. laws, rules, and regulations. One such set of regulations is the economic and trade sanctions program administered by the Office of Foreign Assets Control (OFAC) of the U.S. Department of the Treasury.¹² These sanctions have been imposed on certain countries, as well as individuals and entities that appear on OFAC's List of Specially Designated Nationals and Blocked Persons (the SDN List). ICANN is prohibited from providing most goods or services to residents of sanctioned countries or their governmental entities or to SDNs without an applicable U.S. government authorization or exemption. ICANN generally will not seek a license to provide goods or services to an individual or entity on the SDN List. In the past, when ICANN has been requested to provide services to individuals or entities that are not SDNs, but are residents of sanctioned countries, ICANN has sought and been granted licenses as required. However, applicant acknowledges that ICANN is under no obligation to seek such licenses and, in any given case, OFAC could decide not to issue a requested license.

2.7 Accountability Mechanisms

ICANN has a commitment to accountability and transparency in all of its practices. ICANN considers these principles to be fundamental safeguards in ensuring that its bottom-up, multistakeholder model remains effective. The mechanisms through which ICANN achieves accountability and transparency are built into every level of its organization and mandate – beginning with its Bylaws,¹³ detailed in its Accountability and Transparency Frameworks and Principles¹⁴ (adopted by ICANN's Board in 2008) and annually reinforced in its Strategic and Operational Plan.¹⁵ In order to reinforce its transparency and accountability, ICANN has established accountability mechanisms for review of ICANN actions. See ICANN Accountability Mechanisms¹⁶ for more information.

2.8 Subsequent Application Rounds

ICANN anticipates future rounds of new gTLDs will take place at regular and predictable intervals without indefinite review periods. Except under extraordinary circumstances, application procedures will proceed without interruption unless the GNSO Council recommends a pause and the ICANN Board approves it.

The Board may initiate a new round even if prior application processing and delegation steps are incomplete. Applications for allocatable variant strings of existing gTLDs may also be submitted in the 2026 and subsequent rounds.

The Board will determine the timing for the next application round as soon as feasible, ideally by the second Board meeting after the following conditions are met:

1. Confirmation of the list of applied-for strings for the ongoing round and closure of the window for string change requests. This will provide applicants in a subsequent round with an understanding of which strings can be applied for.

2. ICANN has not encountered significant barriers in receiving and processing new applications.

Future reviews and policy development processes, including the next Competition, Consumer Choice & Consumer Trust (CCT) Review, should occur independently of subsequent gTLD application rounds. They must not stop or delay these rounds, except in extraordinary circumstances.

If any review outputs or policy development processes could materially impact application procedures, such changes will apply to the next application round following the adoption of the relevant recommendations by the Board. The implementation of these recommendations will be a prerequisite for the timing of the next application round.

2.9 Calendar Days and Timelines

Unless otherwise specified, the countdown period for all processes mentioned in the Applicant Guidebook will be in calendar days and will commence at 00:01 UTC the day after the announcement of the initiation of the process. Unless otherwise specified, all of the deadline times will be in Coordinated Universal Time (UTC).

2.10 Fundamental Obligations of Registry Operators in relation to Registrars

This section highlights registry operators’ obligations related to their interactions with Registrars. See Appendix 4 Base Registry Agreement for all registry operator obligations.

A domain name in a gTLD must be registered through an ICANN-accredited registrar, except under certain limited exceptions identified in the Base Registry Agreement that allow the registry operator to register a name to itself. See Section 2.9 of the Base Registry Agreement.

A registry operator must use a uniform agreement with all registrars authorized to register names by creating a Registry-Registrar Agreement (RRA) to define requirements for its registrars. The RRA must include certain terms that are specified in the Base Registry Agreement, and may include additional terms specific to the gTLD. A registry operator must provide advance notice of pricing changes to all registrars, in compliance with the time frames specified in the agreement. See Sections 2.9 and 2.10 of the Base Registry Agreement.

All registry operators are required to abide by the Registry Operator Code of Conduct, unless ICANN grants an exemption to an eligible registry operator that requests such an exemption.¹⁷ The Registry Operator Code of Conduct requires the registry operator to provide non-discriminatory access to its registry services to all ICANN-accredited registrars that enter into and are in compliance with the RRA for the TLD. See Specification 9, Section 1(a) of the Base Registry Agreement.

Furthermore, the Registry Operator Code of Conduct requires registry operators that also provide registrar or registrar-reseller services to ensure that such services are offered through a legal entity separate from the registry operator, maintaining separate books of accounts. ICANN reserves the right to refer any application to the appropriate competition authority regarding any cross-ownership issues. See Specification 9, Section 2 of the Base Registry Agreement.

A registry operator should be aware that an ICANN-accredited registrar has no obligation to carry a gTLD or offer it to its customers in its product offerings. While registrars are encouraged to follow updates regarding the New gTLD Program in order to be aware of delegated gTLDs, it is at the registrars’ discretion to evaluate whether to enter into an RRA with each registry operator.

ICANN will continue to provide support for gTLD registry operators as they launch and maintain registry operations. ICANN provides a point of contact for gTLD registry operators for assistance on a continuing basis. Registry operators may also wish to reference the registry operator website¹⁸ and the Post-Contracting section of the New gTLD Program website¹⁹ for more information.

ICANN’s contractual compliance function conducts regular audits to ensure that gTLD registry operators comply with their agreement obligations and investigates any instances of noncompliance. See the Contractual Compliance webpage²⁰ for more information on current contractual compliance activities.

ICANN’s Bylaws mandate that the organization act in an open and transparent manner, ensuring equitable treatment among registry operators. ICANN is responsible for maintaining the security and stability of the global Internet, and looks forward to a constructive and cooperative relationship with future gTLD registry operators in furtherance of this goal.