In my 17 December post, I walked through whether you should still apply for a new gTLD in the 2026 round, given the opportunities and risks in the final Applicant Guidebook. Today, I want to focus on one of the most consequential infrastructure and operational decisions you’ll make before you ever click “submit” on your application: choosing your Registry Service Provider (RSP).
Unlike 2012, when applicants could theoretically build and defend their own technical infrastructure, ICANN’s 2026 round requires all applicants to use an RSP that has passed the Registry Service Provider Evaluation Program. That means your back-end partner is no longer optional, and picking the wrong one can quietly sabotage everything from your technical evaluation to your long-term operational viability.
ICANN’s RSP List Is Coming (But It’s Not Here Yet)
ICANN originally planned to publish the list of successfully evaluated RSPs last month. Due to technical issues, that date has been pushed to 30 January 2026.
Once published, the list will appear on ICANN’s RSP Evaluation Program page and will be continuously updated as more RSPs complete evaluation. A second RSP evaluation window will open in April 2026, coinciding with the gTLD application period, allowing additional providers to still enter the program.
What that means for you: if you’re planning to apply in the 2026 round, you have roughly three months from the publication of the RSP list until the application window opens to evaluate providers, have substantive conversations, and lock in your back-end partner. That timeline is tight, especially if your string has specific policy, compliance, or go-to-market requirements that not every RSP can or will support.
Why RSP Selection Is Not Just “Picking From a List”
The RSP Evaluation Program was designed to streamline technical assessment by pre-vetting back-end operators against ICANN’s technical, security, and operational requirements. An RSP that passes evaluation can support as many gTLD applications as it wants without being re-evaluated each time.
That’s good news for applicants. It lowers cost and complexity on the technical side. But it also creates a false sense of security. Just because an RSP is on ICANN’s approved list does not mean they are the right fit for your registry business.
The RSP evaluation you need to do goes far beyond ICANN’s technical checklist. Experienced industry advisors look at factors like:
- Policy and governance alignment with your intended registry model
- Operational track record in abuse handling and compliance
- Registrar connectivity and commercial support capabilities
- Organizational fit and the level of access you’ll get as a client
- Long-term financial structure and hidden cost exposure
These aren’t yes/no questions. They require comparative analysis, reference checking with existing clients, and honest assessment of whether your registry model and the RSP’s platform and culture are genuinely aligned, not just “close enough.”
What to Do Right Now
If you’re serious about the 2026 round, here’s what I suggest you start doing before the 30 January RSP list drops:
Build your evaluation framework now. Don’t wait for the list to figure out what criteria matter most to your string and business model. Map out what you’re actually evaluating against: policy flexibility, abuse capabilities, registrar relationships, pricing transparency, and cultural fit.
Identify likely first-tier candidates. Based on industry track record, current gTLD portfolios, and known participation in the RSP evaluation window, you can make educated guesses about which operators will be on ICANN’s list. Start building intelligence on their strengths, weaknesses, and fit for your use case.
Pressure-test your technical and policy assumptions. If your TLD has unusual eligibility rules, compliance requirements, or go-to-market mechanics, validate now whether your chosen RSP’s existing platform and operational setup can actually support your model, or whether you’re asking them to build custom functionality they’ve never deployed before. Custom work doesn’t just cost more. It introduces timeline risk, testing risk, and long-term support complexity that can derail your registry years after launch.
Engage experienced advisors early. People who have worked with multiple RSPs across different rounds and registry models can help you surface blind spots and ask the right questions, questions you may not even know to ask yet. That kind of guidance is far more valuable than generic marketing decks.
The RSP you choose will shape everything from your application’s technical evaluation to your day-to-day operations, your relationship with registrars, and your ability to respond to abuse complaints and compliance audits. It’s not a vendor transaction. It’s a foundational strategic partnership that you’ll live with for years.
Once ICANN publishes the official list on 30 January, the clock starts ticking. The applicants who will make the smartest RSP choices are the ones who have already done the hard work of defining what they actually need, rather than scrambling to pick a name that “looks good” or “had a nice booth at a conference.”
If you’re looking at the upcoming RSP list and thinking, “I’m not sure how to evaluate these providers or what questions I should even be asking,” that’s exactly the signal to bring in someone who does. Better to invest in that clarity now than to lock yourself into a multi-year relationship with a back-end partner that can’t actually support what your registry needs to succeed.