- Katılım
- 21 May 2023
- Mesajlar
- 496
- Tepki
- 17
- Puan
- 18
Domaini başka bir firmaya taşımak, nameserver değiştirmekten farklı bir işlemdir. Burada alan adının kayıt kuruluşu değişir; EPP ya da AuthInfo adı verilen kod ise bu aktarımın sahibin isteğiyle başlatıldığını doğrulayan önemli parçalardan biridir.
Sorun genellikle kodu bulamamakla bitmiyor. Alan adının kilit durumu, kayıt sahibinin iletişim bilgileri veya yakın tarihte yapılan bir değişiklik yüzünden aktarım daha başlamadan durabiliyor. Kontrol sırasını doğru kurmak, destek talepleri arasında gün kaybetmeyi önler.
Hosting taşımak için domaini mutlaka başka kayıt kuruluşuna aktarmanız gerekmez. Web sitesini yeni sunucuya yönlendirmek çoğu zaman DNS kayıtları veya nameserver değişikliğiyle yapılır. Registrar transferi ise alan adının kayıt ve yenileme yönetimini başka bir ICANN akreditasyonlu firmaya geçirir.
Bu ayrım önemlidir; yanlış anda hem DNS hem registrar hem de kayıt sahibi bilgisini birlikte değiştirirseniz hangi işlemin soruna yol açtığını bulmak zorlaşır. Genel tescil, sahiplik ve yenileme düzeni için forumdaki domain satış ve tescil rehberine bakabilirsiniz.
ICANN belgelerinde kodun resmî adı AuthInfo Code. Piyasada EPP kodu, transfer kodu veya yetkilendirme kodu da deniyor. ICANN’in Auth-Code açıklamasına göre kayıt kuruluşu, kodu panelden üretmenize izin verir ya da talebinizden sonra beş takvim günü içinde sağlar.
Bu kodu parola gibi düşünün. Forum mesajına, ekran görüntüsüne veya herkese açık destek kaydına yazmayın. Yeni kayıt kuruluşunun kendi transfer ekranı dışında paylaşmanız isteniyorsa adresi ve talebi yeniden doğrulayın.
Kod doğru olsa bile alan adı aktarım kilidindeyse istek reddedilebilir. ICANN EPP durumları rehberinde
En fazla karışan nokta burası. Güncel ICANN Transfer Policy, ICANN kapsamındaki genel üst düzey alan adlarında farklı 60 günlük durumlar tanımlar. Bunları aynı olay gibi anlatmak doğru olmaz:
Kayıt sahibi değişikliği kilidinde bazı registrarlar, değişiklik yapılmadan önce vazgeçme seçeneği sunabilir; bunu sunmak her durumda zorunlu değildir. Önce iletişim bilgisini değiştirip sonra aktarım istemek bu yüzden planı geciktirebilir. Nihai hedef registrar değişikliği ise, mevcut firmanın politikasını okuyup işlem sırasını destekten yazılı olarak doğrulamak daha güvenlidir.
Site ve e-posta aynı alan adına bağlıysa DNS kopyası özellikle önemlidir. Taşıma öncesi genel yayın kontrolü için hosting ve domain sorunları rehberi, posta kayıtları için de SPF, DKIM ve DMARC konusu yardımcı olabilir.
“Transfer edilemiyor” mesajı tek başına teşhis değildir. Yeni registrarın verdiği istek numarasını, alan adının o andaki EPP durumlarını ve mevcut registrarın açıkladığı ret sebebini kaydedin. ICANN’in kayıt sahibi SSS sayfası; yeni tescil, kayıt sahibi değişikliği kilidi, dolandırıcılık şüphesi, yetkilendiren kişinin kimliği üzerindeki makul uyuşmazlık ve bazı ödeme/uyuşmazlık durumlarının aktarımı engelleyebileceğini açıklıyor.
Önce şu ayrımı yapın:
Registrar gerekçe vermeden veya politika dışı biçimde süreci engelliyorsa yazışmaları saklayın ve ICANN’in resmî transfer şikâyeti kanalını değerlendirin. Ancak ccTLD uzantılarında yetkili kurum ve uyuşmazlık yolu farklı olabilir.
Yeni panelde kayıt sahibi bilgilerini, nameserverları, otomatik yenilemeyi ve alan adının yeni bitiş tarihini kontrol edin. Web sitesini,
Özetle: Önce registrar transferiyle DNS taşımasını ayırın; sonra sahiplik, EPP durumu ve 60 günlük kilidin hangi olaya bağlı olduğunu doğrulayın. AuthInfo kodunu en son ve yalnız resmî panelde kullanın. Sorun yaşadıysanız kodu paylaşmadan yalnız uzantıyı, durum kodunu ve registrarın verdiği ret sebebini yazmanız teşhisi kolaylaştırır.
Güncelleme: 16 Ağustos 2026. Kurallar ICANN kapsamındaki gTLD transferleri temel alınarak özetlenmiştir; uzantı ve kayıt kuruluşuna özgü güncel şartlar ayrıca kontrol edilmelidir.
Sorun genellikle kodu bulamamakla bitmiyor. Alan adının kilit durumu, kayıt sahibinin iletişim bilgileri veya yakın tarihte yapılan bir değişiklik yüzünden aktarım daha başlamadan durabiliyor. Kontrol sırasını doğru kurmak, destek talepleri arasında gün kaybetmeyi önler.
Önce hangi işlemi yapmak istediğinizi netleştirin
Hosting taşımak için domaini mutlaka başka kayıt kuruluşuna aktarmanız gerekmez. Web sitesini yeni sunucuya yönlendirmek çoğu zaman DNS kayıtları veya nameserver değişikliğiyle yapılır. Registrar transferi ise alan adının kayıt ve yenileme yönetimini başka bir ICANN akreditasyonlu firmaya geçirir.
Bu ayrım önemlidir; yanlış anda hem DNS hem registrar hem de kayıt sahibi bilgisini birlikte değiştirirseniz hangi işlemin soruna yol açtığını bulmak zorlaşır. Genel tescil, sahiplik ve yenileme düzeni için forumdaki domain satış ve tescil rehberine bakabilirsiniz.
EPP kodu tek başına aktarımı başlatmaya yetmez
ICANN belgelerinde kodun resmî adı AuthInfo Code. Piyasada EPP kodu, transfer kodu veya yetkilendirme kodu da deniyor. ICANN’in Auth-Code açıklamasına göre kayıt kuruluşu, kodu panelden üretmenize izin verir ya da talebinizden sonra beş takvim günü içinde sağlar.
Bu kodu parola gibi düşünün. Forum mesajına, ekran görüntüsüne veya herkese açık destek kaydına yazmayın. Yeni kayıt kuruluşunun kendi transfer ekranı dışında paylaşmanız isteniyorsa adresi ve talebi yeniden doğrulayın.
Kod doğru olsa bile alan adı aktarım kilidindeyse istek reddedilebilir. ICANN EPP durumları rehberinde
clientTransferProhibited, mevcut kayıt kuruluşundan başka bir kuruluşa aktarım isteğinin reddedileceğini anlatır. Bu kilit çoğu panelde “transfer lock” veya “domain lock” adıyla açılıp kapatılır. serverTransferProhibited gibi sunucu tarafı durumlarda ise doğrudan registrar desteği gerekebilir.“60 gün” tek bir sebep için kullanılan genel sayaç değildir
En fazla karışan nokta burası. Güncel ICANN Transfer Policy, ICANN kapsamındaki genel üst düzey alan adlarında farklı 60 günlük durumlar tanımlar. Bunları aynı olay gibi anlatmak doğru olmaz:
- İlk tescilden sonraki 60 gün içinde registrar değişikliği engellenebilir.
- Bir registrar transferinden sonraki ilk 60 günde yeni bir transfer sınırlanabilir.
- Kayıt sahibi adı, kuruluşu veya ilgili e-posta gibi bilgiler değiştiğinde 60 günlük “Change of Registrant” kilidi uygulanabilir.
Kayıt sahibi değişikliği kilidinde bazı registrarlar, değişiklik yapılmadan önce vazgeçme seçeneği sunabilir; bunu sunmak her durumda zorunlu değildir. Önce iletişim bilgisini değiştirip sonra aktarım istemek bu yüzden planı geciktirebilir. Nihai hedef registrar değişikliği ise, mevcut firmanın politikasını okuyup işlem sırasını destekten yazılı olarak doğrulamak daha güvenlidir.
Kesin hüküm kurmayın' Alıntı:
Aktarımdan önce uygulanacak kısa kontrol sırası
- Registrar ve sahiplik: ICANN Lookup üzerinden kayıt kuruluşunu kontrol edin; panel hesabının ve kayıtlı e-posta kutusunun erişilebilir olduğundan emin olun.
- Durum kodları:
clientTransferProhibited,pendingTransfer,redemptionPeriodveya başka bir engel görünüyor mu bakın. - Yakın tarih: İlk tescil, son transfer veya kayıt sahibi bilgisi değişikliği 60 günlük döneme giriyor mu kontrol edin.
- Süre ve ödeme: Alan adını son güne bırakmayın. Bitiş tarihini, mevcut yenileme durumunu ve önceki kayıt dönemine ilişkin ödeme sorunu bulunup bulunmadığını doğrulayın.
- DNS kaydı: A, AAAA, CNAME, MX, TXT ve nameserver değerlerinin bir kopyasını alın. Registrar transferi DNS’i değiştirmemeli diye varsaymak yerine, iki firmanın akışını teyit edin.
- EPP/AuthInfo: Kodu son aşamada üretin, güvenli tutun ve yeni registrarın resmî panelinden işlemi başlatın.
Site ve e-posta aynı alan adına bağlıysa DNS kopyası özellikle önemlidir. Taşıma öncesi genel yayın kontrolü için hosting ve domain sorunları rehberi, posta kayıtları için de SPF, DKIM ve DMARC konusu yardımcı olabilir.
Aktarım reddedildiyse hata mesajını parçalayın
“Transfer edilemiyor” mesajı tek başına teşhis değildir. Yeni registrarın verdiği istek numarasını, alan adının o andaki EPP durumlarını ve mevcut registrarın açıkladığı ret sebebini kaydedin. ICANN’in kayıt sahibi SSS sayfası; yeni tescil, kayıt sahibi değişikliği kilidi, dolandırıcılık şüphesi, yetkilendiren kişinin kimliği üzerindeki makul uyuşmazlık ve bazı ödeme/uyuşmazlık durumlarının aktarımı engelleyebileceğini açıklıyor.
Önce şu ayrımı yapın:
- Kod reddediliyor: Yeni bir AuthInfo kodu üretip boşluk veya eski kod ihtimalini kontrol edin.
- Kilit görünüyor: Kilidin kullanıcı tarafından mı, registrar/registry tarafından mı konduğunu sorun.
- 60 gün uyarısı geliyor: Sayacın ilk tescil, önceki transfer veya kayıt sahibi değişikliğinden hangisine bağlı olduğunu yazılı olarak isteyin.
- E-posta gelmiyor: Spam klasöründen önce kayıtlı iletişim adresinin doğru ve erişilebilir olduğunu doğrulayın; aktarım sırasında aceleyle değişiklik yapmayın.
Registrar gerekçe vermeden veya politika dışı biçimde süreci engelliyorsa yazışmaları saklayın ve ICANN’in resmî transfer şikâyeti kanalını değerlendirin. Ancak ccTLD uzantılarında yetkili kurum ve uyuşmazlık yolu farklı olabilir.
Aktarım tamamlandıktan sonra işi bitmiş saymayın
Yeni panelde kayıt sahibi bilgilerini, nameserverları, otomatik yenilemeyi ve alan adının yeni bitiş tarihini kontrol edin. Web sitesini,
www yönlendirmesini ve e-posta alıp göndermeyi gerçek bir testle doğrulayın. Eski registrar hesabında başka domainleriniz kalıyorsa hesabı hemen kapatmayın; önce envanteri çıkarın.Özetle: Önce registrar transferiyle DNS taşımasını ayırın; sonra sahiplik, EPP durumu ve 60 günlük kilidin hangi olaya bağlı olduğunu doğrulayın. AuthInfo kodunu en son ve yalnız resmî panelde kullanın. Sorun yaşadıysanız kodu paylaşmadan yalnız uzantıyı, durum kodunu ve registrarın verdiği ret sebebini yazmanız teşhisi kolaylaştırır.
Güncelleme: 16 Ağustos 2026. Kurallar ICANN kapsamındaki gTLD transferleri temel alınarak özetlenmiştir; uzantı ve kayıt kuruluşuna özgü güncel şartlar ayrıca kontrol edilmelidir.
Dijital Dünyanıza Yön Veren Pusula
