ICANN’ın 2026 gTLD Turu: 4 Aralık 2025’te Bilinenler
ICANN Yönetim Kurulu, 30 Ekim 2025’te 2026 yeni gTLD turunun Başvuru Kılavuzu’nu (Applicant Guidebook, AGB) kabul etti; karar 3 Kasım’da duyuruldu. Bu yazı, 4 Aralık 2025 itibarıyla kabul edilmiş çerçeveyi ve alan adı sahipleri için sonuçlarını ele alıyor. O tarihte başvuru penceresinin Nisan 2026’da açılması hedefleniyordu; değerlendirmelerin tamamlanması ve yeni uzantıların kullanıma açılması ise ayrı aşamalardı.
Karar, mevcut bir uzantıda alan adı kaydetmekten farklı olarak yeni bir üst seviye uzantıyı işletmek isteyen kurumları ilgilendiriyor. Kılavuzun, uyuşmazlık çözüm sağlayıcılarının kuralları eklenerek en geç 30 Aralık 2025’te yayımlanması istenmişti. Temel registry işletmecisi sözleşmesinin (Base Registry Agreement) tamamlanması gibi işler hâlâ sürüyordu. Dolayısıyla kabul edilmiş ilkeleri, nihai sözleşmeyi ve ilerideki uygulama tarihlerini birbirinden ayırmak gerekiyor.
Markalar ve küçük işletmeler açısından pratik soru, her yeni uzantıyı satın almak değil; hangi gelişmeleri izlemek ve mevcut portföyde hangi eksikleri gidermek gerektiğidir. Aşağıda başvuru değerlendirmesini, kapalı jenerik ve .marka kurallarını, hak koruma yollarını ve teknik sorumlulukları ayırıyoruz. DNS abuse yükümlülüklerinin bir bölümü 5 Nisan 2024’ten beri geçerliydi; bunları 2026 turuyla yeni getirilmiş kurallar gibi sunmuyoruz.
gTLD Nedir, Yeni gTLD Turları Nasıl Çalışır?
gTLD, DNS kökündeki genel üst seviye alan adı kategorisidir. .com, .net ve .org yanında .shop, .blog ve .istanbul da bu gruptadır; bir uzantının coğrafi anlam taşıması onu kendiliğinden ülke kodu uzantısı yapmaz. .tr gibi ccTLD’ler ayrı kategoridir. Ayrıca “genel” ifadesi herkesin kayıt yapabileceği anlamına gelmez: marka ve topluluk uzantılarının kayıt uygunluğu kısıtlı olabilir.
gTLD ile ccTLD Arasındaki Farkın Stratejiye Etkisi
ccTLD’lerin kayıt ve yönetim kuralları uzantıya göre değişir; bazıları yerleşiklik şartı koyabilir. gTLD’ler ICANN çerçevesindeki kurallara tabidir; bu, uygulanabilir ulusal mevzuattan muaf oldukları anlamına gelmez. Alan adı stratejisi kurarken “ccTLD mi gTLD mi?” sorusu, global hedef, hukuki risk ve SEO tarafını birlikte düşünmeyi gerektirir. Bu konuyu daha temelden ele aldığımız alan adı stratejisi nasıl kurulur rehberimize mutlaka göz atmanızı öneririz.
2012 Turundan 2026 Başvuru Kılavuzuna
ICANN’ın 30 Ekim 2025 kararına göre 2012 turu internetin ad alanına 1.200’den fazla yeni gTLD ekledi. Sonraki tur, Subsequent Procedures (SubPro) politika çalışması ve ilgili diğer süreçlerin çıktıları üzerine kuruldu. Kabul edilen kılavuzda önceki turdan ayrılan somut başlıklar arasında şunlar bulunuyor:
- Teknik işletim yeterliliğinin, uzantı başvurusundan ayrı Registry Service Provider (RSP) programında değerlendirilmesi.
- Başvuru çakışmalarında özel anlaşmaların yasaklanması ve uygun koşullarda alternatif uzantı seçeneği.
- Beklenmedik uygulama sorunlarının ele alınması için bir öngörülebilirlik çerçevesi.
- Başvuru desteği, uluslararasılaştırılmış alan adları ve farklı başvuru türleri için tanımlanmış süreçler.
Bu değişiklikler, her başvurunun aynı sürede sonuçlanacağı veya belirli bir uzantının mutlaka açılacağı anlamına gelmez. Başvurunun niteliği, itirazlar ve çakışmalar sonucu etkileyebilir. Planı, “daha güvenli uzantılar geliyor” gibi genel beklentilere değil; yayımlanmış aşamalara, uygunluk koşullarına ve kurumun üstleneceği sorumluluklara bağlamak daha yararlıdır.
ICANN’ın Yeni gTLD Politikalarında Öne Çıkan Başlıklar
Aşağıdaki politika özeti, Kurulun 30 Ekim 2025’te kabul ettiği kılavuz sürümüne dayanır. Başvuru yapacak kurumlar, başvuru anındaki yürürlükteki sürümü ve sözleşmeyi ayrıca kontrol etmelidir. Bu tarih ayrımı, sonradan yayımlanan uygulama ayrıntılarının geçmişte biliniyormuş gibi anlatılmasını önler. Ulusal hukuk ve veri koruma yükümlülükleri de ICANN program koşullarından ayrı değerlendirilir.
1. Başvuru Süreci ve Değerlendirme Kriterleri
Bir uzantı başvurusu, bir domain alışverişi değildir. Başvuru sahibinin uygunluğu, geçmiş incelemesi ve finansal/operasyonel hazırlığı değerlendirilir; teknik hizmetler ise başarıyla değerlendirilmiş RSP’lerle sağlanmalıdır. Planlama dosyasında şu ayrımları açıkça yapın:
- Başvuru sahibi: Tüzel kişilik, yönetim, finansman ve işletim planını belgeleyin.
- Teknik sağlayıcı: RSP programından geçmiş hizmetleri belirleyin; sağlayıcı başvuru sahibiyle aynı kuruluş olabilir veya dışarıdan seçilebilir.
- Başvuru türü: .marka, topluluk ve coğrafi isim incelemelerinin koşullarını ayrı değerlendirin.
- Bütçe: Kabul edilen temel başvuru ücreti 227.000 ABD dolarıydı; koşullu değerlendirme ücretleri ve uzun dönem işletim giderleri bu tutara eklenebilir.
Hukuk, finans ve teknik ekipler aynı kapsam üzerinde çalışmalıdır. Başvuru ücreti; RSP hizmetini, marka incelemesini, olası uyuşmazlığı, personeli ve yıllara yayılan işletimi tek başına karşılamaz. Aynı şekilde bir hosting veya VPS planı satın almak, RSP değerlendirmesini geçmek demek değildir. Anycast gibi mimari tercihleri, her başvuru sahibi için bağımsız ve yeni bir genel zorunluluk gibi sıralamak yerine ilgili hizmetin değerlendirme ölçütlerine bakın.
2. DNS Kötüye Kullanımına (Abuse) Karşı Sözleşmesel Yükümlülükler
5 Nisan 2024’te yürürlüğe giren DNS abuse sözleşme değişiklikleri yalnızca yeni gTLD turuna özgü değildir. Kapsam; malware, botnet, phishing, pharming ve bu faaliyetleri iletmekte kullanılan spam’i içerir. Registry ve registrar yükümlülükleri birbirinden ayrılmalıdır:
- Kanıta dayalı müdahale: Eyleme elverişli kanıt bulunduğunda makul azaltıcı önlemler alınmalıdır; tek başına şikâyet, ihlalin kanıtı değildir.
- Farklı roller: Registrar kötüye kullanımı durdurmaya veya aksatmaya yönelik önlem alır; registry’nin rolü duruma göre ilgili registrar’a yönlendirmeyi veya doğrudan müdahaleyi içerebilir.
- Orantılılık: Askıya alma her olay için otomatik çözüm değildir. Ele geçirilmiş bir sitede meşru hizmetlerin de kesilmesi gibi yan etkiler değerlendirilmelidir.
DNS abuse süreci ile DNSSEC farklı kontrollerdir. DNSSEC, imzalı DNS verisinin doğrulanmasına yardımcı olur; bir sitenin içeriğinin güvenli olduğunu veya alan adının marka sahibine ait olduğunu kanıtlamaz. Site güncellemeleri, hesap güvenliği ve olay müdahalesi ayrıca gerekir. Temel ayrımlar için DNSSEC ve alan adı güvenliği rehberini kullanabilirsiniz.
3. Başvuru Yayınlama, İtirazlar ve Çakışma Çözümü
Kılavuz, başvuruların kamuya açık bölümlerinin duyurulmasını, yorumları ve tanımlı itiraz yollarını düzenler. Bunlar aynı işlem değildir: kamuya yorum göndermek, belirli bir itiraz türünde başvuru ehliyetine sahip olmak veya itirazı kazanmak anlamına gelmez. Başvuru izleme planında şu kanalları ayırın:
- Kamuya açık bilgiler: Duyurulan başvuru sahibi, istenen uzantı ve yayımlanabilir başvuru bölümlerini izleyin.
- Resmî itirazlar: Dizge karışıklığı, hukuki haklar, sınırlı kamu yararı ve topluluk itirazlarının ayrı koşulları vardır.
- Diğer girdiler: GAC erken uyarısı ve GAC uzlaşma tavsiyesi, sıradan yorumdan ve bağımsız uyuşmazlık sürecinden farklıdır.
Aynı veya çakışan dizgeler için bir contention set oluşabilir. Kabul edilen çerçeve, özel açık artırmalar dahil başvuru çakışmalarının özel anlaşmayla çözülmesini yasaklar; başvuru sonrasında ortak girişimle çözüm de bu kapsamdadır. Kılavuzdaki alternatif dizge, topluluk öncelik değerlendirmesi ve ICANN açık artırması yollarını inceleyin. Açık artırmaların “artık daha az olacağı” yönünde sonuç garantisi çıkarılamaz.
4. Marka Hakları ve Hak Sahibi Mekanizmaları
Marka korumasında başvuru aşamasındaki hukuki hak itirazı ile tescil edilmiş ikinci seviye alan adlarına yönelik yolları ayırın. Trademark Clearinghouse, Sunrise ve Trademark Claims süreçlerinde rol oynar; URS ve UDRP ise kendi koşulları olan uyuşmazlık mekanizmalarıdır. Kılavuzun kabul edilmesi, hepsinin otomatik olarak sadeleştiğini veya her şikâyeti daha hızlı çözeceğini göstermez. Risk değerlendirmesinde örneğin:
- Markanın yazım hatalı varyasyonlarını kullanan kötü niyetli alan adı kayıtları (typosquatting),
- Phishing amacıyla açılan, markayı taklit eden alan adları,
- Marka değerini zedeleyebilecek içerikler
gibi riskler değerlendirilmelidir. Ancak her olumsuz içerik bir marka hakkı ihlali değildir; bu mekanizmalar her olayı hızla durdurma garantisi vermez. Uygun başvuru yolu, olayın niteliğine ve ilgili mekanizmanın şartlarına bağlıdır. Marka koruma tarafını daha operasyonel gözle ele aldığımız defansif domain satın alma stratejileri rehberimiz bu bölümle birebir bağlantılı.
Markalar İçin: Yeni gTLD Kuralları Stratejinizi Nasıl Değiştiriyor?
“Biz zaten .com ve .com.tr ile gayet iyiyiz, yeni gTLD politikaları bizi neden ilgilendirsin?” diye düşünebilirsiniz. Cevap basit: Bu değişiklikler, sadece yeni bir gTLD’ye başvurmayı değil; rakiplerinizin, distribütörlerinizin ve hatta kötü niyetli kişilerin alabileceği alan adlarını da etkiliyor.
.marka ile Kapalı Jenerik Başvurular Arasındaki Ayrım
Bir marka, kendi adına özel bir uzantıya (.marka) başvurmayı şu kullanım amaçlarıyla değerlendirebilir:
- Ürün ve destek hizmetlerini tutarlı bir adlandırma altında toplamak.
- Varsayımsal bir .adiniz uzantısında kampanya.adiniz gibi ikinci seviye adresler kullanmak; bunun mevcut domain altında alt alan açmaktan farklı olduğunu görmek.
- Bayi portallarını işletmenin kendi kontrolünde sunmak; bayinin bağımsız kayıt sahibi olabilmesini ayrıca .marka uygunluk kurallarına göre değerlendirmek.
Kabul edilen kılavuz, kapalı jenerik (exclusive-use generic) başvuruların, kamu yararını değerlendirecek onaylı yöntem ve ölçütler oluşturulana kadar onaylanmayacağını belirtir. Başvuru sahibinin böyle bir dizgeye başvurmadığını ve onu bu biçimde işletmeyeceğini beyan etmesi gerekir; bu tur için planı bir kapalı jenerik modele dayandırmayın. .marka ayrı bir uygunluk incelemesidir. İlgili tanımda dizgenin uygun tescilli markayla eşleşmesi ve diğer koşullar aranır. Specification 13 kapsamındaki kayıt sahipleri ve DNS kontrolü; işletmeci, bağlı kuruluşları veya tanımlı marka lisans sahipleriyle sınırlıdır. Bir bayilik ilişkisi tek başına bu uygunluğu sağlamaz.
Defansif Kayıt Stratejisi Yeniden Gündemde
Yeni gTLD’leri tamamen görmezden gelmek, marka koruma planında boşluk bırakabilir. Olası senaryolar şunlardır:
- Markanın farklı yazımları yeni gTLD’lerde başkaları tarafından kaydedilebilir.
- Eleştiri veya şikâyet siteleri beklenmedik uzantılarda açılabilir; bunların varlığı tek başına kötüye kullanım anlamına gelmez.
- Phishing amaçlı sahte ödeme sayfaları, alışılmadık ama ikna edici gTLD’ler altında yayına girebilir.
“Savunma amaçlı erken kayıt” bazı kritik alan adlarında pratik olabilir; ancak kayıt ve yenileme maliyetleri nedeniyle her durumda en ucuz seçenek değildir. Markanız için kritik olabilecek uzantıları, hedef kitlenizin kullandığı uzantıları ve sektörünüzle doğrudan ilişkili gTLD’leri risk ve bütçeye göre önceliklendirerek defansif kayıt planı oluşturabilirsiniz. Bu noktada, toplam portföyü sağlıklı yönetmek için alan adı portföy yönetimi rehberimizde anlattığımız takip, etiketleme ve yenileme politikalarından faydalanabilirsiniz.
Mevcut Alan Adı Stratejinizi Gözden Geçirmek İçin Fırsat
Yeni bir uzantı başvurusu yapmasanız da mevcut domain portföyünüzü gözden geçirebilirsiniz. Bu bir zorunlu ICANN geçişi değildir; pazarlama ve operasyon ekiplerinin aynı envanteri kullanmasını sağlayan bir yönetim çalışmasıdır. Başlangıçta şu soruları yanıtlayın:
- Markanın kısa adı, ürün adları ve önemli yazım varyasyonlarından hangileri sizde?
- Hangi ülkelere hizmet veriyorsunuz; ilgili uzantıların kayıt koşulları ve hedef kitlenin tercihleri neler?
- Yeni bir uzantının somut kullanım amacı var mı; yoksa yalnızca tekrar eden kayıt ve yenileme maliyeti mi ekliyor?
Yanıtları, sahiplik ve yenileme sorumluları belirlenmiş bir 3–5 yıllık domain planına dönüştürebilirsiniz. Bu süre bir ICANN takvimi değil, kurum içi bütçeleme örneğidir. Yeni gTLD seçimi kendi başına arama sıralaması veya kullanıcı güveni kazandırmaz; içerik, site yapısı ve tutarlı marka iletişimi ayrıca önem taşır. ICANN’ın yeni alan adı politikalarının marka ve domain stratejisine etkilerini yazısı, daha geniş portföy tartışmasını tamamlar.
Teknik ve Operasyonel Taraf: Yeni gTLD’ler İçin Altyapı Gereklilikleri
Teknik sorumluluğu iki düzeyde değerlendirin: uzantıyı işleten registry/RSP katmanı ve o uzantıda tek bir domain kullanan işletme. Birincisinin sözleşmesel hizmet yükümlülükleri, ikincisinin web sunucusu ayarlarıyla aynı değildir. 2026 turuna başvuracak kurum, değerlendirilmiş RSP hizmetleri ve kendi operasyon sorumlulukları arasındaki sınırı belgelemelidir.
DNS, DNSSEC ve RSP Hizmetleri
RSP programı 19 Kasım 2024’te açılmıştı. Teknik yeterlilik, uzantı başvurusundan ayrı ele alınır; başarılı değerlendirme bir sağlayıcının birden fazla uzantıya hizmet vermesinde yeniden kullanılabilir. Başvuru sahibi açısından şu noktalar önemlidir:
- Hizmet kapsamı: Seçilen RSP’nin gereken DNS, DNSSEC ve kayıt verisi hizmetleri için değerlendirilmiş olduğundan emin olun.
- Sorumluluklar: İzleme, olay bildirimi, anahtar yönetimi ve hizmet sürekliliği görevlerini sağlayıcıyla belgeleyin.
- Ayrı domain bölgesi: TLD’nin imzalı olması, sizin ikinci seviye DNS bölgenizi kendiliğinden imzalamaz; DNSSEC kurulumu ve parent DS ilişkisi ayrıca yönetilir.
Gündelik domain yönetiminde DNS kayıtları A’dan Z’ye rehberimiz, A/AAAA, MX ve TXT gibi kayıtların rolünü anlamak için bir başlangıçtır. Registry işletimi ise bundan daha geniş bir hizmet ve sözleşme kapsamına sahiptir. Standart DNS veya sunucu hizmetinin RSP yeterliliği sağladığını varsaymayın; değerlendirme durumunu ve hangi hizmetleri kapsadığını başvuru hazırlığında doğrulayın.
RDAP ve Kayıt Verisinin Korunması
RDAP, alan adı kayıt verisine erişimde kullanılan protokoldür; hangi verinin kamuya gösterileceği veya yetkili taleplere açıklanacağı ise ayrı politika ve hukuki kurallara bağlıdır. Bunu yalnızca 2026 turuyla gelen yeni bir gizlilik rejimi gibi anlatmak doğru olmaz. Registry işletimi planlanırken şu sorumluluklar açıklığa kavuşturulmalıdır:
- Hangi kayıt verisinin hangi amaçla toplandığı ve saklandığı.
- Kamuya açık yanıtlarda hangi alanların yayımlandığı veya gizlendiği.
- Kamuya açık olmayan veri taleplerinin kim tarafından, hangi usulle değerlendirildiği.
Bu başlıklar için uygulanabilir ICANN sözleşmesi ve Registration Data Policy ile KVKK/GDPR gibi ilgili mevzuat birlikte değerlendirilir. RDAP kullanmak tek başına hukuki uyum sağlamaz; daha fazla log toplamak da otomatik olarak daha iyi uyum demek değildir. KVKK ve GDPR uyumlu hosting rehberimiz, hosting katmanındaki veri işleme ve süreç tasarımı için ek okuma sunar.
Veri Escrow, Yedekleme ve Felaket Kurtarma Planları
Registry data escrow, kayıt verisinin tanımlı biçimde bir escrow kuruluşuna yatırılmasını öngören süreklilik mekanizmasıdır. Amaç, gerektiğinde uzantının işletiminin devam ettirilmesini veya devrini desteklemektir. Bu işlem sitelerin dosya ve veritabanı yedeği değildir; işletmeci iflas ettiğinde bütün hizmetlerin kesintisiz süreceği garantisini de vermez. 4 Aralık 2025’te yeni tur temel sözleşmesinin tamamlanması hâlâ bekleniyordu.
Bu da şu soruları beraberinde getiriyor:
- Registry verisi için ilgili escrow kapsamı, biçimi, takvimi ve doğrulama sorumlusu kim olacak?
- Escrow dışında uygulama, yapılandırma ve anahtarların ayrı yedekleme ihtiyacı nasıl karşılanacak?
- Hangi arıza için hangi RTO/RPO hedefleri belirlenecek ve geri yükleme nasıl denenecek?
3‑2‑1 yedekleme rehberimiz, bağımsız kopya tutma ve geri yüklemeyi planlama açısından yararlıdır. Ancak bu genel yaklaşım registry escrow yükümlülüğünün yerine geçmez. TLD işletimi tasarlanıyorsa veri tesliminin doğrulanması, sağlayıcı değişimi ve yetki devri de ayrıca ele alınmalıdır; yalnızca bir yedek dosyasının varlığı iş sürekliliğini kanıtlamaz.
Türkiye ve Bölgesel Pazar İçin Olası Etkiler
2026 programı gTLD başvurularını kapsar; .tr kayıt kurallarını bu kararla değiştirmez. Türkiye’deki işletmeler için etkiler, seçilecek uzantılara ve gerçek kullanım ihtiyacına bağlıdır. Aşağıdaki başlıklar birer planlama olasılığıdır, açılacağı kesinleşmiş yeni uzantılar listesi değildir:
- Sektör ve şehir adları: Bir proje gündeme gelirse dizge uygunluğu, coğrafi ad incelemesi ve varsa gerekli kamu otoritesi desteği araştırılmalıdır.
- İhracatçı işletmeler: Mevcut .com ve ccTLD portföyünün yanında yeni bir uzantının hedef kitleye katkısı ve toplam maliyeti değerlendirilmelidir.
- Ajanslar: Müşteri adına yapılan kayıtların sahipliği, yenileme yetkisi ve devir süreci açık tutulmalıdır.
Önce mevcut portföyü görünür hale getirmek, sonra yeni seçenekleri değerlendirmek bütçeyi daha anlaşılır kılar. Kullanılmayan görünen bir domaini bırakmadan önce eski e-posta, hesap kurtarma, bağlantı ve yönlendirme bağımlılıklarını araştırın. ICANN alan adı politikalarındaki değişiklikler ve yol haritası yazısı bu operasyonel bakışı tamamlar; farklı politikaların kapsam ve yürürlük tarihlerini ayrı izlemek gerekir.
Uygulanabilir Bir Alan Adı Yol Haritası
Küçük bir işletme ile kendi uzantısına başvuracak kurumun ihtiyacı aynı değildir. Aşağıdaki üç adım, kapsamı büyütmeden kararları düzenlemek için kullanılabilir. Bunlar ICANN’ın zorunlu tuttuğu bir danışmanlık süreci değil; portföy yönetimi için önerilen çalışma başlıklarıdır.
1. Stratejik Seviye: Marka, SEO ve Hukuk
Önce hedef ülkeleri, ürünleri, marka haklarını ve bütçeyi belgeleyin. Bir .marka başvurusunda tüzel kişilik, uygun marka ve kullanım modeli ayrıca incelenmelidir. Mevcut domainlerle devam edecek işletme ise daha küçük bir kayıt planına ihtiyaç duyabilir. Şu kararları yazılı hale getirin:
- İş için gerekli gTLD ve ccTLD kayıtları ile bunların kullanım amacını belirleyin.
- Defansif kayıt için risk ve bütçe sınırını tanımlayın.
- .marka veya başka bir gTLD başvurusu için ayrı fizibilite gerekip gerekmediğine karar verin.
Bu kararları, yenileme maliyetlerini ve izleme sorumlusunu belirleyerek tamamlayın. Hiçbir küçük domain seti markayı bütün olası taklitlerden korumaz. Savunma kayıtları, izleme ve uygun hukuki/teknik müdahale yollarıyla birlikte düşünülmelidir; her olumsuz içerik veya benzer ad otomatik hak ihlali sayılmaz.
2. Operasyonel Seviye: Portföy ve Yenileme Yönetimi
Dağınık kayıtlar, politika değişikliğinden bağımsız olarak yenileme ve erişim riski yaratır. Domain sahibi, registrar, DNS sağlayıcısı, ödeme yöntemi ve kurtarma kişileri tek envanterde görülebilmelidir. Kritik alan adlarının süresini ve uyarıların gerçekten ilgili kişiye ulaştığını kontrol edin.
Domain, hosting ve VPS gibi sunucu hizmetleri ayrı sağlayıcılarda bulunabilir. Tek panel varsayımına dayanmak yerine her hizmetin sahibi ve yönetim hesabını belirleyin. Envanter şu kontrolleri birbirine bağlamalıdır:
- Yenileme hatırlatmalarını,
- DNS ve nameserver bütünlüğü kontrollerini,
- SSL ve e‑posta altyapısıyla uyumlu çalışmayı
Kontrollerin sorumlusunu ve son doğrulama tarihini kaydedin. Bir domain başka altyapıya taşınırken DNS, sertifika ve posta geçişlerini birlikte planlayın; domain yenilemesi ile sunucu yenilemesini aynı olay sanmayın. Böylece yeni bir uzantı eklemek de tanımlı bir operasyon sürecine dönüşür.
3. Teknik Seviye: DNS, Güvenlik ve Altyapı
Mevcut sitelerde de hesap güvenliği, güncellemeler ve DNS değişiklik kontrolü değerlidir; fakat bunlar registry düzeyi uygunluğun kanıtı değildir. Hizmet seçerken pazarlama ifadesinden çok, ihtiyaç duyulan özelliğin ilgili planda gerçekten bulunmasına ve nasıl yönetildiğine bakın:
- DNS yönetiminde yetki ayrımı, değişiklik kaydı ve desteklenen DNSSEC süreci.
- Hedef kullanıcılar için ölçülmüş ağ erişimi; kullanılan IPv4 ve IPv6 yollarının ayrı doğrulanması.
- Sertifika yenileme, uygulama güvenliği ve gerekiyorsa WAF/DDoS hizmetinin açık kapsamı.
Bu kontrollerin her biri belirli bir sorunu çözer; hepsini tek bir “gTLD uyumlu hosting” etiketi altında toplamak yanıltıcıdır. Kendi uzantısına başvuran kurum RSP ve registry yükümlülüklerini ayrıca karşılamalı, sıradan bir domain sahibi ise kullandığı web ve e-posta hizmetlerinin çalışmasını doğrulamalıdır.
Sonuç: Kabul Edilen Kuralları Somut Kararlara Dönüştürün
4 Aralık 2025 açısından temel gelişme, 2026 turu kılavuzunun Kurul tarafından kabul edilmiş olmasıydı. RSP değerlendirmesi, kapalı jenerik başvuruların dışlanması ve özel çakışma çözümünün yasaklanması somut kurallardı. Başvuru penceresi hedefi ile bir uzantının değerlendirilip köke eklenmesi ve kayıt açması aynı tarih değildi.
Çoğu işletmenin ilk işi yeni bir TLD başvurusu yapmak değil; mevcut domainlerini, yenileme sorumlularını ve marka izleme ihtiyacını netleştirmektir. .marka düşünen kurumlar ise uygunluk, maliyet, RSP seçimi ve yıllara yayılan yönetişim için ayrı fizibilite hazırlamalıdır. Yeni uzantı; daha iyi SEO, kesintisizlik veya phishing’den korunma garantisi sağlamaz.
Başlamak için tek bir envanter hazırlayın, kritik domainleri işaretleyin ve izlenecek ICANN duyurularına sorumlu atayın. Hosting veya sunucu ihtiyacını değerlendirirken gerekli DNS, posta, sertifika ve yedekleme kapsamını sağlayıcıyla doğrulayın. Hukuki başvuru uygunluğu ve marka uyuşmazlıkları için uzman değerlendirmesi alın; teknik hizmet satın almayı bu değerlendirmeyle karıştırmayın.
