Kısa cevap: Alan adı transferi, alan adının kaydının tutulduğu şirketi – yani kayıt kuruluşunu – değiştirir. Site ve e-posta, DNS kayıtları doğru kopyalandığı sürece transfer yüzünden hiç durmaz. İşlemin anahtarı mevcut kuruluştan alınan AuthInfo kodudur; buna çoğunlukla EPP kodu deniyor. ICANN politikası bu kodu alan adı başına tekil olmaya ve self-servis bir ekran yoksa talepten itibaren 5 takvim günü içinde verilmeye zorunlu kılar; karşılığında kayıt ya da son transfer üzerinden 60 gün geçmemişse talep reddedilebilir.
Transfer nedir, ne değildir
Bu konuda en sık yapılan karışıklık, hosting taşımak ile alan adı transferini aynı sanmaktır. İkisi birbirinden tamamen bağımsız iki iştir. Hosting taşımak, sitenin hangi sunucudan servis edildiğini değiştirir ve DNS bölgesindeki A kaydına dokunmakla olur. Transfer ise alan adının faturasını kesen, yenilemesini yapan ve kaydını tutan şirketi değiştirir. Siteye hiç dokunmadan transfer yapabilirsiniz; aynı şekilde transfer yapmadan hosting de değiştirebilirsiniz. Sunucu tarafını alan adını başka bir hosting'e taşıma yazısında ele alıyoruz.
Transferin kritik yan etkisi şudur: transfer DNS kayıtlarını taşımak zorunda değildir. Alan adı yeni kuruluşa geçerken o kuruluşun varsayılan isim sunucuları devreye girerse ve o bölge boşsa, site ve e-posta aynı anda durur. Bu yüzden transfer öncesinde mevcut bölgenin tam dökümünü almak ve transfer sonrasında isim sunucularının eski değerde kaldığını doğrulamak gerekir. Kayıt türlerinin ne işe yaradığını DNS kayıt türleri yazısında tek tek anlatıyoruz.
ICANN politikasının koyduğu kurallar
Genel üst düzey alan adlarında transfer, ICANN Transfer Policy ile çerçeveye alınmıştır. Pratikte bilmeniz gereken maddeler şunlar.
- 60 gün, iki ayrı yerde çıkar. Kayıt kuruluşu, talep alan adının kayıt tarihinden itibaren 60 gün içinde yapıldıysa transferi reddedebilir. Aynı şekilde alan adı önceki transferinden itibaren 60 gün içindeyse de reddedebilir.
- AuthInfo kodu alan adı başına tekil olmak zorundadır. Bir kuruluş bütün müşterilerine aynı kodu veremez. Panelinizde kendi kendinize kod üretebileceğiniz bir ekran yoksa, kuruluş kodu talep tarihinden itibaren 5 takvim günü içinde vermek zorundadır.
- Ödeme anlaşmazlığı kodu geciktirmek için gerekçe değildir. Politika, aradaki bir fatura tartışması yüzünden AuthInfo kodunun verilmemesini açıkça kabul etmez. Elinizdeki dayanak budur.
- Sahip bilgisi değişikliği ayrı bir kilit doğurur. Change of Registrant, yani kayıt sahibinin adı, kurumu ya da e-posta adresinin değişmesi, 60 günlük bir transfer kilidi uygulanmasına yol açar. Önceki sahip, değişiklik talebinden ÖNCE bu kilitten feragat edebilir.
- Onay formunun ömrü sınırlıdır. Kazanan kayıt kuruluşunun düşürdüğü FOA, yani Form of Authorization, 60 gün sonra düşer. Yarım bırakılmış bir transfer süresiz beklemez.
- redemptionPeriod durumundaki alan adı transfer edilemez. Süresi bitmiş ve silinme sürecine girmiş bir alan adını önce mevcut kayıt kuruluşunun geri alması gerekir; ancak ondan sonra transfer konuşulabilir. Bu süreci alan adının süresi bitince ne olur yazısında ayrıntılandırıyoruz.
Transferi engelleyen durumlar
Transfer talebi reddedildiğinde panelde çoğu zaman tek satırlık bir hata görürsünüz. Aşağıdaki tablo o satırın arkasında ne olduğunu ve ne yapmanız gerektiğini topluyor.
| Durum | Belirtisi | Çözümü |
|---|---|---|
| Transfer kilidi | Durum satırında clientTransferProhibited yazar | Mevcut kuruluşun panelinden kilidi kaldırın; bu kilit yetkisiz transferi engellemek için vardır |
| Kayıttan 60 gün geçmemiş | Yeni alınmış alan adında talep reddedilir | 60 günün dolmasını bekleyin; kuruluş bu gerekçeyle reddetme hakkına sahiptir |
| Son transferden 60 gün geçmemiş | Kısa süre önce taşınmış alan adında talep reddedilir | Önceki transfer tarihinin üzerinden 60 gün geçmesini bekleyin |
| Sahip bilgisi yeni değişmiş | Ad, kurum ya da e-posta güncellenmesinin ardından kilit görünür | 60 günü bekleyin; önceki sahip değişiklikten önce feragat etmişse kilit uygulanmaz |
| AuthInfo kodu alınamıyor | Panelde kod ekranı yok, destek de yanıt vermiyor | Yazılı talep açın; politika gereği 5 takvim günü içinde verilmesi gerekir |
| İletişim adresine ulaşılamıyor | Onay e-postası gider ama kimse açamaz | Transferden önce kayıt sahibi e-postasını erişilebilir bir adrese güncelleyin |
| Silinme sürecinde | Durum satırında redemptionPeriod yazar | Transfer edilemez; önce mevcut kuruluştan geri alma işlemi yapılır |
| Gizlilik servisi açık | Onay akışı maskelenmiş adrese gider | Gizliliği geçici olarak kaldırın, transfer bittikten sonra geri açın |
Adım adım: transfer akışı
- Mevcut DNS kayıtlarının tam dökümünü alın. Transfer kayıtları taşımaz. Bölgedeki her satırı – A, AAAA, CNAME, MX, TXT, SRV, CAA ve isim sunucuları – yazılı hâle getirin. Bu döküm, transferden sonra bir şey ters giderse elinizdeki tek referanstır.
- Kayıt sahibi iletişim e-postasını güncelleyin. Onay akışı bu adrese gider. Adres eski bir çalışanın kutusuna ya da erişilemeyen bir hesaba bağlıysa transfer orada durur. Ama dikkat: adı, kurumu veya e-postayı değiştirmek Change of Registrant sayılır ve 60 günlük kilit doğurur; bu yüzden güncellemeyi transfere başlamadan belirgin bir süre önce yapın ya da önceki sahibin feragat seçeneğini kullanın.
- WHOIS / RDDS gizliliğini geçici olarak kaldırın. Gizlilik servisi açıkken onay yazışması maskelenmiş bir adrese düşebilir. Transfer tamamlandıktan sonra yeni kuruluşta gizliliği yeniden açabilirsiniz.
- Transfer kilidini kaldırın. Mevcut kuruluşun panelinde alan adının durumuna bakın;
clientTransferProhibitedgörüyorsanız kilit açıktır. Bu kilit yetkisiz transferi engellemek için vardır, iş bittiğinde yeni kuruluşta tekrar açılması önerilir. - AuthInfo / EPP kodunu alın. Panelde böyle bir ekran varsa kodu kendiniz üretin. Yoksa yazılı talep açın; politika gereği 5 takvim günü içinde verilmesi gerekir. Kodu mesajlaşma uygulamasında değil, kendi hesabınızın erişimi olan bir yerde tutun.
- Yeni kuruluşta transfer talebini başlatın. Alan adını ve AuthInfo kodunu girin. Bu adımda genellikle alan adına bir yıl ek süre satın alınır; ücretlendirme kuruluşa göre değişir.
- Onay e-postasını yanıtlayın. Kayıt sahibi adresine düşen onay bağlantısını kullanın. Mevcut kuruluş da size bir bilgilendirme gönderir; bazı panellerde transferi oradan hızlandırıp hemen onaylama imkânı vardır.
- Transfer bittiğinde DNS kayıtlarını doğrulayın. İsim sunucularının eski değerde kaldığını, site ile e-postanın çalıştığını ve bölgedeki her satırın dökümle aynı olduğunu kontrol edin. Eksik satır varsa dökümden girin. Son olarak transfer kilidini tekrar açın ve otomatik yenilemeyi devreye alın.
Alan adının durumunu okumak
Transfere başlamadan önce yapılacak ilk şey, alan adının genel kayıt verisinde (RDDS, eski adıyla WHOIS) durum satırlarına bakmaktır. Aşağıdaki örnekte alan adı ornekfirma.com ve parantez içindeki değerler YER TUTUCUDUR; durum kodlarının kendisi gerçektir.
# transfere KAPALI bir alan adi Domain Name: ORNEKFIRMA.COM Registrar: (mevcut kayit kurulusu) Domain Status: clientTransferProhibited Registrant Email: (gizlilik servisinin maskeli adresi) Name Server: (isim sunucusu 1) Name Server: (isim sunucusu 2) # transfere ACIK bir alan adi Domain Status: ok # silinme surecinde, transfer EDILEMEZ Domain Status: redemptionPeriod
Üç satırın anlamı şudur: clientTransferProhibited kilidi açıktır ve mevcut kuruluşun panelinden kapatılması gerekir. ok engel olmadığını söyler. redemptionPeriod ise transferin konuşulamayacağı, önce geri alma işleminin yapılması gereken durumdur.
.tr ve .com.tr tarafı
Türkiye uzantılı alan adları ICANN politikasının değil, BTK bünyesindeki TRABİS sisteminin kurallarına tabidir. 2022 yılında yönetim nic.tr ve ODTÜ yapısından TRABİS'e devredildi. İşleyiş fikir olarak benzer: transfer kodu mevcut kayıt kuruluşundan alınır, yeni kayıt kuruluşuna verilir, talep TRABİS üzerinden eski kuruluşa iletilir ve onaylanmasıyla alan adı yeni kuruluşa geçer.
Burada kasıtlı olarak bir süre taahhüdü yazmıyoruz: kuruluşların yayınladığı bekleme süreleri birbiriyle çelişiyor. Pratik tavsiye şu: işlemi alan adının bitiş tarihine yakın bir güne bırakmayın ve koda ulaşamıyorsanız mevcut kuruluşla yazışmayı e-posta üzerinden, kayıt kalacak biçimde yürütün.
Yaygın hatalar
- Transferi alan adının son günlerine bırakmak. Süre biterken başlatılan bir transfer, araya yenileme ve silinme süreçleri girdiğinde yarıda kalır. Alan adının bitişine rahat bir pay bırakarak başlayın.
- İletişim e-postasına erişimi olmadan başlamak. Onay yazışması kayıt sahibi adresine gider. Kimsenin açamadığı bir adres, transferi teknik olarak değil ama pratik olarak imkânsız hâle getirir.
- Transferden hemen önce sahip bilgisini değiştirmek. Ad, kurum ya da e-posta güncellemesi Change of Registrant sayılır ve 60 günlük transfer kilidi doğurur. İyi niyetli bir düzeltme, iki ay beklemeye dönüşür.
- Transferin DNS kayıtlarını taşıdığını varsaymak. Taşımaz. Yeni kuruluşun varsayılan isim sunucuları devreye girer ve o bölge boş gelirse site ile e-posta aynı anda durur. Döküm almak bu tek riski ortadan kaldırır.
- AuthInfo kodunu güvensiz bir kanalda paylaşmak. Kod, alan adı üzerinde yetki anlamına gelir. Paylaşılmış bir ekip sohbetine ya da üçüncü bir kişiye bırakılan kod, yetkisiz transfer riski doğurur.
- Transfer bittikten sonra kilidi tekrar açmamak. Kilit kapalı kalan alan adı, hesabı ele geçiren birinin yetkisiz transfer denemesine karşı korumasız kalır. İş bitince kilidi geri açın.
- E-posta tarafını hiç test etmemek. Site açılıyorsa her şeyin yolunda olduğu sanılır; oysa MX ya da SPF satırı eksik kalmış olabilir. Dışarıdan bir deneme iletisi gönderip gelişini doğrulayın; kurulum sırasını kurumsal e-posta kurulumu yazısında anlatıyoruz.
Ne zaman uzmana bırakmalı
Tek bir alan adını yeni bir kuruluşa almak, kodu elinizde olduğunda yarım saatlik iştir. Zorlaşan durumlar şunlar: alan adı eski bir ajansın ya da işten ayrılmış bir çalışanın hesabında duruyorsa, iletişim adresine kimse erişemiyorsa, kayıt sahibi bilgisi kurumla uyuşmuyorsa, aynı alan adı üzerinde site ile birlikte kurumsal e-posta ve ödeme entegrasyonları çalışıyorsa, ya da kuruluş AuthInfo kodunu vermiyorsa.
Bu işi biz web sitesi ve e-ticaret çalışmalarının bir parçası olarak yürütüyoruz: önce alan adının durumunu ve bölgedeki her satırı dökeriz, sonra transferi site ve e-posta kesintiye girmeyecek sırayla tamamlarız. Mevcut yapının genel fotoğrafını isterseniz teknik denetim sayfasına bakabilir ya da iletişim sayfasından yazabilirsiniz.
Devamını okumak için
Kayıt türlerinin tamamı için DNS kayıt türleri, sunucu değiştirmenin sırası için alan adını başka bir hosting'e taşıma, süresi bitmiş bir alan adını kurtarmak için alan adının süresi bitince ne olur, e-posta tarafına geçmek için kurumsal e-posta kurulumu yazısına bakın. Tüm başlıklar blog sayfamızda, çalışma alanlarımız ana sayfamızda.