gTLD string evaluation is one of the most critical and unforgiving stages in the ICANN New gTLD application process. It sits at the center of a high-stakes, high-reward journey for applicants.
You may have a compelling idea for a new Top-Level Domain, such as something catchy like .ninja or game-changing like .eco. That is a great start. However, getting your own TLD is not as simple as choosing a strong name and submitting an application.
Before any new TLD enters the root, it must survive what we call the Technical Gauntlet. This process tests whether a proposed string is technically sound, compatible with existing DNS rules, and safe to introduce at a global scale. In short, even the best ideas fail if the string breaks DNS rules or triggers ICANN safeguards.
The gTLD string evaluation phase determines whether a proposed string is technically viable, secure, and safe to introduce into the DNS root. You’ve got a brilliant, catchy, and brandable string ready to go. You can already see .yourTLD becoming a secure and trusted corner of the internet. But even the cleverest string will get rejected flat if it breaks DNS rules or triggers one of ICANN’s many safeguards.
Before your TLD ever sees the light of day, it must survive what we call the Technical Gauntlet.
This is not just about having a great idea. Instead, it requires proving that your string will not break the internet, confuse users, or create security risks. The process is a minefield of technical requirements. It also demands strict policy adherence and legally binding commitments.
Just look at the 2012 application round: 1,930 applications were submitted, and believe me, not all of them made it through unscathed.
This guide is your survival manual. We’re here to demystify the entire ICANN gTLD string evaluation 2026 process. We’ll cut through the acronym-heavy jargon to give you a clear, actionable roadmap – covering everything from pre-submission checks and string similarity risks to the legally binding Public Interest Commitments (PICs) you’ll have to make.
Consider this your definitive resource for navigating a complex landscape. Even a minor misstep can derail your application and sink your significant investment. The base application fee alone is expected to be $227,000.
We’ll walk through the key stages every applicant must conquer before their string can be delegated into the DNS root. For a deeper dive into the official rules, it’s essential to know that the draft Applicant Guidebook was released to help applicants prepare for this complex journey.
ICANN designed the evaluation process to ensure a stable and trustworthy expansion of the internet’s namespace. The table below gives a high-level overview of the critical checkpoints every gTLD string must pass before it can be officially delegated into the DNS root.
| Evaluation Stage | Primary Purpose | Common Pitfall to Avoid |
|---|---|---|
| Initial Technical Checks | To filter out strings that are reserved, blocked, or violate fundamental DNS stability rules | Applying for a two-letter string that conflicts with country codes (e.g., .us or .uk) |
| String Similarity Review | To prevent user confusion by rejecting strings that are visually or phonetically similar to existing TLDs | Choosing a string like .paypa1 that is confusingly similar to an established brand TLD like .paypal |
| Commitment Evaluation | To ensure applicants make enforceable promises to protect the public interest and maintain security | Overpromising in Registry Voluntary Commitments (RVCs), creating expensive, long-term legal burdens |
Understanding these stages is the first step toward building a successful application strategy and avoiding costly, time-consuming mistakes down the road.
This is where the rubber meets the road. Even the most clever, brand-perfect string will fail if it violates fundamental DNS rules or trips up ICANN’s technical safeguards. Before your potential TLD can even dream of going live, it has to get through the ICANN gTLD string evaluation – a tough screening process built to protect the stability and security of the entire Domain Name System (DNS).
During gTLD string evaluation, automated systems identify technical risks, reserved names, and potential stability issues before human review begins. This first technical hurdle is mostly automated, acting as the first line of defense against strings that could cause trouble. Think of it as a bouncer at an exclusive club; if your string isn’t on the list and doesn’t meet the basic dress code, it’s not getting in.
This infographic breaks down how an application moves from submission to a final decision.
As you can see, the technical review is the critical checkpoint where a string’s basic viability is decided. It’s a make-or-break phase for every applicant.
First, you’ll face a series of automated checks. As soon as you submit your application, ICANN’s system runs your string against several hard-and-fast rules. These are the easiest ways to get rejected, so clearing this stage is non-negotiable.
These initial checks cover:
.com or .un. This includes two-letter strings that match country codes (like .us or .ca), the names of major Intergovernmental Organizations (think .redcross), and other protected termsDo This: Before you get too emotionally (and financially) invested, check ICANN’s official lists of blocked and reserved names to make sure your idea isn’t dead on arrival.
At this stage, the evaluation becomes more subjective and more complex. In practice, a huge part of the ICANN technical evaluation is the string similarity review. The whole point is to prevent internet users from getting confused. If your proposed string looks, sounds, or even just feels too much like an existing TLD (like .car vs .cars) or another one in the application pool, it’s going to get flagged.
Imagine the chaos if both .amazon and .amazoon existed. It would be a playground for phishing scams. The 2012 application round was a perfect example of how heated this can get. Of the 1,930 applications submitted, a huge number were for similar or overlapping strings, leading to what ICANN calls “contention sets.” You can explore the official application data from the 2012 round to see just how common this was.
Don’t Do This: Don’t pick a string like .paypa1 (with a number one) hoping to ride the coattails of .paypal. The evaluation panel looks at visual, aural, and conceptual similarities, and this kind of move will get you booted.
If you’re applying for an Internationalized Domain Name (IDN) – like .在线 (Chinese for “online”) or .みんな (Japanese for “everyone”) – you’re signing up for another layer of intense scrutiny. IDNs and their variant strings (different characters that look alike across different scripts) are governed by a strict set of Label Generation Rules (LGRs).
Failing to create a solid LGR is a frequent cause of delays and even rejections for IDN applications. It’s all to ensure a character in one script can’t be used to spoof a TLD in another.
Applying for a geographic name like .nyc or .paris? You’d better have your paperwork in order. These strings must be supported by official government documentation. No exceptions.
Finally, there’s the ghost in the machine: name collisions. This happens when a proposed public gTLD (like .corp) is identical to a name that’s already widely used in private, internal computer networks. ICANN assesses this using longitudinal risk datasets. This “leakage” creates major security and stability risks, which is exactly why promising strings like .home and .corp were blocked in the 2012 round.
When you apply for a gTLD, you’re not just submitting a technical proposal. You’re making a series of legally binding promises to ICANN and the entire internet community. This is where policy meets pavement. Getting them wrong is like signing a contract without reading the fine print – a mistake that can come back to haunt your registry for years. Let’s untangle this web of commitments.
Think of Public Interest Commitments (PICs) as the non-negotiable rules of the road for every registry operator. These standard requirements apply across the board to all new gTLDs. They grew out of the lessons learned from the 2012 application round to address concerns from governments and internet users.
Every single applicant has to agree to a standard set of PICs, including:
These commitments create the bedrock of trust. If you’re running .law, for example, you are expected to have robust systems in place to stop it from becoming a hotspot for legal scams.
For certain TLDs in higher-risk sectors, the standard PICs just aren’t enough. In these cases, ICANN imposes Safeguard PICs on registries operating in sensitive industries like finance, health, or government. These are extra, stricter obligations designed to protect vulnerable users. A registry for .bank or .health will face much tougher scrutiny than one for .fun.
This is your chance to make your application stand out, but be careful – it’s a double-edged sword. Registry Voluntary Commitments (RVCs) are promises you propose to show how your TLD will bring a unique benefit. Maybe you volunteer to fund digital literacy programs or enforce specific content policies.
Don’t Do This: Don’t let the word “voluntary” fool you. Once ICANN approves your application, your RVCs become legally binding. They carry the same weight as mandatory PICs. These promises will be picked apart during the Registry Commitments Evaluation (RCE). To nail this, you need to be deeply familiar with the legal considerations when applying for a new top-level domain to avoid creating future problems for yourself.
Finally, if you apply as a community TLD for a string like .eco or .music, your specific Community Registration Policies are evaluated with the same tough standards as RVCs.
So, you’ve made it. Your string sailed through the technical checks, and your commitments are locked in. But now for the real question: will anyone actually be able to use it? Welcome to the critical, and often painfully overlooked, challenge of Universal Acceptance readiness.
At its core, Universal Acceptance means your new gTLD should work seamlessly everywhere online. ICANN requires registry operators to affirm the technical feasibility of their string, and a TLD that isn’t universally accepted is commercially crippled before it even gets off the ground.
The whole point of UA is to build a truly multilingual and expanded internet where every domain name and email address gets treated equally. For you as an applicant, this means your shiny new .luxury or .apparel TLD has to work just as reliably as a classic .com.
The Universal Acceptance Steering Group (UASG) is the go-to resource here, offering a ton of data and tools to help registries and developers test for readiness.
This data shines a light on the persistent gaps in software and systems around the world. The biggest headaches almost always pop up with non-ASCII Internationalized Domain Names (IDNs). This is a huge pitfall. Just imagine launching .世界 (Chinese for “world”) only to find out that 20-30% of web forms reject it. These aren’t just hypotheticals; they’re the real-world roadblocks that stunted the growth of many promising IDNs from the 2012 round.
To get a better handle on the technical and policy challenges unique to these domains, you can learn more about mastering IDNs and their specific requirements.
To avoid launching a TLD that no one can actually use, you have to build UA readiness directly into your application strategy.
Here are the proactive steps every applicant must take:
Navigating the ICANN application process is like walking through a minefield blindfolded. Here are the biggest explosions to watch out for:
.book for your exclusive use. This is a major no-noHistory is our best teacher, and for anyone eyeing the next gTLD application window, the 2012 round was a masterclass in what can go wrong. That first massive wave of nearly 2,000 applications was a global experiment, leaving behind a treasure trove of war stories and cautionary tales. Many applicants in 2012 underestimated how strict gTLD string evaluation would be. As a result, they faced avoidable objections, delays, and rejections.
A staggering 751 applications ended up in contention sets, forced to battle it out for identical or confusingly similar strings. For a closer look, ICANN’s own review of the new gTLD program offers a detailed history.
One of the most dramatic lessons came from the outright rejection of seemingly perfect strings like .home and .corp. Multiple applicants poured fortunes into preparing these intuitive, highly marketable TLDs, only to see them blocked at the eleventh hour. The reason? A catastrophic risk known as name collisions.
Finally, the 2012 round served as a major wake-up call for Universal Acceptance readiness. Many innovative Internationalized Domain Name (IDN) TLDs – those in scripts like Arabic or Chinese – were successfully delegated but then faced a harsh market reality. Adoption was painfully slow because major email providers, social networks, and web applications simply weren’t ready to handle non-ASCII characters.
Winning in the ICANN gTLD string evaluation 2026 is all about meticulous preparation, not luck. This is your guide to getting your application in fighting shape.
Do This: Before you even dream of writing a check for the $227,000 application fee, pre-test your string with experienced Registry Service Providers (RSPs) and DNS engineers. They can run simulations and audits to catch any technical red flags that could get you disqualified right out of the gate.
Do This: Conduct a thorough audit of any potential confusion risks. The string similarity review is one of the most critical hurdles, and ICANN is taking this so seriously that for the next round they’re bringing in expert evaluation providers. You can learn more about how ICANN is evolving its evaluation methodology for the next round.
Don’t Do This: Don’t fall so in love with your string that you become blind to its flaws. An objective, data-driven audit is your best defense against a string confusion objection.
Do This: Draft your PICs and RVCs conservatively. Your mantra here should be: Be specific, be measurable, and be achievable. Avoid binding promises you can’t enforce.
Don’t Do This: Steer clear of vague, aspirational language like “promoting a safer internet.” Every single word will be scrutinized, and once it’s approved, it’s set in stone.
Finally, your budget can’t just stop at the application fee. A big piece of that puzzle must be dedicated to Universal Acceptance (UA) advocacy, marketing and adoption campaigns. A TLD that passes ICANN’s evaluation but fails in the real world is a failed investment.
| Preparation Step | Key Action | Why It Matters |
|---|---|---|
| Technical Validation | Engage an RSP or DNS expert to conduct a full audit of your string for potential technical issues like name collisions | Prevents an early-stage disqualification and saves you from wasting the hefty application fee on a technically flawed string |
| String Similarity Review | Perform a comprehensive, objective audit against existing and likely TLDs, including common misspellings | A proactive audit helps you anticipate and defend against potential string confusion objections, a common reason for application failure |
| Commitment Drafting | Write your PICs and RVCs with specific, measurable, and conservative language. Avoid vague marketing promises | These are legally binding contracts. Overcommitting can create significant legal and financial burdens for your registry down the line |
| Long-Term Budgeting | Allocate funds specifically for Universal Acceptance (UA) initiatives beyond the initial application fee | Ensures your TLD is actually usable across the global internet, which is critical for its long-term viability and return on investment |
Completing these steps doesn’t just tick boxes; it builds a resilient foundation for your application. It shifts your position from being a hopeful applicant to a serious contender.
And if your string clears the technical gauntlet, the journey is far from over. Select gTLD contracting: you won… now the work begins walks through what happens next – from Registry Agreement negotiations to compliance, timelines, and operational readiness before delegation.
Getting through ICANN’s gTLD string evaluation can feel like navigating a maze. To clear things up, here are some straight answers to the questions we hear most often from new applicants.
Hands down, it’s underestimating the string similarity review. It’s easy to get tunnel vision, focusing only on your own TLD and your own vision. But applicants often forget to look outward and analyze how their proposed string could be confused with existing TLDs like .bank or even another string in the same application round. This blind spot is a simple mistake that can lead to expensive objections or even a flat-out rejection.
Yes. 100%. When ICANN gives your application the green light, any Registry Voluntary Commitments you’ve made get baked directly into your official Registry Agreement. They become contractual obligations, legally enforceable by ICANN.
A vague promise tossed in to make your application stand out can easily morph into a costly, decade-long operational nightmare. Treat every single word in your RVCs as if it’s already part of a signed contract.
Yesterday. But since that’s not possible, you should start right now. A successful gTLD application is a marathon, not a sprint, built on months of careful technical, legal, and financial planning. Procrastination is the fastest way to get your application denied.
Success in gTLD string evaluation comes from preparation, conservative commitments, and early technical validation. Ready to get through the technical gauntlet and claim your piece of the internet? The team at TLDz holds a perfect 100% success rate across more than 50 applications. We mix deep industry expertise with our own proprietary tools to guide you from a simple idea to a successful registry launch.
Don’t gamble with your application. Make sure your gTLD is built to win from day one. Chat with the TLDz team to validate your approach.
Subscribe to Our Monthly Newsletter
Join our mailing list to receive exclusive content only our newsletter members have access to.