New gTLDs: what is "String Confirmation Day"?

While Reveal Day is the moment the world first sees the new gTLD applications, String Confirmation Day is the date when the list is "locked in" and the official contest begins.

It is a brand-new milestone introduced for the 2026 Round to help streamline the process and reduce the chaotic legal battles seen in previous years.

The 14-Day "Pivot" Window

The reason String Confirmation Day exists is to account for the String Replacement Period. Here is how the timeline works:

• Reveal Day (Oct 2026): ICANN publishes all applications. For the first time, an applicant for .patatras sees that five other companies also applied for .patatras.
• The 14-Day Window: Applicants who find themselves in "contention" (competing for the same name) have 14 days to decide if they want to switch to a Replacement String they pre-submitted in their application.
• String Confirmation Day (Nov 2026): This occurs exactly 14 days after Reveal Day. It is the day ICANN publishes the final, stabilized list of strings after all "pivots" and replacements have been made.

Why It Is Important

String Confirmation Day serves as the official "starting gun" for several critical legal and administrative phases:

• Final Contention Sets: Once this day passes, you can no longer switch names to avoid a fight. If two people are still applied for the same name, they are officially in a "contention set" that must be resolved (usually via auction or agreement).
• Objection Period Starts: The 104-day window for third parties (brands, governments, etc.) to file formal objections begins on this day.
• Prioritization Draw: Shortly after this day, ICANN holds a "lottery" to determine the order in which applications will be processed.
• Singular/Plural Notifications: This is the deadline for anyone to notify ICANN if an applied-for string is a singular or plural version of an existing or pending TLD (e.g., .table vs .tables).

New gTLDs: what is "Reveal Day"?

In the world of domain names, Reveal Day is the official date when ICANN (the Internet Corporation for Assigned Names and Numbers) publicly announces all the applications submitted for new generic Top-Level Domains (gTLDs).

Until this day, the specific strings (the part after the dot) and the identities of the applicants are kept strictly confidential.

Why It Matters

Reveal Day is a major milestone because it marks the shift from a private application process to a public evaluation phase. It is significant for several reasons:

• Transparency: For the first time, the public sees who wants to own what (e.g., Google applying for .whatever or a startup applying for .whosthere).
• Objection Period: It triggers a window where governments, brands, or other organizations can file formal objections if they believe a proposed domain is confusingly similar to an existing one or violates specific policies.
• Contention Awareness: It reveals "contention sets"—situations where multiple parties have applied for the same string (like 13 different companies all applying for .youbet).

Historical Context: The 2012 Round

The most famous "Reveal Day" occurred on June 13, 2012. ICANN held a massive press conference in London to announce 1,930 applications. This event fundamentally changed the internet landscape, leading to the thousands of non-traditional endings we see today, like .app, .guru, and .pizza.

Upcoming: The 2026 Round

ICANN is currently preparing for the next major round of new gTLDs. According to the current timeline for the 2026 Round:

• Application Window: Expected to open in April 2026 and close in August 2026.
• Reveal Day: Scheduled for October 2026.

On that day in October, the industry will finally find out which new brands and generic terms are being proposed for the next generation of the web.

New gTLDs: what is a good Backend Registry offer?

Below is a clear, up‑to‑date, citation‑backed overview of what constitutes a good backend registry offer for new gTLDs, based on the latest ICANN RSP Evaluation Program information and industry guidelines.

✅ What Makes a Good Backend Registry Offer for a New gTLD?

A strong backend registry offer (i.e., Registry Service Provider / RSP solution) must satisfy ICANN’s technical, operational, security, and compliance expectations, while also supporting the business goals of the registry operator.

Based on the latest ICANN 2026 RSP Evaluation Program updates and industry resources, here are the essential components:

1. Full Compliance With ICANN’s RSP Evaluation Requirements

A good backend provider should be officially evaluated under ICANN's Registry Service Provider Evaluation Program.

ICANN now publishes a list of evaluated RSPs, showing which backend operators have passed technical screening and full technical testing. This gives applicants clarity and de‑risks choosing a backend. [newgtldpro....icann.org], [tldz.com]

Being on the evaluated list ensures the provider meets standards for:Stability
Security
Resilience
Scalability

2. Robust DNS & Anycast Infrastructure

A backend registry must provide globally distributed authoritative name servers with Anycast routing for high uptime and fast responses. [newgtldprogram.com]

Key elements:Global Anycast network
High availability & redundancy
Low latency resolution
Proven operational history

3. Full DNSSEC Support

Good backend operators must deliver automatic DNSSEC signing, key management, and rollover automation to ensure domain authenticity and security. [newgtldprogram.com]

4. EPP-Based Provisioning for Registrars

The backend must run a robust Extensible Provisioning Protocol (EPP) system that supports:Domain create/update/delete
Registrar authentication
High throughput
Full ICANN compliance [newgtldprogram.com]

5. RDAP / WHOIS Services

Compliant Registration Data Access Protocol (RDAP) or WHOIS services must be offered, with:Secure data access
ICANN policy compliance
Real‑time accuracy [newgtldprogram.com]

6. High-Availability Registry Database

The registry database is the heart of TLD operations. A strong backend provides:Redundant data centers
24/7 monitoring
Automated failover
Transaction logging [newgtldprogram.com]

7. ICANN Compliance, Reporting & Data Escrow

Backend operators must support:Monthly ICANN reporting
Automated policy enforcement
Accredited data escrow services [newgtldprogram.com]

Some providers (e.g., DENIC Services) bundle DNS, Anycast, DNSSEC, and escrow in one package. [gtld.directory]

8. Support for IDNs & Additional Registry Services

As of March 2026, ICANN includes evaluation criteria for:IDN support
Additional registry services [newgtldpro....icann.org]

Choosing a backend capable of multilingual domain management is increasingly important.

9. Scalability & Multi‑TLD Capability

A good backend registry has experience running many TLDs simultaneously and can scale to:Large registration spikes
Sunrise / Landrush phases
Global marketing launches [newgtldprogram.com]

ICANN emphasizes that RSPs should be evaluated once and then host multiple gTLDs, ensuring proven multi‑TLD readiness. [cadeproject.org]

10. Transparent Pricing & Flexible Business Models

While pricing details vary, strong offers typically include:Predictable per‑domain or per‑TLD pricing
Optional premium domain support
Flexible service tiers (startup vs enterprise)
Migration support

Industry directories highlight that providers range from enterprise‑grade operators to flexible, modern platforms tailored to different business sizes. [newgtldprogram.com]

11. Expert Advisory & Application Support (Optional but Valuable)

Some backend providers — or partnered consultants — help with:Application planning
Technical documentation
Policy development
Go-to-market strategy [newgtldprogram.com]

Directories like the DNA Resource Directory and The gTLD Directory list vetted partners offering legal, technical, and strategic expertise. [thedna.org], [gtld.directory]

✅ Summary: What a “Good Backend Registry Offer” Looks Like

A top-tier backend registry offer should include:
RequirementWhy It Matters✅ Evaluated by ICANN’s 2026 RSP Program Ensures technical and security compliance
✅ Global DNS + Anycast Network Fast, reliable resolution worldwide
✅ DNSSEC Support Security and trust
✅ Robust EPP Provisioning Seamless registrar operations
✅ RDAP/WHOIS ICANN-required public data access
✅ High-Availability Registry DB Core stability
✅ Reporting + Data Escrow Compliance and disaster recovery
✅ IDN-ready Global market capability
✅ Scalable multi-TLD architecture Future‑proofing
✅ Optional advisory services Helps non-technical applicants

Should you add Web3 to your new gTLD project?

Short answer: Maybe—but only if your goals, infrastructure, and target audience align with what Web3 actually offers.

Below is a structured evaluation supported by current industry analysis and real examples pulled from the search results.

✅ Reasons You Should Add Web3 Integration

1. The next ICANN round is already leaning toward Web3
Latest industry guidance shows that Web3 will be a major strategic factor in new gTLD applications for 2026.Analysts note that “the Web3 community will be an active player in the next round of new gTLDs”.
This means you will be competing in a market where many applicants will promote decentralized identity features. [worldtrade...review.com]

2. Registries are already preparing for Web3‑ready infrastructure
Modern registry platforms are expected to support decentralized functionality:Web3‑enabled gTLDs need scalable, modular architectures that can interact with blockchain networks, decentralized identifiers (DIDs), smart contracts, and tokenized domain ownership. [dn.org]
Traditional EPP‑only registries may lag behind future expectations.
If your goal is long‑term competitiveness, Web3 readiness is becoming a differentiator.

3. Growing interest in Web2‑Web3 “bundled” domain models
Companies like Unstoppable Domains and Nova Registry already plan to offer TLDs where customers get:One DNS domain (Web2)
One blockchain domain (Web3)
as a pair under the same extension. [iptwins.com]

This shows a clear market direction: gTLDs that provide utility in both ecosystems.

⚠️ Reasons You Might Avoid or Delay Web3 Integration

1. Technical and operational overhead is significant
Web3 integration requires:API‑driven architectures (REST, JSON‑RPC, SDKs)
Interaction with multiple blockchains
Smart contract design and audits
Node infrastructure for chains like Ethereum, Polygon, Solana
[dn.org]

If your registry infrastructure isn’t prepared for this level of complexity, implementing Web3 can delay launch and substantially raise costs.

2. Web3 domains have serious governance and security downsides
Blockchain domain ownership is:Permanent (irreversible)
Tied to user wallets
Vulnerable to key loss
Missing WHOIS and recovery mechanisms
As documented, losing private keys or having a wallet compromised means the domain is gone forever, with no recovery path. [namesilo.com]
This model may cause customer support challenges and reputational risk.

3. Browser support remains inconsistent
Mainstream browsers do not natively resolve Web3 domains without:Extensions
Alternative resolvers
Special integrations [falconinternet.net]
This means the Web3 version of your domain will not be universally usable yet, limiting real‑world adoption outside crypto‑native audiences.

4. Trademark protection becomes more complex
Brand owners will face new infringement risks:Scammers using wallet‑based identities
Impersonation
NFT marketplace abuse [iptwins.com]

If your target customers are enterprises, they may prefer TLDs without these new complications.

🎯 So—Should you add Web3?

Add Web3 IF:
✔ Your TLD targets tech, crypto, innovation, identity, gaming, AI, or developer communities.
✔ You want long‑term differentiation and future‑proofing.
✔ You have the budget and staffing to maintain blockchain integrations.
✔ You want to tap into early Web3 adopters and build a modern identity ecosystem.
✔ Your business strategy includes tokenized domains, wallet‑linked identities, or decentralized services.

In this case, Web3 integration is a competitive advantage.
Avoid or Delay Web3 IF:
✘ Your TLD targets mainstream consumer markets (travel, lifestyle, local, small business).
✘ You want to minimize technical and operational complexity.
✘ You are optimizing for ICANN compliance and traditional DNS reliability.
✘ Your registry team is small or you plan to outsource everything.
✘ You prefer to wait until browser support and regulatory clarity improve.

In this case, adding Web3 may be unnecessary overhead.

🧩 A Hybrid Option (Recommended for many new registries)

Many registry operators are choosing a middle path:
Offer optional Web3 features without making them core

Example approaches include:Linking DNS domains to blockchain wallet records
Offering optional NFT mirrors of DNS domains
Providing decentralized hosting via IPFS
Supporting DID or blockchain verification APIs

This avoids the complexity of full Web3 while still appealing to innovators—aligned with the scalable architecture guidance provided by current registry experts. [dn.org]

📌 Final Verdict

If your gTLD aims to be modern, future‑proof, and developer‑friendly, adding Web3 capabilities is a strong strategic move.
If your gTLD is traditional, commercial, or brand‑focused, Web3 is optional and may be unnecessary right now.

What is a "variant string" in the 2026 new gTLD applicant guidebook?

A variant string refers to a situation where a proposed top‑level domain (TLD) has other forms of the same label in different scripts, and those alternative forms are identified as variants under the Root Zone Label Generation Rules (RZ‑LGR).

In other words:

• If someone applies for a gTLD label (for example, in Arabic, Chinese, or another script),
• and that label has other related forms that are considered variants according to the RZ‑LGR,
• then the application is treated as a variant string application.

ICANN’s official 2026 FAQ states:

“If an applicant applies for a string that has other forms in different scripts—such as Arabic or Chinese—and those forms are identified as variant strings under the Root Zone Label Generation Rules (RZ‑LGR), the application is considered a variant string application.” [newgtldpro....icann.org]

🧩 Why variant strings matter

Variant strings are particularly important in internationalized domain names (IDNs). Many scripts (Arabic, Chinese, Cyrillic, Indic scripts, etc.) have characters or sequences that:

• look alike,
• represent the same underlying linguistic label, or
• behave as related forms per language rules.

Allowing all possible variants to coexist could create:

• user confusion,
• security risks (spoofing, phishing), and
• instability in the DNS.

ICANN, therefore, evaluates and restricts some variants from being delegated to ensure the DNS remains safe and predictable. Variant review is part of the technical evaluation panels being assembled for the 2026 round. [cadeproject.org]

📝 Summary (simple definition)
Variant string (2026 Applicant Guidebook)

A variant string is an alternate form of the same TLD label in a different script, recognized under the Root Zone Label Generation Rules (RZ‑LGR). Applying for a string that has such recognized variants makes it a variant string application. [newgtldpro....icann.org]

New gTLD Program: Replacement Strings?

In the New gTLD Program: 2026 Round, ICANN introduced "Replacement Strings" as a major policy update to help applicants avoid "string contention" (when two or more parties apply for the same or visually similar domain names).

Instead of being forced into a costly auction or community priority evaluation, you now have a "safety valve" to switch your choice if you see a conflict.

How it Works

1. Selection: When you submit your initial application (expected window: April 30, 2026 – August 12, 2026), you can designate a secondary "Replacement String" alongside your primary choice.
2. Reveal Day: Once the application window closes, ICANN publishes all applied-for strings (primary and replacement) on "Reveal Day" (projected for October 2026).
3. The 14-Day Window: After Reveal Day, you have exactly 14 days to assess the competition. If you see that your primary choice is in a contention set, you can choose to swap it for your pre-selected replacement string.
4. Irreversibility: If you trigger the switch, it is permanent. You cannot go back to your original choice, even if the replacement string later faces its own contention issues.

Applications Not Included in the Prioritization Draw in the next Round of new gTLDs

In the upcoming 2026 Round of New gTLDs, the Prioritization Draw remains an optional but highly recommended step for applicants who want to control their "speed to market."
Applications "not included" in the draw generally fall into two categories: those that choose not to participate and those that are disqualified from participating due to procedural failures.

1. Voluntary Non-Participants
Participation in the Prioritization Draw is not mandatory. If an applicant chooses not to buy a ticket (historically around $100) or fails to send a representative to the live draw event, their application is handled as follows:

• The "Late Batch" Treatment: These applications are not ignored; they are simply assigned a priority number after all the participating applications have been drawn.
• Randomized Order: Once the "ticket-holders" are all assigned numbers, ICANN will use the same randomized process to assign numbers to the remaining non-participating applications.
• Processing Delay: Historically, being at the end of the queue can delay your evaluation results and ultimate delegation into the root zone by several months or even over a year, depending on the total volume of applications.

2. Ineligible or Disqualified Applications
Some applications may be excluded from the draw entirely if they do not meet the strict administrative and legal criteria set for the 2026 round:

• Failure of Administrative Check: Applications that do not pass the "Admin Check" (which happens between August and October 2026) are not eligible for the draw. This includes applications with missing mandatory documents or incorrect entity information.
• Non-Payment of Fees: The full evaluation fee (approximately $227,000) must be paid within seven days of the application window closing. Failure to pay by August 19, 2026, results in immediate rejection.
• Ineligible Entities: Applications from individuals or entities that do not yet legally exist (like a "pending" joint venture) are prohibited and will not reach the draw stage.
• Tampering: ICANN reserves the right to disqualify any applicant found to be "gaming" the ticket process or attempting to sell/transfer their priority numbers, which are strictly non-transferable.

What are the Fundamental Obligations of Registry Operators in relation to Registrars?

In the ICANN ecosystem, the relationship between a Registry Operator (the entity managing the TLD, like .com or .app) and Registrars (the companies that sell domains to the public, like GoDaddy or Namecheap) is strictly governed by the Base Registry Agreement (Base RA).

The "Fundamental Obligations" are designed to ensure a competitive, fair, and stable domain name market.

1. Non-Discriminatory Access

This is the "Golden Rule" of the registry-registrar relationship. A Registry Operator must treat all ICANN-accredited registrars equally.

• Equal Treatment: You cannot offer a lower wholesale price or better technical support to one registrar while charging others more.
• Uniform Terms: All registrars must sign the same Registry-Registrar Agreement (RRA).
• Fair Promotion: If you offer a "sale" or marketing incentive, it must be available to every accredited registrar who wishes to participate.

2. The Registry-Registrar Agreement (RRA)

A Registry cannot simply make up its own rules on the fly.

• ICANN Approval: Any RRA must be consistent with the Base RA. If a Registry wants to make "substantive" changes to its RRA, it must submit those changes to ICANN for a review period (and often a public comment period).
• Transparency: The RRA must clearly outline the technical requirements, payment terms, and compliance standards the registrar must meet.

3. Technical Interoperability (The Shared Registration System)

Registries are obligated to provide a stable Shared Registration System (SRS) that registrars use to register and manage domains.

• EPP Standard: Registries must support the Extensible Provisioning Protocol (EPP), the industry-standard "language" used for domain transactions.
• Performance Specifications: The Registry must meet strict "Service Level Agreements" (SLAs). For example, the SRS must be available 99.4% to 99.9% of the time to ensure registrars can always process orders.

4. Data Handling and WHOIS/RDAP

Registries must maintain an accurate database of all registered domains and provide access to that data.

• Registration Data Directory Services (RDDS): Registries must provide a publicly queryable database (via WHOIS or the newer RDAP protocol) so that registrars and the public can verify domain ownership and status.
• Data Escrow: Registries must regularly "back up" their registration data with a third-party escrow provider. This ensures that if the Registry fails, the registrars (and their customers) don't lose their domains.

5. Vertical Integration Safeguards

If a company owns both a Registry and a Registrar (known as Vertical Integration), there are strict "Code of Conduct" obligations:

• Anti-Abuse: The Registry cannot use its "insider" data to give its own registrar an unfair advantage (e.g., seeing which domains are being searched for and registering them first).
• Separation of Systems: The Registry must maintain clear boundaries to ensure that its wholesale operations don't unfairly subsidize its retail arm.

ICANN new gTLDs: What are the Clarifying Questions?

In the ICANN New gTLD Program, Clarifying Questions (CQs) are formal requests for more information sent by ICANN’s evaluation panels to applicants.

Receiving a CQ does not mean your application has failed. Instead, it means the evaluators found your initial answers insufficient to award a passing score and are giving you a specific opportunity to fix the gaps.

Why You Might Receive a CQ

During the Initial Evaluation (IE) phase, different expert panels review your application. A CQ is triggered if a panel—such as Financial, Technical, or Geographic Names—determines that:

• An answer is incomplete or unclear.
• The provided financial data doesn't align with the proposed scale of the registry.
• Technical documentation lacks specific details on DNS stability or security.
• The applicant's entity structure requires further legal proof.

ICANN new gTLDs: What is the Prioritization Draw?

In the context of ICANN’s New gTLD Program, the Prioritization Draw is a randomized process used to assign a "priority number" to every application. This number determines the order in which applications are processed through initial evaluation, pre-delegation testing, and eventually, the execution of registry agreements.

Because ICANN receives a massive volume of applications in a short window, it cannot process all of them simultaneously. The draw ensures that the queue is formed in a fair, transparent, and neutral manner.

How the Draw Works

The process was first introduced in the 2012 round and has been refined for the upcoming 2026 Round. Here is the typical breakdown of the event:

• The "Lottery" Format: It is a manual, live event. In past rounds, physical paper tickets representing each application were placed in a drum and drawn by hand to ensure the process could not be "gamed" by digital timestamps.
• Optional Participation: Applicants generally have the choice to participate by purchasing a ticket (historically around $100). Applications with tickets are drawn first; those without tickets are assigned priority numbers afterward.
• Categorization: To promote linguistic diversity, Internationalized Domain Names (IDNs)—which use non-Latin scripts like Arabic, Chinese, or Cyrillic—are typically prioritized and drawn in the first group.

How do I learn if someone plans to submit the same new gTLD application as me in April 2026?

Finding out if someone is gunning for the same digital real estate as you is a bit of a waiting game, thanks to ICANN’s "silent period" during the application window.

Because applications are confidential until the window closes, you won’t know for certain who your competitors are until "Reveal Day."

1. The Official Timeline

The application window opens on April 30, 2026, and is expected to stay open for 12–15 weeks. During this time, ICANN does not publish a live list of applicants.

 * Reveal Day (Estimated October 2026): Once the window closes and ICANN completes its initial administrative checks, they will publish the full list of all applied-for strings and the names of the applicants.

 * Contention Sets: If your string matches or is "confusingly similar" to another, you will be placed in a Contention Set. ICANN will notify you formally at this stage.

2. Strategic "Intel" Before Reveal Day

While you can't see the official list early, you can look for breadcrumbs:

 * Trademark Clearinghouse (TMCH): Check if others have registered the string as a trademark. While not a guarantee they’ll apply for a gTLD, it’s a strong indicator.

 * Industry Rumors: In the 2012 round, many "dot brand" applicants and major portfolio registries (like Identity Digital or Google) were vocal about their interests in trade publications.

 * The "Replacement String" Strategy: New for 2026, ICANN allows you to submit a "Replacement String" in your application. If your primary choice ends up in a contention set, you may have the option to pivot to your backup to avoid a costly auction or dispute.

3. Key Rule Change: No Private Auctions

In previous rounds, competitors often settled "contention" privately (sometimes for millions). For 2026, private resolutions and private auctions are prohibited. If you and another party apply for the same name and neither withdraws, you will likely head to an official ICANN Auction of Last Resort, where the highest bidder wins and the proceeds go to ICANN (not the losing party).

Should I own a registered trademark to submit a dotBrand new gTLD application to the ICANN in 2026?

📝 Registered Trademark Requirement for dotBrand

Yes, based on the requirements from the previous round and the current planning for the next round (expected to open in April 2026), a registered trademark is a mandatory requirement for a dotBrand (\text{.brand}) new gTLD application.

Here are the key points:

- String Match: The domain extension (the "string") you apply for must be identical to a registered trademark that your organization (the Registry Operator) owns.

- Trademark Clearinghouse (TMCH): You must provide proof of this registered trademark, typically by having the mark recorded with the Trademark Clearinghouse (TMCH). This process helps verify the legitimacy of the brand name you are applying for.

- Restricted Use: The dotBrand gTLD is a restricted namespace, meaning only the Registry Operator, its affiliates, or trademark licensees are permitted to register second-level domain names (like website.yourbrand). This restriction is tied directly to the trademark ownership.

- Non-Generic: The applied-for string cannot be considered a "Generic String" (a standard dictionary word or common term).

In summary, for a dotBrand application, having a valid, registered trademark that matches the TLD string and registering it with the TMCH is a fundamental part of establishing your eligibility and right to the name.

🗓️ Important Dates for the Next ICANN Round (2026)

ICANN has provided a projected timeline for the next round of the New gTLD Program:

- Applicant Guidebook (AGB) Publication: The final AGB, which contains all the definitive rules and requirements, is expected to be published around December 2025.

- Application Window Opens: The application submission period is projected to open in April 2026 and last for approximately 12–15 weeks.

I recommend closely monitoring ICANN's official "New gTLD Program: Next Round" website for the final release of the Applicant Guidebook in late 2025, as this document will contain the definitive, non-negotiable rules for the 2026 application window.

Which strings cannot be submitted as new gTLD applications in the 2026 ICANN round?

In the upcoming 2026 ICANN New gTLD round, not all strings are eligible for application. ICANN enforces strict technical, public interest, and "confusing similarity" rules to protect the stability and security of the Domain Name System (DNS).

The following categories of strings cannot be submitted or will be blocked during the application process:

1. Technical & Formatting Prohibitions

Strings must meet specific syntax requirements to ensure they work across all internet software.

Too Short or Too Long: Strings must be between 3 and 63 characters long. Single-character (e.g., .a) and two-character (e.g., .ab) ASCII strings are prohibited.

Invalid Characters: Strings cannot contain digits (0–9), dashes (-), or special symbols. They must consist only of alphabetic characters (a–z) or valid Internationalized Domain Name (IDN) scripts.

Leading/Trailing Dashes: While dashes are generally banned in the TLD itself, they are also prohibited at the start or end of any internal label components.

2. Reserved & Blocked Names

ICANN maintains a Blocked Names List that prevents the registration of strings with high global sensitivity or technical risk.

Country and Territory Names: High-level names of countries and territories (e.g., .america, .france, .china) are generally reserved or require specific government support.

Intergovernmental Organizations (IGOs): Strings that mimic the names of major international bodies (e.g., .olympic, .redcross, .un) are often protected.

Internal Technical Strings: Strings used for internal networking that could cause "name collision" are banned. This includes:

.local, .home, .corp, .lan, .onion

3. "Confusingly Similar" Strings

To prevent user confusion, ICANN will reject applications for strings that are visually or functionally too close to existing or other applied-for TLDs.

Existing TLDs: You cannot apply for a string that is a visual "look-alike" to an existing one (e.g., if .apple exists, a string that looks identical in another script might be blocked).

Plural vs. Singular: A major change for the 2026 round is the strict handling of singular and plural versions of the same word (e.g., if .sport exists, .sports may be deemed confusingly similar and blocked).

Variant Strings: For IDNs (non-Latin scripts), "variants" that are visually identical to the primary string are treated as part of the same application and cannot be applied for separately.

4. Policy-Based Prohibitions

Closed Generics: In the 2026 round, ICANN has determined that "Closed Generics" (generic terms like .book or .shoe that a single company wants to use exclusively for itself without opening registrations to others) are prohibited.

Brand TLD Constraints: For "dotBrand" applications, the string must exactly match a trademarked label in the Trademark Clearinghouse. You cannot apply for a brand string that does not have a matching Signed Mark Data (SMD) file.

How many new gTLD applications will be submitted to the ICANN in April 2026?

The official application window for ICANN’s New gTLD Program: Next Round is scheduled to open on April 30, 2026.

Because this is the very first day of a 12–15 week submission period, the exact number of applications that will be submitted specifically within the month of April 2026 is unknown, but it is likely to be a small fraction of the total. Most organizations will use the full window to finalize their technical and financial documentation.

Estimated Total Applications

While ICANN does not have a "fixed" number of applications, industry experts and ICANN's own planning documents suggest the following projections for the entire round:

Projected Range: Between 500 and 3,500 applications.

Specific Industry Plans: Some players have already announced major moves; for example, Nova Registry has publicly stated intentions to apply for at least 200 new gTLDs.

Historical Context: In the previous round (2012), ICANN received 1,930 applications. Experts anticipate this round could be similar or slightly larger due to the rise of ".brand" domains and Internationalized Domain Names (IDNs) in non-Latin scripts.

Key Factors Influencing the Number

High Entry Cost: The application fee is set at $227,000 per gTLD. This significant investment naturally limits the pool to established corporations, well-funded startups, and government entities.

Process Complexity: The 2026 round features an expanded Applicant Guidebook (AGB) with over 200 questions, requiring extensive technical, financial, and legal preparation.

Brand Strategy: Many global brands that sat out in 2012 are expected to participate this time to secure their own digital namespaces (e.g., .brand).

Important Dates for 2026:

• Application Window: Opens April 30, 2026
• Submission Period: Duration 12 to 15 weeks
• Projected Window Close: July – August 2026
• Initial Evaluation Results Expected 2027

Note: ICANN has mandated that the final Applicant Guidebook be available at least four months before the window opens. It was officially adopted in late 2025 to ensure the April 30, 2026, launch date remains on track.

Brand and Trademark Protections in the new gTLD program: what should an applicant know?

Brand and trademark protection for applicants in the new gTLD program involves both proactively protecting your own brand by applying for a brand TLD, and reactively defending your trademarks against third-party gTLD applications.

Applicants should know about the following mechanisms and strategic considerations:

🛡️ Proactive Protection: The Brand TLD (.brand)

Applying for a Brand TLD (a "dotBrand," e.g., .google, .nike) is the highest level of digital control and protection for a trademark owner.

1. The .Brand TLD Designation

Closed Registry: The primary characteristic is that the registry is restricted. Only the brand owner and its affiliates or licensees are permitted to register second-level domains (e.g., shop.nike). Third-party registrations are prohibited.

Enhanced Security: This provides unprecedented control, allowing the brand owner to implement high-level security protocols (like DNSSEC) across all domains, significantly reducing phishing and counterfeiting risks.

Eligibility: The applied-for string must typically be identical to a registered trademark owned by the Registry Operator.

2. Specification 13

This is a critical addendum to the Base Registry Agreement that grants special exemptions for Brand TLDs.

Exemptions: It provides relief from certain obligations designed for open registries, such as the mandatory requirement to publish contact information for registrants.

Sunrise Deferral: It defers the mandatory Sunrise period (priority registration for trademark holders) for as long as the TLD remains a closed, qualified Brand TLD. This avoids a public launch process.

⚔️ Defensive Protection: Rights Protection Mechanisms (RPMs)

If you are not applying for your own TLD, you must be prepared to defend your trademarks against other gTLD applications using these tools:

1. Legal Rights Objection (LRO)

This is a pre-delegation dispute resolution procedure to formally challenge a third-party gTLD application.

Grounds: An objection may be filed if the applied-for gTLD string, or the applicant’s potential use of it, would cause impermissible infringement of the objector's existing trademark.

Procedure: LROs are resolved by an independent panel of experts, primarily administered by the WIPO Arbitration and Mediation Center.

2. Trademark Clearinghouse (TMCH)

The TMCH is the central, global database of verified trademark information and is foundational for protection.

Sunrise Services: All new gTLD registries must offer a Sunrise Period (at least 30 days) where verified trademark holders from the TMCH can register corresponding domain names before public access.

Trademark Claims Service: For at least 90 days after general public registration opens, the registry must use the TMCH to provide notice to both the new domain registrant (warning of the conflict) and the trademark holder (if the registration proceeds).

3. Uniform Rapid Suspension System (URS)

This is a post-delegation dispute mechanism for clear-cut cases of trademark infringement (cybersquatting) in a newly delegated TLD.

Process: URS is a faster and less expensive alternative to the Uniform Domain Name Dispute Resolution Policy (UDRP).

Remedy: The only remedy is the temporary suspension of the infringing domain name, making it suitable for quick relief in obvious cases of abuse.