Alan Adı Transferi Nasıl Yapılır? Kod ve Transfer Kilidi

Alan adı transferi, adın bir kayıt şirketinden diğerine taşınmasıdır; üç koşula bağlıdır: ad kilitli olmamalı, eski kayıt şirketinden alınan yetkilendirme kodu doğru girilmeli ve ICANN politikasındaki altmış günlük sınırlar engel oluşturmamalıdır. Kayıt şirketinizi fiyat, destek ya da panel nedeniyle değiştirmek isteyen bir site veya atölye sahibiyseniz, taşımayı yeni şirketin panelinde başlatır, eski şirketten kodu ve kilit durumunu alırsınız. Kayıt şirketlerinin arayüzleri farklı olduğundan burada ekran adımları değil, hangi bilginin kimde olduğu ve hangi sırayla ilerleneceği anlatılır. Ülke uzantılarının kendi transfer kuralları bu konunun dışındadır.

Taşımadan önce hazırlanacaklar

Transferi başlatmak tek tıklama gibi görünse de gerçek iş, başlamadan önceki hazırlıktır. ICANN'in Registrants' Benefits and Responsibilities (yeni sekmede açılır) sayfası, kayıt şirketinden alan adını taşıma, yenileme ve geri yükleme yönergelerine erişme hakkınızı yazar; yani ilk adım, eski kayıt şirketinizin transfer sayfasını okumaktır. Ardından tablodaki kalemleri tek tek hazırlayın. Tablo: Transfer öncesi hazırlık kalemleri.

Uygulama önerisi: transferi hafta sonu ya da yoğun satış gününe değil, siz erişilebilir olduğunuzda başlatın. Onay e-postasının gelmediği bir hafta sonu, süreci gereksiz yere uzatır.

Hangi kayıt şirketinden hangisine

Eski şirket mevcut ad sunucularınızı ve kayıt listenizi tuttuğu için transfere başlamadan o şirketten çıkış prosedürünü ayrıca sorun. Yeni şirketin transfer fiyatını ve transferin süre sonuna ne kattığını yazılı öğrenin; politikaya göre başarılı bir transfer, kayıt süresine bir yıllık uzatma getirir, ama toplam süre on yılı aşamaz.

Hazırlık sırası

1. Eski kayıt şirketi hesabına girişi doğrulayın.
2. Süre sonu tarihini ve altmış gün kurallarının tarihlerini yazın.
3. DNS kayıt listesini dışa aktarın.
4. Yeni kayıt şirketinde hesap açın ve transfer ücretini öğrenin.
5. Kilidi kaldırın, kodu alın ve transferi aynı gün başlatın.

Yetkilendirme kodu ne işe yarar ve nasıl alınır

Yetkilendirme kodu, adın sahibi olduğunuzu yeni kayıt şirketine kanıtlayan paroladır. Kayıt sistemlerinde kullanılan RFC 5731 (yeni sekmede açılır) bu bilgiyi authInfo olarak adlandırır. Belgeye göre yetkilendirme bilgisi alan adı oluşturulurken atanır ve sonradan güncellenebilir; bilgi yalnızca adın bağlı olduğu kayıt şirketine ya da geçerli yetkilendirme bilgisini sunan bir tarafa döndürülür. Yani kodu e-postada paylaşmak, adın kontrolünü paylaşmak demektir.

ICANN Transfer Policy (yeni sekmede açılır) sayfasına göre kayıt şirketi, alan adı sahibine kendi kodunu üretme ve transfer kilidini kaldırma imkanı sunmuyorsa, ilk talepten itibaren beş takvim günü içinde kodu vermek ve kilidi kaldırmak zorundadır. Aynı sayfada kayıt şirketinin ödeme anlaşmazlığı gerekçesiyle kod vermeyi reddedemeyeceği yazılıdır. Panelde "Auth code", "EPP code" ya da "Transfer key" gibi adlarla görünebilir; arayüzü Türkçe kullanıyorsanız etiket adları farklı görünebilir.

Kodun doğru kullanımı

1. Kodu yalnızca yeni kayıt şirketinin transfer formuna girin.
2. Kodu başka bir kanalda saklamayın ve işlem bitince panelde yeniden oluşturulabiliyorsa yenileyin.
3. Kod yanlışsa yeniden istemek, süreci başlatmış bir transferi iptal etmeden önce yapılacak ilk iştir.
4. Kodun geçerlilik süresi kayıt şirketine bağlıdır; belgelerde bu konuda ifade yok.

Kod gelmediğinde yazışma

Kod beş takvim günü içinde gelmezse kayıt şirketine kısa ve tarihli bir yazı gönderin. Yazıda alan adı, hesap adı, ilk talep tarihi ve istenen iki şey bulunsun: yetkilendirme kodu ile transfer kilidinin kaldırılması. ICANN Transfer Policy sayfasındaki beş takvim günü kuralına atıf yapabilirsiniz; ancak bu kuralın kayıt şirketinin kendi panelinde kodu üretme imkanı sunmadığı durumda geçerli olduğunu belirtmeyi unutmayın. Yanıt gelmezse yazışmayı kaydedip kayıt şirketinin sözleşmesinde yazan itiraz yolunu kullanın; ICANN sayfası, kayıt şirketine kaygıları nasıl ileteceğinizi öğrenme hakkınızı yazar.

Transfer kilidi: ne zaman açılır, ne zaman kapanır

RFC 5731, clientTransferProhibited durumu varken adın transfer isteklerinin reddedilmesi gerektiğini yazar. Yani kilit açıkken taşıma başlatılamaz. ICANN politikasının I.A.5.1 maddesine göre kayıt şirketi bu durumu yalnızca kayıt sırasında ya da sonraki bir talep üzerine uygulayabilir ve kayıt sözleşmesi, kayıt sahibinin açık rızasıyla bu yasağın şartlarını içermelidir. Aynı sayfada, kayıt sahibinin transferden önce kilidi açma konusunda makul bir fırsatı olmadığı sürece, kilidin transferi reddetme gerekçesi olarak kullanılamayacağı yazılıdır.

Pratikte bu, kilidi kaldırmanın sizin elinizde olması gerektiği anlamına gelir. Panelde kilit ayarını bulamıyorsanız destek ekibinden isteyin ve talebin tarihini kaydedin; beş takvim günü süresi talep tarihinden başlar. Kilit açıldıktan sonra yeni kayıt şirketinde transfer isteğini başlatın. Transfer bittiğinde yeni şirkette kilidin yeniden açık olup olmadığını panelden doğrulayın.

Kilitsiz kalma süresini kısa tutun

Uygulama önerisi: kilidi, transferi başlatmadan hemen önce kaldırın ve işlem tamamlanınca kilidi yeniden açın. Kilit açıkken adın istenmeyen bir transfer riskine açık olduğunu unutmayın; bu yüzden kodu üretme, kilidi açma ve transferi başlatma işlerini aynı gün içinde sürdürmek, açık kalma süresini kısaltır.

Altmış günlük kurallar

ICANN politikasında altmış günlük üç ayrı sınır vardır. Politika, kayıt şirketinin alan adının oluşturulmasından sonraki altmış gün içinde istenen transferi ve önceki bir transferden sonraki altmış gün içinde istenen transferi reddedebileceğini yazar. Üçüncü sınır farklıdır: kayıt sahibi değişikliğinden sonra uygulanan altmış günlük kilit. Tablo: Üç sınır ve ne zaman devreye girdiği.

Kayıt sahibini transferden önce mi sonra mı değiştirmeli

Politika, kayıt sahibi değişikliğinde hem önceki hem yeni kayıt sahibinden güvenli yolla onay alınmasını, ikisine de bildirim gönderilmesini ve onaylardan sonra bir gün içinde işlem yapılmasını yazar. Kayıt şirketi kilitten vazgeçme seçeneği tanıyabilir, ama bu tercih değişiklik talebinden önce yapılmalıdır. Politika, önceki kayıt sahibine değişiklikten önce kayıt şirketleri arası transfer talep etmesini önerir; böylece kilit tetiklenmez. Sıra pratikte şöyle kurulur: önce transferi tamamlayın, sonra yeni kayıt şirketinde kayıt sahibi bilgisini güncelleyin. Hem taşımak hem kayıt sahibini değiştirmek istiyorsanız bu sıra işi kolaylaştırır; yine de kayıt şirketlerinin işleyişi farklı olabilir, önceden sorun.

Transferin reddedilme nedenleri

ICANN politikasının I.A.3.7 maddesi, kayıt şirketinin transferi hangi gerekçelerle reddedebileceğini sayar. Madde listesi kapalıdır; yani sayılanlar dışında bir gerekçe politika kapsamında geçerli sayılmaz.

• Sahtecilik kanıtı.
• Kayıt sahibinin ya da yönetim kişisinin kimliği konusunda makul bir uyuşmazlık.
• Önceki kayıt dönemi için ödeme yapılmaması (ayrıntılı istisnalarıyla).
• Yetkili transfer kişisinin açık itirazı.
• Alan adının oluşturulmasından sonraki altmış gün içinde talep edilmesi.
• Önceki bir transferden sonraki altmış gün içinde talep edilmesi.

Ayrıca devam eden UDRP ya da URS işlemleri, mahkeme kararları, TDRP uyuşmazlıkları ve kayıt sahibi değişikliği sonrası altmış günlük kilit için reddetme zorunlu tutulur. Politika, kayıt şirketinin transfer süreçlerini hizmet bedelini tahsil etmek için bir baskı aracı olarak kullanmamasını da yazar; ilgisiz ödeme anlaşmazlıkları nedeniyle transfer engellenemez.

Reddedildiğinde ne yapılır

Reddi bildiren mesajdaki gerekçeyi gerekçe listesiyle eşleştirin. Gerekçe listede yoksa kayıt şirketine politikanın hangi maddesine dayandığını sorun. Gerekçe geçerliyse (örneğin altmış gün kuralı) yapılacak şey beklemektir. Sorun ödeme ise faturayı kapatıp transferi yeniden başlatmak gerekebilir; ayrıntı kayıt şirketine göre değişir.

Reddi gerekçeye göre okumak

Tablo: Ret gerekçesi ve sizin hamleniz.

Transfer sürecinin zaman çizelgesi

ICANN politikası sürecin ana zamanlama kurallarını verir. Tablo: Politikadaki süreler ve ilgili taraf.

Politika, onay formunun İngilizce iletilmesini şart koşar; kayıt şirketleri başka dillerde de gönderebilir ve çevirinin doğruluğundan sorumludur. Yani e-posta İngilizce gelirse yadırgamayın. Sayfa güncellenmiş bir sürümün de yayımlandığını belirtir (21 Şubat 2024 tarihli); uygulamadan önce güncel metne bakın.

Bekleme sırasında yapılacaklar

Transfer isteği gönderildikten sonra beş günlük pencere boyunca hesap bilgilerinizi değiştirmeyin, ad sunucularını elleme ve aynı anda başka bir değişiklik başlatmayın. Onay e-postasını bekleyin; gelmediyse spam klasörüne bakın, ardından kayıt şirketine yazın.

Onay e-postası gelmezse

Onay e-postası kayıtlı iletişim adresine gider. Gelmediyse sırayla şunlara bakın: spam klasörü, kayıt şirketinde kayıtlı adresin güncel olup olmadığı ve alan adı filtreleri. Adres değiştirilecekse bunun kayıt sahibi değişikliği sayılıp sayılmayacağını kayıt şirketinden sorun; politika, e-posta adresinde esaslı değişikliği kayıt sahibi değişikliği kapsamında sayar. Bu nedenle onay adresini transfer sürecinin ortasında değiştirmek altmış günlük kilidi tetikleyebilir.

Maliyet ve süre hesabı

Transferin maliyetini yalnızca ilk fiyata bakarak değerlendirmeyin. ICANN politikasının I.A.15 maddesine göre kayıt sahibi tarafından yetkilendirilen ve tamamlanan bir transfer, mevcut kayda bir yıllık uzatma getirir; ancak kalan süre dahil toplam kayıt süresi on yılı aşamaz. RFC 5731 transfer isteğine isteğe bağlı bir dönem öğesi eklenebildiğini ve bu sürenin transfer tamamlanınca kayıt süresine ekleneceğini yazar. Sunucu birim sayısını sınırlayabilir. Yeni kayıt şirketinin transfer ücretinin bu uzatmayı kapsayıp kapsamadığı belgelerde yazmaz; her kayıt şirketinin fiyat sayfasına bakın.

Tablo: Transfer maliyetini hesaplarken sorulacaklar.

Hesap yaparken

Uygulama önerisi: iki şirketin üç yıllık toplam maliyetini aynı tabloya yazın; transfer ücretini, yıllık yenileme ücretini ve ek hizmetleri ekleyin. Taşımanın tasarrufu bu tabloda görünmüyorsa, taşımak için panelden panele geçme çabasına değmeyebilir.

Terimler sözlüğü

Aynı kavram farklı belgelerde farklı adlarla geçer. Tablo: Transfer terimleri ve karşılıkları.

Transfer takılırsa B planı

Transfer reddedilir ya da günlerce beklerse alan adınızın mevcut kayıt şirketinde çalışmaya devam ettiğini unutmayın. Süre sonu yaklaşıyorsa, yenilemenin bekleyen transferi nasıl etkileyeceğini mevcut kayıt şirketinden yazılı sorun ve süre sonunu ihmal etmeyin. Ardından red gerekçesini giderin ve transferi yeniden başlatın. Uygulama önerisi: transfer başlatmadan önce süre sonuna en az bir ay kalmasını bekleyin; böylece beklenmedik gecikme sizi yenileme baskısına sokmaz.

Transfer sırasında DNS ve e-postanın korunması

RFC 5731, bir alan adı nesnesinin transferinin ona bağlı alt ana bilgisayar nesnelerini de örtük olarak transfer ettiğini yazar. Belge, alan adı için tanımlı ad sunucusu referanslarının transferde nasıl ele alındığını belirtmez. Bu nedenle ad sunucularının transferden sonra ne olacağını eski ve yeni kayıt şirketinden yazılı öğrenin. Uygulama önerisi: transferden önce kayıt listesini dışa aktarın, transfer sonrasında A, MX ve TXT kayıtlarını bu dosyayla karşılaştırın.

Google'ın Site moves without URL changes (yeni sekmede açılır) sayfası, DNS ayarlarının TTL değerine göre önbelleğe alındığını ve değişiklikten en az bir hafta önce TTL'nin birkaç saate çekilmesini önerdiğini yazar. Ad sunucusu değiştirilecekse bu öneriyi uygulayın. Hosting de değişecekse işi ayrı bir plan olarak ele alın; hosting değiştirirken DNS geçişi ve TTL yazısındaki sıra transfer günü yaşanacak karışıklığı azaltır. Google belgelerindeki öneriler değişebilir; uygulamadan önce güncel sayfaya bakın.

Ad sunucusu aynı mı kalıyor, değişiyor mu

İki durumun yönetimi farklıdır. Tablo: Ad sunucusu kararı ve yapılacaklar.

Tek değişiklik kuralı

Uygulama önerisi: kayıt şirketi transferi, hosting değişikliği ve e-posta sağlayıcı değişikliğini aynı güne koymayın. Sorun çıktığında hangi değişikliğin nedeni olduğunu ayırmak zorlaşır. Önce transferi tamamlayın, birkaç gün gözleyin, sonra diğer değişikliklere geçin.

Search Console ve sahiplik doğrulaması

Alan adı mülkünüz DNS kaydıyla doğrulandıysa, transfer sonrası kaydın yeni yerde de aynen durduğunu teyit edin. Mülk türleri arasındaki farkı Search Console mülk türü yazısında bulabilirsiniz. Kayıt silinirse doğrulama bozulabilir; bu nedenle ad sunucusu değişiyorsa TXT ve CNAME doğrulama kayıtlarını yeni yere eklemeyi unutmayın.

Transferden sonra Search Console'a girip mülkün hâlâ doğrulanmış göründüğünü kontrol edin. Doğrulama bozulmuşsa kaybolan kaydı yeniden ekleyin. Doğrulama kayıtlarını, transferden önce aldığınız DNS dışa aktarım dosyasıyla karşılaştırmak hangi satırın eksik kaldığını hemen gösterir. Aynı kontrolü bir hafta sonra bir kez daha yapın; önbellekteki eski yanıtlar ilk günlerde tabloyu yanıltmış olabilir. Eksik kaydı bulunca neden eksik kaldığını da nota yazın, böylece bir sonraki taşımada aynı satır unutulmaz.

Karar kuralı: taşımalı mı, kalmalı mı

Her sorun transferle çözülmez. Tablo: Neden ve önerilen hamle.

Örnek senaryo: bir mum atölyesi

Örnek senaryo: Elde mum döken bir atölye, sitesini bir tasarımcının önerdiği kayıt şirketinden almıştı. Yenileme fiyatı arttığı için başka bir kayıt şirketine taşımak istiyor; sipariş yoğunluğunun arttığı haftalardan önce işi bitirmek ve ad sunucusu değişikliğiyle sezonun ortasında uğraşmamak istiyor. Atölye sahibi önce kayıt şirketi paneline girip adın kilitli olduğunu görüyor. Kodun nerede olduğunu bulamayınca destek ekibine yazıyor ve talebin tarihini not ediyor.

Sıra şöyle ilerler. Atölye sahibi DNS kayıtlarını dışa aktarır, dosyayı ayrı bir klasöre kaydeder ve süre sonu tarihine bakar. Süre sonu iki aydan uzak olduğu için transferi hemen başlatır. Kilidi açar, kodu alır ve yeni kayıt şirketinde transfer isteğini oluşturur. Onay e-postasını bekler, spam klasörünü kontrol eder. Transfer bitince site, sipariş formu ve e-postayı tek tek dener; DNS kayıtlarını dışa aktardığı dosyayla karşılaştırır ve kilidi yeniden açar.

Aynı atölye ikinci bir durumla da karşılaşabilir. Transfer isteğinden sonra mevcut kayıt şirketi, adın yakın zamanda kayıt sahibi bilgisi değiştiği için altmış günlük kilitte olduğunu bildirir. Atölye sahibi bu kez beklemeyi seçer, bekleme süresince adı kendi hesabında tutar ve takvime kilidin biteceği tarihi yazar. Kilit bitince transfer yeniden başlatılır. Beklemenin maliyeti yoktur, ama atölye süre sonuna yakınsa yenilemeyi ayrıca halletmek zorundadır.

Senaryodan çıkan ders

Hazırlık hızlı yapılırsa transfer birkaç günlük sıradan bir işlemdir. Süreci uzatan şey bu örnekte teknik bir engel değil, kodun nerede olduğunun bilinmemesi ve onay e-postasının okunmamasıdır. Bu yüzden atölye sahibi transfer tarihini, kodu aldığı günü ve onay e-postasının geldiği adresi tek satırlık bir nota yazıyor. Bir şey ters giderse destek ekibine "şu tarihte şu adımı attım" diyebilmek, aynı soruların baştan sorulmasını engeller. Bu not, ileride alan adını devralacak kişi için de ilk başvuru kaynağı olur.

Güvenlik: kod ve hesabın korunması

Transfer süresince hesabınız normalden daha fazla risk altındadır, çünkü kilit açıktır ve kod üretilmiştir. Uygulama önerisi olarak şu önlemleri alın.

• Kayıt şirketi hesabında iki aşamalı doğrulamayı açın.
• Hesap e-postasının parolasını da güçlü ve benzersiz tutun; çünkü onay mesajları oraya gelir.
• Kodu parola yöneticisi gibi güvenli bir yerde saklayın, işlem biter bitmez geçersiz kılın veya yenileyin.
• Ekran görüntüsü paylaşırken kodun, ödeme bilgisinin ve oturum bilgilerinin görünmediğinden emin olun.
• Transfer isteği siz başlatmadan geldiyse onaylamayın ve yazışmayı hemen kayıt şirketine iletin.

Başkasının başlattığı transfer

Sizin başlatmadığınız bir transfer için onay formu alırsanız onaylamayın. Politikada mevcut kayıt şirketinin beş takvim günü içinde yanıt vermemesi halinde onayın varsayıldığı yazılıdır; bu nedenle bilmediğiniz bir transfer talebini aynı gün kayıt şirketine bildirin ve kilit durumunu kontrol edin.

Çok sayıda alan adı ve ajans hesapları

Birden fazla alan adı taşıyorsanız ya da müşterinizin alan adlarını yönetiyorsanız, süreç kalabalıklaşır. Her ad için ayrı kod, ayrı kilit durumu ve ayrı bir süre sonu tarihi vardır. Uygulama önerisi: tek bir tabloda alan adı, mevcut kayıt şirketi, kilit durumu, kodun alındığı tarih, transfer talebinin tarihi ve sonucu tutun.

Müşteri adına taşırken

Alan adı müşterinin adınaysa kod ve onay e-postası da müşterinin adresindedir. Yazılı yetkiyi alın, kod isteğini müşterinin yönetmesini sağlayın ve transferden sonra kayıt sahibi bilgisinin müşteri adına olduğunu doğrulayın. Kayıt sahibi değişikliği gerekiyorsa altmış günlük kilidi önceden planlayın.

Taşımadan sonraki ilk hafta

İlk haftada sitenin ve e-postanın düzenli çalıştığını her gün bir kez denemek yeterlidir. Search Console'da bildirimlere, sipariş kutusunda eksik iletilere bakın. Bir sorun belirirse DNS kayıt listesini dışa aktarılan dosyayla karşılaştırmak ilk adımdır.

Transfer sonrası kontrol listesi

• Yeni kayıt şirketi panelinde alan adı etkin ve süre sonu tarihi beklenen şekilde ilerlemiş.
• Transfer kilidi yeniden açık.
• Site ana sayfası, iç sayfalar ve sipariş ya da iletişim formu başka bir ağdan açılıyor.
• E-posta hem alıyor hem gönderiyor.
• DNS kayıtları dışa aktarılan listeyle birebir eşleşiyor.
• Search Console doğrulaması ve diğer TXT kayıtları yerinde.
• Otomatik yenileme açık ve ödeme yöntemi geçerli.
• Kayıt sahibi iletişim e-postası iki kişinin okuduğu bir adres.
• Eski kayıt şirketinde ayrı bir hizmet (örneğin e-posta ya da barındırma) varsa kullanımı sürüyor mu kontrol edildi.
• Belgeleme sayfası yeni kayıt şirketi, süre sonu tarihi ve sorumlu kişiyle güncellendi.

Eski hesabı kapatmadan önce

Eski kayıt şirketinde başka alan adı, e-posta ya da barındırma hizmetiniz varsa hesabı kapatmak sorun yaratabilir. Hesabı kapatmadan önce faturalarınızı, bildirim adreslerinizi ve DNS dışa aktarımlarınızı kaydedin.

Kayıt şirketine yazılı sorular

Telefonda alınan yanıt ileride kanıt olmaz. Uygulama önerisi: şu soruları e-posta ya da destek formuyla sorun ve yanıtları saklayın.

1. Alan adım şu anda kilitli mi, kilidi nasıl kaldırabilirim?
2. Yetkilendirme kodunu kendim üretebiliyor muyum? Üretemiyorsam beş takvim günü içinde verilecek mi?
3. Alan adım son altmış gün içinde oluşturuldu, taşındı ya da kayıt sahibi değişti mi?
4. Ödenmemiş bir fatura ya da dönem var mı?
5. Transfer tamamlanınca ad sunucularım ne olacak?
6. Başarılı transferle kayıt süresine bir yıl eklenecek mi, ücret nedir?

Sık Sorulan Sorular

Alan adı transferi ne kadar sürer?

ICANN politikası mevcut kayıt şirketine beş takvim günü yanıt süresi tanır; yanıt gelmezse onay varsayılır. Gerçek süre kayıt şirketlerine ve uzantıya bağlıdır; güncel politika metnine ve kayıt şirketinizin açıklamasına bakın.

Yetkilendirme kodunu vermemek için ödeme anlaşmazlığı gerekçe olabilir mi?

ICANN politikası, kayıt şirketinin ödeme anlaşmazlığı nedeniyle kodu vermeyi reddetmemesini yazar. Kod gelmezse talebi yazılı yapın ve politikanın ilgili maddesini hatırlatın.

Transfer kilidi ne işe yarar?

RFC 5731'e göre clientTransferProhibited durumu varken transfer istekleri reddedilir. Kilit, istenmeyen taşımayı engeller; taşıma yapmadığınız sürece açık kalması önerilir.

Yeni aldığım alan adını hemen taşıyabilir miyim?

ICANN politikası, alan adının oluşturulmasından sonraki altmış gün içinde talep edilen transferin reddedilebileceğini yazar. Önce bu süreyi bekleyin.

Transfer sırasında siteme ve e-postama ne olur?

RFC 5731 alt ana bilgisayar nesnelerinin alan adıyla birlikte transfer edildiğini yazar ama ad sunucusu referanslarının ele alınışını belirtmez. Kayıt listesini önceden dışa aktarın ve transferden sonra karşılaştırın.

Kayıt sahibini değiştirirsem transfer kilitlenir mi?

ICANN politikasına göre kayıt sahibi değişikliğinden sonra altmış günlük transfer kilidi uygulanır; kayıt şirketi kayıt sahibine kilitten önceden vazgeçme seçeneği tanıyabilir. Detaylar için kayıt şirketinizin yönergesine bakın.

Sonuç

Alan adı transferi üç şeyi sırayla çözmekle ilerler: hazırlık, kod ve kilit, ardından taşıma sonrası doğrulama. Altmış günlük sınırlar, reddedilme nedenleri ve beş günlük süreler ICANN politikasında yazılıdır; panel adımları ise kayıt şirketinden kayıt şirketine değişir. Kayıt listesini dışa aktarmak, onay e-postasını okunan bir adrese bağlamak ve transferi hosting değişikliğinden ayrı yapmak en düşük maliyetli üç önlemdir. Başarısız ya da geciken bir transferde de yapılacak şey aynıdır: gerekçeyi yazılı alın, politikadaki ilgili süreyi not edin ve süre sonu tarihinizi ihmal etmeyin. Kod ve kilit gibi hassas bilgileri paylaşırken ekran görüntüsünü ve ortak belgeleri kullanmayın, işlem biter bitmez kilidin yeniden açık olduğunu doğrulayın ve yeni kayıt şirketinde otomatik yenilemeyi açık tutun. Ülke uzantılarının kuralları farklı olabilir; kendi uzantınızın belgelerini ayrıca okuyun.

Taşıma tamamlandıktan sonra sitenizi içerik ortaklıklarıyla tanıtmak isterseniz tanıtım yazısı hizmetimize göz atabilirsiniz.