Updated 4 November 2026: ICANN’s 2026 new gTLD application window ran from 30 April to 12 August 2026 and is now closed. Applications were published on 7 October; String Confirmation Day is scheduled for 17 November 2026. This article was first published on 30 December 2025. Its timeline and policy guidance have been updated against the current Applicant Guidebook. The guide explains the long-term brand, financial and technical decisions behind operating a TLD, alongside practical steps for organizations that simply want to register useful domains when new extensions launch.
What the New ICANN gTLD Application Round Actually Is
ICANN (the Internet Corporation for Assigned Names and Numbers) coordinates the global Domain Name System. During designated application windows, organizations can apply to run their own gTLDs – extensions named for brands, cities, commercial sectors, or specialized communities.
The 2012 round introduced more than a thousand new extensions. The 2026 round is the next large-scale application opportunity after years of policy work. An application appearing in the published list does not mean that its string has been approved, delegated into the DNS root zone or opened for domain registrations.
A new gTLD application is an application to become a registry operator, responsible for an entire namespace under an ICANN Registry Agreement. A registrar offers domain registrations to customers; a Registry Service Provider (RSP) supplies evaluated technical registry functions. These are distinct roles. The operator remains responsible for its contractual obligations when it outsources technical services.
Operating a TLD can provide control over a brand or community namespace, together with significant continuing obligations. Evaluate that control against the simpler option of registering domains under an existing extension.
Which Organizations Have a Case for Operating a gTLD?
A TLD requires continuing funding, policy expertise and technical operations. The following scenarios can justify evaluating the model. New submissions to the 2026 round are closed; organizations without an application should treat these as long-term planning questions and wait for official information about any subsequent round.
1. Large or Ambitious Brands (.brand)
A qualifying .Brand TLD can give a company a controlled namespace. ICANN evaluates eligibility, and Specification 13 sets the applicable registration and use conditions. A trademark registration alone does not guarantee .Brand status or application approval. Potential uses include:
- Unify digital properties under a controlled extension
- Use short campaign addresses within the permitted registration model
- Support anti-phishing education by giving users a consistent official namespace to recognize; lookalikes elsewhere remain possible
Brand TLDs tie directly into long-term domain strategy and defensive registrations. If you are not yet confident in your brand’s domain posture, it is worth reviewing a defensive registration approach first. Our article on defensive domain registration strategy for typosquats, IDNs, and brand TLDs is a good baseline when assessing the cost and purpose of a brand TLD.
2. Sector or Community Registries
A sector-focused TLD and a formally designated Community Application are not interchangeable. Community applicants must serve a clearly defined community and have registration policies evaluated for inclusion in the agreement. Rules should explain who is eligible, which names are permitted and how those conditions are enforced.
Here, the registry would serve many independent registrants. This requires:
- Clear, enforceable registration and eligibility policies
- Abuse reporting, evidence assessment and mitigation procedures
- Reliable registry and DNS services delivered through evaluated RSPs
3. Cities and Geographic Regions
City and regional TLDs named for a particular place can concentrate tourism, local businesses, cultural institutions, and citizens into a unified namespace. Municipalities or regional authorities can use them to:
- Standardize official digital addresses for public services and agencies
- Create a recognizable local identity for businesses
- Offer local-language or local-script domains for inclusivity
Geographic name rules in Guidebook section 7.5 distinguish unavailable country or territory names from geographic categories requiring government or public-authority support or non-objection. These include capital names, city names intended for a city-associated purpose, and specified subnational or regional names. All applications are screened even if the applicant does not self-designate a geographic name. A support letter does not make an otherwise unavailable country name eligible; community endorsement is a separate issue.
4. Platforms and Ecosystems
A platform may want to structure participant addresses under a common namespace, but the proposed registration model must fit the applicable application and contract rules. Do not assume that third-party merchant registrations qualify under .Brand terms, or that a generic sector term may be reserved exclusively for the platform’s own benefit.
A platform could evaluate this option during architecture or capacity planning for multi-tenant SaaS. If you are already thinking about multi-tenant architectures for SaaS apps and the hosting infrastructure behind them, a dedicated TLD is one possible long-term naming option, subject to policy and financial feasibility.
5. Who Probably Should Not Apply (Yet)
If you are an individual site owner, a small business with limited IT capacity, or a brand that is still stabilizing its marketing and naming strategy, a gTLD is usually overkill. The costs (both application and ongoing operations) are substantial, and you will need to maintain compliance and technical resilience for years.
In those cases, choosing the right combination of available domains (.com, ccTLDs, relevant existing new gTLDs) is usually a better fit. Our guide on planning a domain strategy with ccTLD vs gTLD and international SEO is a solid place to start.
2026 Rules and Existing Registry Obligations
Separate changes specific to the 2026 application process from obligations that already apply to contracted registries and registrars. The RSP Evaluation Program and rules on private contention resolution matter to this round; DNS abuse and registration-data requirements also have their own earlier implementation dates.
Registry Agreement and Continuing Duties
Registry operators sign a detailed Registry Agreement with ICANN. Key areas to review in the applicable agreement include:
- DNS abuse: Relevant contract amendments took effect on 5 April 2024; they were not first introduced by the 2026 round.
- Registration data: The Registration Data Policy took effect on 21 August 2025. Use its current requirements and applicable privacy law.
- Technical service: DNS, DNSSEC, EPP, RDAP and data escrow must meet the applicable agreement and evaluated service requirements; ordinary hosting uptime is not the full obligation.
We have already covered many of these policy themes in our article ICANN New gTLD Policies and what they mean for your domains. Use the current ICANN agreement and Guidebook for application-specific decisions.
Public Interest, Safeguards and Closed Generics
A closed generic is a generic string proposed for exclusive operation for the operator’s own benefit. ICANN does not permit closed generic applications under the current framework; claiming a public-interest benefit is not an available workaround. A qualifying .Brand TLD and a community registry with membership conditions are different models.
For a permitted model, document how the applicable commitments will work in practice:
- Required safeguards and public-interest commitments, including those relevant to regulated sectors
- Eligibility, verification, complaints and enforcement rules appropriate to the registration model
- Community registration policies or voluntary commitments that ICANN can evaluate and incorporate into the agreement
String Contention and Objections
Two or more applicants may apply for the same or confusingly similar string. ICANN has well-defined processes for:
- String evaluation for relevant similarity and eligibility rules
- Objections through the specific procedures and standing requirements in the Guidebook
- Contention resolution through permitted program mechanisms, including eligible Community Priority Evaluation and, where necessary, ICANN auctions
Private auctions, joint ventures or other arrangements designed to resolve contention privately are prohibited. There are also restrictions on direct and indirect communications among applicants in the same contention set. Read these with qualified counsel before discussing competing applications. Community designation does not automatically win priority, and a prioritization draw determines processing order rather than entitlement to a string.
To keep up with the broader domain policy trends beyond gTLDs, our article ICANN domain policy dates and implementation status provides related context; check dated policies for current obligations.
Architecture Behind a gTLD: Registry, DNS and Hosting Layers
Technical reliability is one part of TLD operation, alongside funding, policy, rights protection and compliance. Start by choosing evaluated registry services and defining what the operator, RSP and any general hosting provider will each deliver. A familiar server architecture is not evidence that a system meets registry requirements.
1. The Registry Backend (SRS, EPP, and Databases)
The registry backend is your “source of truth” for domain registration records in your TLD. Key components include:
- Shared Registration System: The authoritative registry database and services for domain and nameserver objects
- EPP: The protocol interface used by authorized registrars for registration lifecycle operations
- Data resilience: Consistent replication, recovery testing and controlled administrative access appropriate to the registry software; a specific database product is not prescribed by this guide
Guidebook section 3.1.10 requires coverage by evaluated Main, DNS and DNSSEC RSPs; one provider may cover multiple roles. The Main RSP operates the registration database, EPP, RDAP and data escrow functions. Building these services internally also requires the relevant RSP evaluation. Our guide to backup planning with RPO and RTO explains general recovery concepts; routine backups do not replace contractual data escrow.
2. Authoritative DNS Infrastructure
The TLD’s authoritative servers publish the TLD zone and referrals to delegated domains. The authoritative hosting for those domains is a separate layer. Registry DNS design must address redundancy, performance and failure domains, including:
- Distributed authoritative service: Network and geographic resilience, often using anycast as an architectural option
- DNSSEC operations: TLD signing, safe key rollovers and correct DS relationships; signing the TLD does not automatically sign every child domain
- Service monitoring: DNS availability and response behavior measured separately from EPP or RDAP availability
We have an in-depth guide on what DNSSEC is and how to set it up safely, including key rollover without breaking resolution. If you are planning to be a TLD operator, DNSSEC is a required registry function, not an optional website feature.
3. RDAP and Registration Data
Use RDAP as the required registration-data service for this round, not “WHOIS and/or RDAP.” ICANN’s RDAP guidance explains that gTLD registries and registrars must provide RDAP, while most WHOIS obligations ended on 28 January 2025; some legacy TLD agreements have exceptions. RDAP service design includes:
- One or more API/web services backed by your registry database
- Rate limiting and abuse control to avoid scraping and DDoS
- Careful handling of personal data to stay compatible with privacy regulations
RDAP uses HTTP-based services, but it is not merely a public copy of the registry database. Apply the required RDAP profile, publication/redaction rules, access handling and service levels. Rate limits, load balancing and protective controls must preserve required service behavior rather than indiscriminately blocking legitimate protocol clients.
4. Security, Logging and Monitoring
A TLD is a high-value target. As a registry, you must assume you will face:
- DDoS attacks against DNS servers or public APIs
- Credential stuffing and phishing attempts targeting your control panels
- Attempts to abuse your TLD for spam, malware, or brand impersonation
This is where classic hosting practices meet registry-specific concerns. You will need:
- Hardened systems with firewalls and access controls assigned to the responsible operator or provider
- Centralized logging across DNS, application servers, and databases
- Metrics and alerts to detect anomalies quickly
Our articles on securing a VPS for real-world threats and setting up monitoring and alerts with Prometheus and Grafana explain useful general practices. Registry-specific controls, evaluated services and contractual response duties still require a separate design.
5. General Hosting and Registry Service Boundaries
DCHost offers VPS, dedicated server and other hosting options for application infrastructure. Those products do not themselves establish RSP evaluation or registry compliance. Confirm which portals, integrations and supporting applications your team will operate, then size their hosting separately from the evaluated registry service. This article does not present DCHost as an ICANN-evaluated RSP or promise a turnkey registry operation.
Application Process, Costs and Timeline
The Guidebook was adopted on 30 October 2025 and its final V1 was published on 16 December 2025, before this article’s original publication. As of this update, V3-2026.10.07 is the authoritative version. The 2026 submission period is complete; the stages below describe the lifecycle and the work existing applicants must continue.
1. Strategy and Preparation
Preparation should connect business demand, eligibility and technical delivery. Existing applicants should revisit their assumptions as evaluation proceeds; future applicants can use the same planning questions without assuming that another submission window is imminent.
- String and eligibility: Trademark rights, unavailable names, geographic conditions and applicable IDN/variant rules
- Registration policy: Who may register and how eligibility and complaints will be handled
- Financial model: Sustainable demand, pricing and funding for continuing operations
- Technical delivery: Evaluated RSP scope, integration responsibilities, data escrow and service continuity
2. Application Submission
Applications were submitted during the 30 April–12 August 2026 window. Applicants now need to keep their file accurate and follow ICANN’s procedures for clarifications and changes. The application covers:
- Applicant identity and financial stability
- Technical capability and infrastructure plans
- Operational and abuse mitigation policies
- Rights protection mechanisms (for trademarks and brand owners)
Keep operational plans and supporting evidence aligned with the selected RSPs. A hosting diagram alone does not demonstrate eligibility or technical compliance. Changes to the application or providers should use the applicable application-change process.
3. Evaluation, Objection, and Contention Phases
ICANN published applications on 7 October 2026. The replacement period ran from 8 to 21 October. String Confirmation Day is scheduled for 17 November, followed by the announced Community Input and Objections Period through 16 March 2027. These milestones do not determine a universal launch date. The lifecycle includes:
- String review: Relevant eligibility, similarity and other string requirements
- Community input and objections: Defined channels and deadlines; different objection procedures can have their own timing
- Contention and applicant/application evaluation: Permitted contention mechanisms and the relevant financial, operational and application-type assessments
Dates for later stages depend on program announcements and the individual application. The prioritization draw is planned for 2027, with its exact date to be announced. Track ICANN notices and assigned deadlines; a prototype or an early application does not guarantee faster approval.
4. Contracting, Pre-Delegation Testing and Delegation
After the required evaluations and any contention are resolved, successful applicants enter contracting and onboarding. Registry System Testing v2.0 provides the required pre-delegation tests and also supports the separate RSP evaluation process. IANA separately handles the root-zone delegation request and the associated nameserver and DS checks.
Coordinate the production service and required tests with the evaluated RSP. Relevant readiness work includes:
- Confirmed technical service scope and integration responsibilities
- DNS, DNSSEC, EPP, RDAP and data escrow operating under the applicable requirements
- Documented incident handling, recovery, monitoring and access controls
Complete the necessary testing and IANA delegation process before relying on the TLD in public DNS. Launch plans must also follow the applicable Sunrise and Trademark Claims rules and any agreement-specific exceptions. Landrush is a commercial launch option, not a mandatory stage for every TLD. Delegation does not mean all software will accept the new suffix immediately; test domain forms, certificates, identity systems and email for Universal Acceptance, including IDNs where applicable.
5. Cost Considerations
The standard 2026 gTLD evaluation fee is USD 227,000 per application, subject to qualified Applicant Support Program and variant exceptions. This is a base evaluation fee, not the entire project budget. Include:
- Applicable conditional evaluation fees and possible objection or contention costs
- Ongoing ICANN charges under the agreement, including applicable transaction fees
- Legal/policy work, rights protection, support and abuse operations
- Evaluated RSP services, data escrow, integration and any separately operated infrastructure
Compare a multi-year service and staffing budget with a realistic demand forecast. Price conditional processes separately and allow for delays. Cost planning should begin with required registry functions and responsibilities; choosing inexpensive VPS instances is not a substitute for satisfying those requirements.
Risk Management: Security, Abuse and Brand Protection
Operating a TLD does not automatically make your namespace safe. You must actively manage risk on several fronts.
1. Abuse Mitigation and Reputation
ICANN’s contractual DNS abuse definition covers malware, botnets, phishing and pharming, plus spam when it delivers those harms. An operator may have broader acceptable-use policies, but those should not be confused with the contractual definition. Evidence handling, registrar coordination and timely proportionate mitigation are operational duties; a WAF does not by itself address abuse of domains under the TLD.
Practical steps include:
- Clear AUP and enforcement mechanisms in your registration policy
- Abuse reporting channels and SLAs for investigation
- Automation to detect patterns in DNS and registration data
Use signals from reporting channels, registry data and appropriate monitoring to support investigation. Keep an auditable record of evidence, decisions and escalation, with privacy controls. Hosting-layer logs and rate limiting are useful for your own services, while abuse of registered names may require action with registrars and other responsible parties.
2. Domain Security and Locking
Your own core domains under the new TLD – registry portals, support sites, APIs – must be especially well-protected. Use strong authentication, carefully scoped administrator access, registrar transfer locks, DNSSEC where appropriate, and registry lock where supported. These controls address different risks and do not guarantee that a website or mailbox cannot be compromised.
We have a dedicated domain security guide, Domain security: locks, DNSSEC, privacy and 2FA, which outlines the same practices you will want to enforce for your own high-value domains and encourage (or require) for critical registrants.
3. Brand Protection and Conflicts
Even as a registry, you remain a brand owner operating in a global domain marketplace. You may still need:
- Defensive registrations in other TLDs to avoid confusion
- Monitoring for typosquats and lookalikes
- UDRP/URS strategies for disputes that spill beyond your own TLD
If your TLD is part of a broader migration or rebrand, our guide on planning a domain change and SEO migration can help you plan redirects, SSL, and DNS changes while monitoring search visibility during the transition. No move can guarantee unchanged rankings. Google treats new gTLDs as generic extensions; a new suffix does not itself provide a ranking boost. Most country-code TLDs have separate geographic-targeting implications.
Google’s international-site guidance distinguishes generic extensions from country targeting. If URLs change, map each old page to its new equivalent and update links, canonical URLs and sitemaps; do not redirect every old URL to a single homepage.
How We Suggest Planning Your Next Steps
Keep policy, technical delivery and business funding in one plan, with a named owner for each decision. Existing 2026 applicants should prioritize their live application obligations. Organizations considering a later round can assess feasibility without treating an unannounced date as a commitment.
1. Clarify the Strategic Why
Start with a short but honest internal document answering:
- What problem does this TLD solve for us or our community?
- How will success be measured in 5–10 years?
- Is this primarily about brand control, security, community building, or revenue?
This helps cut through “it would be cool” thinking and forces a realistic conversation about resourcing and long-term commitment.
2. Map Requirements to Infrastructure
Translate your policy and business goals into concrete infrastructure requirements. For example:
- A qualifying .Brand model may have fewer registrations, but still needs evaluated services, security and contractual compliance.
- An open, high-volume model adds registrar integration, capacity, support and abuse workloads; model DNS, EPP and RDAP traffic separately.
- Neither limited registration volume nor a restricted community removes the need to meet applicable registry obligations.
Ask the RSP to explain capacity assumptions, recovery plans and service boundaries. Size any separately hosted portals or integrations for realistic demand and identify dependencies that could fail together. Test provider handover and operational escalation plans, not just expected traffic volume.
3. Test Integrations and Operations
A test environment helps teams understand registry workflows and detect integration problems. Use an RSP-provided sandbox or a subdomain you control, with test credentials and data. Do not invent a private production suffix that could collide with future public names. The rehearsal should exercise:
- Registrar or management workflows and access restrictions relevant to your role
- Incident escalation, backups, restore procedures and monitoring responsibilities
- Domain and email acceptance in real client applications, including longer suffixes and relevant scripts
A successful rehearsal is evidence of your own operational preparation; it is not ICANN approval and does not replace formal RSP evaluation or required registry testing. Keep the test environment separated from production registrations and user communications.
4. Align with Your Existing Domain Portfolio
A new gTLD does not replace your existing domains overnight. You will still manage .com, ccTLDs, and other gTLDs for years. Think through:
- Which properties migrate to the new TLD and on what timeline
- What will remain on legacy domains for SEO, email stability, or regional reasons
- How redirects, certificates, and DNS records will be managed across all of them
Our guide on domain portfolio management for renewals, billing and brand protection is a useful counterpart here; TLD operation adds a separate set of continuing contractual and technical responsibilities.
5. Build a Cross-Functional Team
Successful TLD projects are not purely IT or purely marketing. You will need at least:
- Technical leads for DNS, servers, security and monitoring
- Legal and policy expertise for ICANN processes, contracts and rights protection
- Operational staff for abuse handling and any registrant or registrar support required by the model
- Brand/communications roles to explain the TLD to users and partners
For DCHost hosting services, confirm the technical scope and management responsibilities in the service proposal. Retain separate qualified advice for ICANN applications, registration policies and rights protection, and select evaluated RSP services for the registry functions. No hosting provider should be assumed to cover those roles merely because it offers DNS or dedicated servers.
Choose the Next Step for Your Role
The 2026 application period has closed, but evaluation and preparation continue for applicants. Follow the current Guidebook, ICANN notices and provider commitments. For brand owners, review published applications and consider whether an objection, watch list or future registration serves an actual business need.
If you have not applied, build the business case and team before making a future commitment, and wait for an officially announced submission opportunity. Buying an ordinary domain in a launched extension remains a different, usually much smaller decision. Neither application publication nor a registrar expression of interest guarantees that your preferred domain will become available.
DCHost can be considered for the general hosting layer of your website or supporting applications. Discuss actual workloads and service scope with the team. A registry project additionally requires evaluated RSP services, sustained funding and specialized policy expertise; establish those responsibilities before committing infrastructure spend.
