ICANN 2026 gTLD Rules: Brands and Domain Strategy

The 2026 gTLD Round: What Was Known on 4 December 2025

On 30 October 2025, the ICANN Board adopted the Applicant Guidebook (AGB) for the 2026 new gTLD round, announcing the milestone on 3 November. This article explains the framework as known on 4 December 2025. At that point, ICANN was targeting April 2026 for the application window. Applying for an extension, completing evaluation, delegation to the DNS root and opening registrations were separate stages, with different timing.

The Board directed publication of the guidebook, including dispute resolution provider rules, by 30 December 2025. Work such as finalising the base Registry Agreement was still outstanding. The distinction matters: adoption of the framework did not mean applications were already open or every operating term was final. Contractual DNS abuse amendments effective since 5 April 2024 also belong to a separate timeline and should not be described as entirely new requirements created by the next round.

For most businesses, the useful decision is which developments to monitor and how to organise existing domains. For a prospective registry operator, the task is much larger: eligibility, funding, service providers and long-term governance. This guide separates those responsibilities, identifies concrete adopted rules and translates them into domain planning without promising better rankings, automatic trust or immunity from phishing.

Quick Refresher: ICANN, gTLDs and the New Round

Before diving into policy details, it helps to align on a few core concepts. If you already live in this world every day, treat this as a quick checklist to be sure we are using the same vocabulary.

ICANN and the role it plays

ICANN (the Internet Corporation for Assigned Names and Numbers) coordinates the global domain name system. It does not sell domains directly. Instead, for gTLDs, its policy and contractual framework covers:

• Registries – the operators of gTLDs
• Registrars – the retail providers where you register domains
• Policy – rules for how TLDs are created, operated and governed

The new policy updates we are talking about focus on new gTLDs – future extensions beyond the familiar .com, .org, .net and the first wave like .shop, .app, .blog and hundreds of others.

What exactly is a new gTLD?

A gTLD (generic top-level domain) is a TLD in the generic rather than the country-code category: .com, .info, .shop, .online, .cloud and so on. “Generic” does not necessarily mean open to everyone; brand and community TLDs can restrict registration. A new gTLD is simply a gTLD that comes out of ICANN’s recent and upcoming application rounds.

ICANN’s October 2025 Board resolution records that the 2012 round added more than 1,200 gTLDs to the namespace. The 2026 guidebook builds on the Subsequent Procedures (SubPro) policy process and related work. Its adopted framework provides a basis for planning; it does not guarantee that every applicant will succeed or that all extensions will launch together.

Why this next round is different

The October 2025 guidebook identifies specific changes from the 2012 round. These are more useful than a general claim that every rule became stricter. In particular, the framework includes:

• A separate RSP Evaluation Program for the technical services behind a registry.
• Rules excluding closed generic applications and prohibiting private resolution of application contention.
• Defined evaluation paths for brand, community and geographic applications.
• A predictability framework for handling unexpected implementation issues, alongside applicant support and internationalised domain provisions.

For digital strategy, the program may create additional options if applications succeed. The useful task is to connect each adopted rule to a real decision: applying for a TLD, monitoring a candidate string or maintaining an existing domain. A larger catalogue of possible names is not itself a reason to expand your portfolio.

Key ICANN Policy Changes for the Next New gTLD Round

SubPro means Subsequent Procedures: the policy work underlying another application round. For this historical overview, the reference point is the guidebook adopted on 30 October 2025, not a later revised edition. Applicants must use the applicable published edition and contract when they actually apply. The following sections distinguish adopted procedures from planning advice.

1. A more structured application and evaluation process

The guidebook sets out application submission, community input, objections, contention resolution and applicant/string evaluations. Different applications may pass through different conditional steps. A documented process helps budgeting, but it cannot promise a fixed completion date or remove the possibility of objections and unsuccessful evaluation.

The adopted framework separates several planning questions:

• Who is applying? Entity eligibility, background screening and financial/operational preparation need evidence.
• Which services will run the registry? Required technical services must come from successfully evaluated RSPs.
• What does it cost? The adopted base application fee was US$227,000, excluding additional applicable conditional evaluation fees and ongoing operating costs.

A brand, community or sector project should therefore be a joint legal, financial and technical assessment. Application fees are not the whole project budget, and a familiar name does not establish eligibility. Our So, you want your own dot? A deep dive into ICANN’s next gTLD application round explains the broader application journey; use the applicable ICANN guidebook to check actual requirements, deadlines and submission details before committing funds.

2. Registry Service Provider (RSP) frameworks

RSPs provide critical technical services such as authoritative DNS, DNSSEC operations and registration data access through RDAP. The RSP Evaluation Program opened on 19 November 2024. Its central change is to separate assessment of those technical capabilities from the application for a particular TLD label. A provider can support multiple applications after the relevant evaluation rather than repeating the entire technical assessment for each one.

What changes in practice:

• Evaluation status: All applicants must use successfully evaluated RSP services; verify the provider and the services covered.
• Separate roles: An RSP can be the applicant itself or an outside provider. Outsourcing technical work does not erase the registry operator’s responsibilities.
• Service scope: Record who handles DNS, DNSSEC, registration data, monitoring and incident coordination. An ordinary hosting plan is not evidence of RSP qualification.

From a hosting perspective, assess where your zones live and how DNSSEC is handled when expanding your domain portfolio. For each candidate TLD, verify that your chosen registrar and DNS hosting plan support the DNSSEC setup you intend to use.

3. Fairness and contention for popular strings

Applications for identical or otherwise conflicting strings can form a contention set. The adopted framework specifies ways to resolve that competition. It does not establish that auctions will become rare, nor that the applicant with the most recognisable brand automatically wins. Examine the relevant process before treating a desired string as an asset you will obtain.

The concrete rules include:

• No private resolution: Private auctions and other private arrangements to resolve contention are prohibited, including joint ventures after submission.
• Defined alternatives: The guidebook provides for replacement strings under its conditions and Community Priority Evaluation for eligible community applicants.
• ICANN auctions: Contention that remains subject to auction follows the ICANN process; applicants should budget for uncertainty instead of predicting how often auctions will occur.

For most registrants this plays out indirectly: it affects which TLDs ultimately make it to market, and under what rules they must operate. But if you are a brand or an association thinking about a community‑oriented TLD, these policies directly shape your governance obligations and how you will need to manage registrations under your TLD.

4. Greater focus on predictability and future rounds

The guidebook includes a predictability framework for unexpected issues during implementation. This is a procedure for managing changes, not a guarantee of annual rounds or a fixed launch date for every successful application. As of this article’s December 2025 reference date, the next window was targeted for April 2026; future rounds should be planned against their own announcements.

For your planning, this means:

• Consider medium‑term timing for a brand TLD, but commit resources against announced application windows rather than an assumed schedule.
• Allow for the possibility that new TLDs will continue to emerge, without assuming a predictable launch cycle.
• You should start treating TLD choice as part of ongoing architecture decisions, not a static one‑off.

We covered this mindset shift more broadly in our article ICANN domain policy changes and what they mean for your domains. The new gTLD policy updates are one of the most important pieces of that bigger puzzle.

DNS Abuse and Rights Protection: Separate Rules and Timelines

Security and rights protection involve several mechanisms with different purposes. Registry and registrar abuse duties arise from their respective contracts. Trademark disputes have their own eligibility and evidence requirements. DNSSEC authenticates signed DNS data. Combining these into a single claim of stronger protection obscures which party can take which action.

Stronger obligations around DNS abuse

The DNS abuse amendments took effect on 5 April 2024, before the 2026 guidebook was adopted. The contractual definition covers malware, botnets, phishing, pharming and spam when it delivers those other forms of abuse. Registry and registrar roles are distinct; the amendments do not mean every complaint must lead to immediate suspension.

• Actionable evidence: Available information must support a reasonable determination that DNS abuse is occurring; an allegation alone is not automatically proof.
• Appropriate action: Registrars act to stop or disrupt abuse; registries may refer the matter to the registrar or take direct proportionate measures as appropriate.
• Context matters: Promptness depends on the case. Suspending a compromised domain can also interrupt legitimate services, so collateral effects must be considered.

For a domain holder, keep an incident contact reachable and be ready to secure a compromised site, preserve useful evidence and coordinate with the provider. Neither a new TLD nor DNSSEC certifies safe content. The contractual changes do not guarantee inbox delivery or a favourable browser reputation; site security, mail configuration and receiving systems remain separate factors.

Rights Protection Mechanisms and Their Limits

Distinguish an objection to a proposed TLD from a dispute about a second-level domain registered later. The guidebook describes formal objections based on string confusion, legal rights, limited public interest and community grounds, each with its own standing and procedure. Public comments and GAC inputs are separate channels. For domain registrations, useful mechanisms include:

• Trademark Clearinghouse: Trademark records support applicable Sunrise and Trademark Claims services; a record is not a right to every similar domain.
• URS and UDRP: These have different procedures and remedies. URS addresses clear-cut abusive registrations through suspension; it is not an automatic transfer or a universal content-removal tool.
• Registry-level disputes: Post-delegation procedures address defined contractual or rights issues; their scope is not every undesirable website.

The guidebook’s adoption does not justify promising that all these mechanisms became simpler or more effective in every case. Prioritise relevant registrations, monitor likely misuse and choose the appropriate response based on evidence. Legitimate criticism is not automatically infringement. Our Defensive domain registration strategy for brand protection discusses how selective defensive registration fits alongside monitoring and dispute handling.

Implications for DNS and hosting architecture

For an ordinary domain owner, keep these practical controls separate from registry qualification:

• DNSSEC: A signed TLD does not automatically sign your domain’s zone. Your DNS host, keys and parent DS records require a coordinated setup.
• Registration data: RDAP is an access protocol; publication, redaction and disclosure rules come from applicable policies and law.
• Abuse response: Patch and secure hosted applications and respond to credible incidents. A registry-level contract does not replace server administration.

For hosting operations, define access controls, update ownership and a proportionate logging policy. Log retention on hosting and email infrastructure for compliance discusses retention considerations; collecting more logs does not by itself establish legal compliance. When selecting a VPS or dedicated server, confirm which security and management tasks are included in the specific service and which remain with your team.

Closed Generics, Brand TLDs and Community Applications

Another major policy theme has been how to treat closed generics, brand TLDs and community TLDs. This matters for both companies dreaming about .brand and for everyone else who will later decide if they should register under those TLDs.

Closed generics: private control of common words

A closed generic, called an exclusive-use generic string in the guidebook, is a generic term proposed for exclusive use by one entity or a restricted related set. The relevant definition and intended use matter; a restrictive registration policy is not by itself a complete classification. Do not assume every community restriction is the same as exclusive corporate use of a generic word.

The October 2025 adopted guidebook states that closed generic applications will not be approved unless and until an approved methodology and criteria exist to assess public interest. Applicants must affirm that they are not applying for, and do not intend to operate, a closed generic string. Plan this round on that basis. Planning should therefore distinguish the following:

• A closed generic proposal cannot proceed in this round simply by asserting that exclusive use benefits the public.
• A .brand application has a separate definition and eligibility evaluation tied to an appropriate registered trademark and other conditions.
• Community and other restricted registration models require their own analysis; their names and policies do not automatically qualify for an exception.

This exclusion does not mean every generic-looking extension will be open to every buyer. Before planning a registration, check the eventual registry’s eligibility and launch rules. An application list is not a catalogue of approved, available domains, and brand or community conditions can restrict access even after a TLD is delegated.

Brand TLDs: clearer expectations and use cases

A .brand designation requires a specific eligibility assessment. A company does not qualify merely because it calls a string its brand or operates a polished website. The adopted guidebook and Specification 13 framework distinguish the qualifying trademark, the entity and the permitted registration/control model:

• The string must meet the applicable registered-trademark matching and eligibility requirements; “closely related” is not a sufficient test.
• Registrants and control of associated DNS records are limited to the registry operator, its affiliates or qualifying trademark licensees under Specification 13.
• A reseller or distributor relationship alone does not establish qualifying trademark-licensee status. Assess the agreement, entity and actual use against the definition.

From a strategy perspective, a brand TLD can support:

• Consistent names: A hypothetical shop.brand or support.brand can group services under one naming scheme.
• Recognisable communication: Users must still learn the address pattern; the extension does not guarantee trust or prevent look-alike domains elsewhere.
• Separate services: Names can distinguish portals or environments, but access control is needed to make an internal service private.

But it also introduces operational overhead: DNS, certificates, hosting, redirects and SEO need to be designed carefully. Our article The calm domain playbook: ccTLD vs gTLD and international SEO is a good companion read when you start modelling how a brand TLD would coexist with existing .com, ccTLDs and subdomain structures.

Community and geographic TLDs: governance really matters

Community TLDs (for example, representing a professional group or a cultural community) and geographic TLDs (city or region names) are also covered by the updated policies.

Key themes include:

• Community claims: Define the community, its connection to the string, registration policies and support; Community Priority Evaluation applies its stated criteria.
• Geographic review: Some defined categories require support or non-objection from relevant governments or public authorities; not every sector or geographic-sounding word has the same requirement.
• Documented commitments: Evaluate the actual application type and obligations rather than assuming a community label guarantees approval or superior governance.

For a local business, the practical task is to review eligibility and purpose if a relevant extension eventually launches. A city-themed name does not guarantee credibility or a search advantage, and new gTLD policy does not replace country-code registration rules. Add an extension to your portfolio only when the use case and recurring costs are clear.

How ICANN’s Updates Affect Registrants, Brands and Hosting Providers

ICANN focuses on policy and contracts, but the consequences land on three very practical players: people who register domains, brands and organisations with portfolios, and the hosting providers who run the servers and DNS behind those domains.

For individual registrants and small businesses

If you manage a handful of domains for your own project or small business, here is what these updates mean in day‑to‑day terms:

• Potential choice: Successful applications may eventually add extensions relevant to your sector or community, subject to evaluation and launch conditions.
• No automatic upgrade: The guidebook does not improve the rankings, mail delivery or security of your existing domains by itself.
• Selective adoption: Decide whether a new name serves users or protects a concrete risk before adding ongoing renewal and administration costs.

We strongly recommend building a lightweight but clear domain plan: primary domain, defensive registrations, redirects and which TLDs you deliberately ignore. Our article Domain portfolio management: organising renewals and brand protection offers a practical framework even if you only hold a modest number of domains.

For brands and organisations with larger portfolios

If you manage dozens or hundreds of domains, ICANN’s updated policies are your signal to revisit both defensive registration and the question of a brand TLD.

Consider:

• Monitoring: Track relevant applied-for strings and, later, actual launch conditions rather than trying to buy every possible name.
• Governance: Assign ownership and renewal responsibility and maintain a common inventory across departments.
• Security: Review account protection, supported locks, DNSSEC setup and change approval. Domain security best practices provides a practical starting checklist.
• Feasibility: Assess .brand eligibility, RSP services, funding and multi-year operation against the option of keeping your existing domains.

Map each important domain to its DNS host, mail service and application endpoints. Record who renews certificates and who can authorise a DNS or registrar change. Keep staging and production access separate even if their names look related. This architecture review is useful for an existing portfolio and does not depend on a successful new TLD application.

For hosting and infrastructure teams

Infrastructure teams can prepare by checking how applications accept and configure domain names. That is a compatibility exercise, not a claim that the new guidebook imposes registry obligations on every hosting provider. Keep technical service requirements scoped to the role your organisation actually performs.

Useful operational checks include:

• Name handling: Avoid fixed lists or length assumptions that reject otherwise valid TLDs; test the domain forms your applications need.
• DNSSEC capability: Where adopted, document signing, parent DS coordination and recovery. TLD signing alone is not enough for your zone.
• Mail setup: Verify sending identities, SPF, DKIM, DMARC and relevant forward/reverse DNS. Correct configuration does not guarantee inbox placement.

For self-managed infrastructure, securing a VPS server and what DNSSEC is and how it secures your site cover different parts of this work. Neither a server-hardening checklist nor enabling DNSSEC proves compliance with the RSP Evaluation Program. Confirm the specific service scope, operational owner and recovery path before making changes to production domains.

Practical Roadmap: How to Prepare for ICANN’s New gTLD Era

Use the following roadmap as a planning sequence from the article’s December 2025 perspective. It is not a promise that new extensions will be available within a fixed number of months. Begin with work that is useful for your current portfolio, then add checkpoints tied to official application and launch announcements.

1. Audit your current domain portfolio and architecture

Start by listing:

• All domains you own (including old project leftovers)
• Which TLDs they use (.com, ccTLDs, existing new gTLDs, etc.)
• Where their DNS is hosted, and whether DNSSEC is enabled
• Which hosting or VPS servers they point to

Then ask:

• Which domains are critical to websites, email, authentication or recovery and must remain under control?
• Which appear unused but still receive mail, old links or password-reset messages? Check these dependencies before allowing expiry.
• Where do shared logins, missing renewal ownership or an untested DNSSEC setup create avoidable risk?

Having this map makes it much easier to decide how new gTLD options fit in, instead of blindly adding more domains whenever a new extension launches.

2. Choose a Focused, Selective or Defensive Registration Policy

Not every organisation needs to chase every new TLD. Define a clear stance:

• Focused: Keep a small set of established domains and consider new registrations only for a documented use case.
• Selective: Monitor defined industry, language or geographic categories and prioritise relevant launches.
• Defensive: For a frequently targeted brand, budget for selected high-risk names and monitoring together. Broad registration cannot eliminate all possible impersonation.

Document this stance and communicate it internally. That way, new TLD launches become a checklist‑driven decision, not a source of endless ad‑hoc debates.

3. Strengthen domain security before adding more complexity

Before you layer in more TLDs, fix the basics:

• Enable registrar lock on all important domains.
• Use 2FA on registrar and DNS control panels.
• Adopt DNSSEC for your key domains where supported by the TLD and DNS host.
• Implement SPF, DKIM and DMARC for your primary email‑sending domains.

These controls address different failure modes; no single checkbox prevents every hijack, compromise or certificate problem. Keep recovery access available and verify the result of each change. Our domain security best practices can help organise the work without treating a security feature as a guarantee that incidents cannot occur.

4. Follow Official Application and Launch Milestones

At the December 2025 reference date, the next-round application window had not opened. The adopted process anticipated several later milestones that should be tracked separately:

• Publication of applied-for strings and the public portions of applications.
• Community input, formal objections, evaluations and any applicable contention resolution.
• Contracting and delegation for successful applications, followed by each registry’s applicable launch and registration arrangements.

As soon as those lists become available, build a simple internal spreadsheet or tracker for:

• TLDs likely relevant to your brand or sector.
• Risky or look‑alike strings you may want to monitor defensively.
• TLDs that offer interesting branding or campaign opportunities.

Update the tracker as evidence changes. A published application does not reserve your brand’s second-level name or prove the TLD will launch. If a relevant registry later announces Sunrise or general availability, check eligibility, terms and dates before deciding to register. A .brand or other restricted TLD may not offer general public registration at all.

5. Evaluate whether a brand TLD belongs in your 3–5 year plan

A .brand project needs a separate feasibility assessment even when its intended use is clear. Include the base application fee, potential conditional fees, RSP and legal work, staffing and recurring obligations. Do not equate owning ordinary domains or buying hosting with readiness to operate a registry. Useful assessment questions include:

• Does the proposed string and applicant meet .brand eligibility, and do intended registrants fit the permitted model?
• What measurable naming or operational benefit would justify the project compared with existing domains and subdomains?
• Who owns registry governance, evaluated RSP services, application migration, certificates and long-term funding?

You do not have to decide “yes” now. But you should avoid being in the position where the application window opens and closes before you have even done the basic thinking. Our deep dive on ICANN’s next gTLD application round and whether a brand TLD fits you can help you frame that internal discussion.

6. Align your hosting and DNS with a multi‑TLD future

Finally, test the domain names and registration models that your services will actually use. A new suffix should not be rejected because an application uses a stale allowlist, but every provider and workflow still has its own supported features. Review the following separately:

• DNS record support and the DNSSEC/parent DS process for the chosen registrar and DNS host.
• The actual certificate issuance and renewal workflow supported by your web hosting or server plan; verify required domain validation and any wildcard limitations.
• Application routing, redirects, email and deployment configuration for the intended hostnames, including a recovery plan for changes.

Pointing DNS at a server is only one part of bringing a domain into service. The application must accept the hostname, TLS must cover it and mail or authentication dependencies must be configured separately. Verify these capabilities with the provider and through a controlled test rather than assuming every new suffix works with every product feature.

Conclusion: Turn Adopted Rules into a Clear Domain Plan

As of 4 December 2025, the concrete milestone was Board adoption of the 2026 Applicant Guidebook. Separate RSP evaluation, exclusion of closed generics and the prohibition on private contention resolution were established parts of that framework. The planned application window was not the same event as approval, delegation or public registration of any particular extension.

Most organisations can start with a current domain inventory, clear renewal ownership and selective monitoring. A prospective .brand operator needs a larger assessment of eligibility, funding and technical services. Keep ordinary site security and DNS work in scope, but do not present them as a substitute for registry qualification or as proof of a search, trust or availability advantage.

Assign someone to follow official ICANN milestones and record why each potential registration or application matters to the business. Confirm specific hosting, DNS, certificate and mail requirements with the chosen providers. Bring legal eligibility and trademark disputes to the appropriate specialists. A small, documented first step is more useful than a portfolio of names with no owner, budget or purpose.