Status as of 3 November 2026: ICANN’s 2026 new gTLD application window ran from 30 April to 12 August 2026 and is closed. Applied-for strings were published on 7 October. This guide, originally written during preparations in November 2025, now explains the 2026 rules and operating model; it is not an invitation to submit a new application in the closed window.
Operating your own extension means taking responsibility for a top-level domain at the end of an internet name. It differs from registering a domain under an existing extension or creating a subdomain. The decision combines legal eligibility, registry infrastructure, continuing obligations and a credible reason for people or internal teams to use the namespace.
The following sections cover application and operating roles, evaluation, costs, launch rules and practical preparation. A controlled namespace can help organize official services, but it does not guarantee trust, search rankings, revenue or protection against attacks elsewhere. Compare the complete operating model with simpler alternatives before committing to it.
What the 2026 gTLD Round Covers
The 2012 application round led to many extensions beyond established names such as .com and .net. The 2026 round is a separate evaluation process for new strings. An application appearing in ICANN’s published list is not yet an approved registry, a delegated TLD or a domain registration service open to the public.
The applicant must be an established eligible legal entity. The 2026 Guidebook excludes individuals, sole proprietorships and entities that have not yet been formed. Corporate existence alone is insufficient: background screening and financial and operational evaluation apply, alongside the checks relevant to the string and application type.
Separate the registry operator from its registry service providers and registrars. The operator is accountable under the Registry Agreement; an RSP supplies evaluated technical functions; registrars provide registration channels under applicable agreements. A web host or mail provider may serve domains beneath the TLD, but those services do not by themselves constitute the registry backend.
From Application to Delegation
Build a process map using the applicable 2026 Guidebook. Administrative checks, publication, community input, objections, string evaluation, contention resolution and applicant/application evaluation have different purposes and may have overlapping timelines. A simple diagram is useful only if it preserves the conditions attached to each step.
Begin with the use case: who will register or use names, what problem does the namespace solve, and why is an existing domain insufficient? A brand may want a controlled set of official service names; a public registry may aim to serve a defined market. Neither case removes the need for abuse response, consumer communication or protection of names under other TLDs.
Assess the proposed string against blocked and reserved names, confusing similarity, geographic rules and any applicable IDN requirements. Visual similarity is not the only potential issue: objections and other review paths have their own criteria. An alternative string is usable only through the permitted process and deadlines; it is not a freely interchangeable backup name.
Prepare governance, financial and operational evidence and select the evaluated RSP services needed for the proposed TLD. Confirm the provider’s scope, willingness and capacity to support it, including relevant IDN capabilities. An applicant intending to supply its own technical backend must still meet the applicable RSP evaluation requirements; buying software is not equivalent to being evaluated.
Publication allows other parties to inspect the public application information, and the program provides defined comment, objection and contention procedures. Follow the 2026 rules rather than assuming an informal agreement or private auction can settle competing applications; private contention resolution is prohibited. Even an uncontested string still needs to satisfy its evaluations.
After successful evaluation, contracting establishes the registry operator’s obligations. Post-contracting onboarding and the delegation testing/procedures specified by ICANN still need to be completed before root-zone delegation. The 2026 agreement has its own timing and extension conditions. RSP evaluation supports this process but does not automatically complete all applicant, contract or delegation requirements.
Current Milestones, Fees and Policy Constraints
ICANN’s 7 October 2026 announcement confirms the completed application window and Reveal Day. It schedules String Confirmation Day for 17 November 2026, which remains a future milestone as of this guide’s 3 November status date. Later evaluation and delegation timelines should not be presented as a guaranteed launch date; follow official updates and application-specific notices.
The standard 2026 gTLD evaluation fee is USD 227,000 per application, with the Guidebook’s exceptions for qualifying Applicant Support Program and variant applications. Conditional evaluation fees may also apply. Budget separately for RSP services, legal work, registry operation, rights protection, registrar integration, support and launch activity over several years. Neither a .Brand nor a public registry should assume its projected benefits will automatically cover those costs.
Closed generics are not an available 2026 operating strategy: a generic term cannot be reserved exclusively for the operator’s own benefit under that model. Geographic strings may be unavailable or require government/public-authority documentation, depending on their defined category and intended use. Community applications and .Brand designation have separate conditions. Governmental advice and objections are formal parts of the process, not informal endorsements to collect after launch.
A useful planning review asks what could prevent approval or sustainable operation: an ineligible applicant, unsupported geographic purpose, conflicting strings, insufficient financial resilience or an RSP scope mismatch. Assign evidence and responsibility for each issue. Keep permitted application changes and communication restrictions in view rather than assuming every concern can be fixed by renaming or negotiating privately.
The ICANN new gTLD program site provides program context; the 2026 Applicant Guidebook page identifies the authoritative version. At this review date it is V3-2026.10.07. Record the version used in your decisions: some HTML reference pages may lag the authoritative English document.
Brand, Public, Geographic and IDN Choices
These are not four mutually exclusive technical products. IDN concerns the script and label rules, while brand, geographic and public-registration decisions concern purpose, eligibility and use. Community designation is another specific application feature. Assess each applicable dimension instead of choosing a label that appears to bypass another requirement.
A .Brand must meet the Guidebook’s eligibility evaluation and Specification 13 of the 2026 Registry Agreement. Registrants and DNS control at every level are limited to the operator, its affiliates or qualifying trademark licensees as defined in that agreement. The trademark and use conditions matter; owning a mark does not automatically qualify every string. While the TLD retains eligible .Brand status and does not elect to implement the specified TMCH services, §4.1 exempts it from Sunrise and Claims. Electing those services or losing eligibility triggers the applicable requirements; this is not a waiver of all rights-protection duties.
A public registration model needs credible demand, clear eligibility and pricing, registrar integration and effective abuse handling. It may serve a profession, activity or other audience without qualifying as a community application. Assess actual prospective use and support costs; a memorable generic word alone does not establish a viable registry business.
Geographic applications require close reading of the defined categories. Country or territory names covered by the Guidebook’s prohibition cannot be made eligible merely by obtaining a support letter. Capital names, city names used for city-related purposes and other specified geographic names have documentation requirements. A hypothetical city project could pair domain use with local business education, but the governance and required public-authority support must be established separately.
For IDNs, review the permitted scripts, Root Zone Label Generation Rules and allocatable variants, and obtain relevant language expertise. Variant strings are not simply an unlimited list of spellings an applicant can choose to control. Test display, input, validation and email workflows across relevant software; delegation does not guarantee universal acceptance of every new or internationalized name.
The Registry Backend: Core Services and Continuity
The technical backend needs resilient authoritative DNS, DNSSEC operations, registry provisioning, registration-data access, data escrow and continuity arrangements. Distributed or anycast service is a common design choice, but the applicable evaluated scope and service requirements govern. Data escrow safeguards registry information; it is not a substitute for each registrant’s website backup. Emergency backend mechanisms operate under ICANN’s conditions rather than providing an unconditional no-outage guarantee.
Define DNSSEC key management, signing, rollover and root DS coordination with the responsible RSP. The TLD must meet its DNSSEC obligations, but signing the parent zone does not automatically secure every child domain end to end. The DNSSEC rollover and DS update guide explains background concepts; use the registry requirements and tested operator procedures for the actual TLD.
IPv6 obligations apply to particular registry services. For example, Specification 6 requires IPv6 glue support and public IPv6 transport for at least two registry nameservers listed in the root, with corresponding IANA records. Directory and shared-registration services have their own provisions. Confirm the exact service scope rather than assuming every endpoint has an identical deadline. The IPv6 adoption guide supports understanding and testing, but the contract determines the registry obligations.
EPP handles provisioning between registry and registrar systems; RDAP serves registration data under the applicable access and privacy requirements. Identify who operates these services, who monitors them and who handles incidents, reporting and escrow submissions. Keep current operational and abuse contacts and rehearse escalation. A provider’s availability statement does not replace evidence that your particular service and responsibilities are covered.
Use the 2026 RSP evaluation and Registry Agreement requirements when planning technical acceptance and onboarding. The historical pre-delegation testing overview is useful context for the earlier round, but should not be copied as the current checklist. Obtain the ICANN-specified procedures for the application and confirm remaining service integrations and delegation gates.
Launch Rules: Rights Protection and Registration Channels
For a public launch, identify the applicable Trademark Clearinghouse requirements and any approved exception. Sunrise gives eligible trademark holders a defined priority-registration opportunity; Claims provides prescribed notices concerning matching names during registration and subsequent notification. These mechanisms do not reserve every confusingly similar name or resolve every rights dispute. Commercial Landrush or general availability phases cannot replace mandatory rights-protection processes.
Registrar distribution must fit the Registry Agreement’s access and non-discrimination rules. A public registry cannot assume that choosing a few preferred sales partners permits exclusion of all other qualifying registrars. Specification 13 provides particular .Brand arrangements, including its conditions for exclusive registrar designation. Agree onboarding, support and clear customer information with the registrars permitted under the actual model.
Web certificates under the TLD are a separate application-layer responsibility. A .Brand operating many sites should plan certificate scope, validation, compatibility and renewal; delegation does not issue certificates automatically. The guide to dual ECDSA and RSA certificates explains algorithm compatibility, while planning for TLS changes covers maintenance. These do not replace registry DNS, EPP or RDAP requirements.
A registered domain’s website DNS also differs from the TLD’s registry zone. Questions about CNAME at a website’s zone apex or provider-specific flattening belong with that domain’s DNS design. The CNAME, ALIAS/ANAME and flattening explanation can support that discussion. Make clear which team controls the parent delegation and which controls the domain’s records.
Measure real use after launch: active services, successful registrations where offered, support demand and policy compliance. A closed .Brand’s internal rollout needs different measures from a public registry’s registrar distribution. Publish accurate examples and support material without promising that every holder will gain trust, traffic or search visibility from the extension itself.
Abuse Response, Email and User Trust
Registries need workable abuse intake and mitigation procedures suited to their obligations. A .Brand can still suffer compromised accounts, malicious content or impersonation elsewhere; a public TLD must also handle reports involving independently operated domains. Distinguish registrar, registry, hosting and application actions so reports reach the party able to act on the evidence.
If the organization also operates email under its TLD, assign a separate mail workstream for SPF, DKIM, DMARC, delivery monitoring and transport security. The SMTP security guide on MTA-STS, TLS-RPT and DANE/TLSA supports that work. These mechanisms serve different purposes, and encrypted transport alone does not guarantee inbox delivery or replace sender authentication.
Tell users how to identify official services using published addresses and appropriate verification, rather than teaching that a suffix alone proves safety. Keep account protection, incident response and external impersonation monitoring in place. Clear launch messaging should describe actual use and support routes, not imply the extension makes security controls unnecessary.
Use RSP Evaluation and the Correct Guidebook Together
The RSP program separates technical provider assessment from the application for a gTLD string. All gTLD applicants must identify evaluated RSP coverage. Check whether a listed provider has completed the required screening and testing for the services and IDN support you need; historical or partially completed evaluation status is not the same as completed coverage. The RSP submission period also closed on 12 August 2026, while evaluation status updates continue.
The 2012 Applicant Guidebook remains a historical reference. Use the authoritative 2026 version for current eligibility, contention, costs and application procedure, and the applicable 2026 Registry Agreement for operating commitments. Do not blend older .Brand launch exemptions or testing terminology into the new rules without checking the actual provision.
Maintain a requirements register that records the governing section, evidence, responsible party and unresolved decision. Separate ICANN milestones from the organization’s readiness work and from a provider’s delivery schedule. A change in one does not automatically extend another; track notices and contractual deadlines against the correct document.
A Hypothetical Launch and Its Operating Lessons
Imagine an eligible .Brand completing its required gates and being delegated into the root. The team verifies authoritative responses and signing from several networks, then introduces a small set of internal services before public sites. This is a hypothetical rollout example, not a reported client deployment or evidence that those stages guarantee success.
If a domain provisioning request fails, the registry and registrar teams investigate the EPP workflow. If the public site presents an expired certificate, the site operator investigates its TLS automation. If a mail address is rejected by a third-party form, the team checks universal acceptance and that service’s validation. Assigning each issue to the right layer makes the rollout manageable without assuming one provider runs everything.
Users still need clear information about official names, and staff need account controls, escalation contacts and rehearsed recovery procedures. A .Brand designation does not make phishing or compromise impossible. Plan maintenance around tested DNSSEC and application procedures rather than treating the appearance of the suffix in the root as the end of the project.
Practical Work to Do at This Stage
Start by distinguishing an existing 2026 application from interest in a future round. Existing applicants should follow their current file, notices and applicable timelines. Organizations that did not apply can develop a business case, but must not assume a new submission can be added to the closed 2026 window.
Write a short decision memo: who benefits, why an existing domain is insufficient, what success would look like and who carries the continuing obligations. Include a multi-year cost comparison and a way to stop or defer the project if the case is weak.
Review the proposed namespace against legal eligibility, rights, geographic restrictions, community requirements and IDN rules as applicable. In an existing application, any change must follow the permitted process. For a possible future round, mark unresolved policy or timing assumptions explicitly rather than treating the 2026 rules as a permanent guarantee.
Ask the RSP for a service-by-service responsibility matrix, evaluation evidence, continuity arrangements, incident escalation and a transition/exit plan. Keep website certificate and mail responsibilities separate. Confirm what remains with the operator, its registrars or other providers so that a gap in the contract does not become a gap in live operations.
Prepare the launch policy for the actual registry model. Check Sunrise/Claims applicability and any .Brand or other authorized exemption, registrar access, reserved names, support and reporting. If an eligible .Brand elects to implement TMCH services, account for the resulting requirements and notice rather than assuming its exemption still works unchanged.
Keep the official version history and application-specific notices with that plan. As of the status date above, the Guidebook is already published and the submission period is over. Future milestones and later rounds should be tracked through official announcements, not presented to users as a date the organization can promise.
Make the Operating Case Before the Naming Decision
A new extension is a long-term registry commitment under an agreement, not unrestricted ownership of a piece of the internet. It can support a coherent naming strategy when the eligible applicant, rules, technical services and funding fit the intended use.
The decisive distinction is between running the registry and running services beneath it. Reliable DNS and registration systems, rights protection and operator accountability establish one layer; usable websites, mail and customer support establish another. A sustainable plan assigns both.
Bring the use case, responsibility matrix and financial comparison to a concrete organizational decision. For existing applicants, connect that decision to the current application and remaining gates. For future interest, continue preparation with clearly identified assumptions until ICANN confirms another opportunity and its rules.
