Domain transfer ve auth code: Türkiye ile yurtdışı registrar farkları

Auth code (EPP) nedir ve neden süre sınırlıdır

Auth code veya EPP kodu, alan adı transferinde sahipliği ve yetkiyi kanıtlayan geçici bir anahtar gibi düşünülebilir. Kod üretildiği anda süre sınırlı olabilir ve belirli bir registrar işlemine bağlıdır. Bu yüzden “yarın hallederiz” yaklaşımı transfer penceresini kaçırır. Kodun süresi dolduğunda yeni kod üretmek gerekir; bu da e-posta zincirini ve onay adımlarını baştan tetikler. Zaman planı üretmeden transfer takvimi yazmak hata oluşturur.

Kod, halka açık WHOIS ekranından bağımsızdır; gizlilik hizmeti açık olsa bile kod üretimi registrar panelinde gerçekleşir. Kimi zaman kod e-postası spam veya yanlış filtrede kalır; registrant iletişim adresinin güncelliği bu yüzden kritiktir. Transfer öncesi posta kutusu doğrulaması yapılmadıysa ilk engel burada çıkar.

Kod tek başına yeterli değildir; transfer kilidi (transfer lock) açık olmayabilir veya premium/çıkış koruması gibi ek kısıtlar bulunabilir. Bu kısıtlar farklı arayüzlerde gizlenebilir; dikkat etmezseniz “kodu aldık ama transfer başlamıyor” döngüsü yaşanır.

Türkiye ve yurtdışı registrar farkları (pratik çerçeve)

ccTLD ve gTLD politikaları farklıdır; bazı uzantılarda belge veya ek doğrulama istenebilir. “Genel rehber” tek tek uzantı yerine süreç prensiplerini anlatır: önce durum sorgusu, sonra kod, sonra transfer isteği ve onay e-postası, ardından durum takibi. Yurtdışı registrarlar çoğu zaman otomasyonu güçlüdür; yerel kayıt sağlayıcılar ise farklı arayüz ve SLA ile çalışabilir. Bu farklar takvim sapması üretir.

Kimlik doğrulama adımları bazı sağlayıcılarda iki faktörlü kimlik doğrulama ile güçlenir. Cihaz değişimi veya OTP sorunları transferi bekletir. Satıcı ve alıcı, “hesaplara erişim sorunsuz” varsayımını erken test etmelidir.

Bazı satıcılar aynı alan adını birden fazla yerde yönettiklerini fark etmez: biri registrar, diğeri ajans paneli gibi. Bu da kodun “doğru yerde” üretilmediği senaryolarını doğurur. Yönetim tek kaynak olmalıdır; değilse önce konsolidasyon planı yapılmalıdır.

Transfer kilidi, durum kodları ve beklenen aralıklar

Transfer kilidi açık görünse bile yanlış sekmede olunan durumlar olur. Panelde birden fazla alan adı veya alt yönetim rolü varsa doğru hesapta olunduğundan emin olun. Kilidi kapatma eylemi bazı panellerde ek onay ister; bu onay e-postaya düşmezse işlem yarım kalır. Ekran kaydı veya tarih damgalı ekran görüntüsü taraflar arasında yanlış anlaşılmayı azaltır.

Domain durum kodları (okunabilir registrar terminolojisi) transfer için önemlidir; “pending transfer” yakınında takılı kalan durumlar destek talebi gerektirebilir. Süreler “birkaç gün” gibi geniş aralıkta verilir; fakat DNS kesintisi, e-posta doğrulama veya nameserver değişikliği gibi olaylarla çakışırsa algı daha uzun sürer.

Transfer sırasında nameserverları değiştirmek bazı senaryolarda risklidir. Çakışan değişiklikler, doğrulama veya DNS tutarlılığını etkileyebilir. Erken plan, “önce transfer, sonra DNS hassas düzenlemesi” yaklaşımına göre kurulabilir.

E-posta onayı ve kimlik avına karşı disiplin

Onay e-postaları, saldırganların favori taklit alanıdır. Bağlantıya tıklamadan göndericiyi ve hedef adresi doğrulayın. Sahte “transfer onayı” yüzünden alan adı dışarı çıkabilir. Şüphe halinde işlemi durdurup registrarın resmi panelinden durumu kontrol edin. Hiçbir hassas bilgiyi mesajlaşmadan paylaşmayın.

Registrant e-postasını güncellemek bazen ayrı bir onay gerektirir. Bu onay süresi kod süresinden bağımsız ilerler ve kesişmezse takvim kayar.

Kurumsal hesaplarda yetkisiz biri kod üretmiş olabilir; bu yüzden rol yönetimi ve denetim izi önem taşır. Transfer yüksek bedelli satışların parçası olduğunda bu adımlar kimlik teyidi ile birleştirilir.

Satıcı ve alıcı için zaman çizelgesi şablonu

Önerilen üst seviye sıra: ön kontrol (WHOIS, kilit, iletişim), kod üretimi ve süre takibi, alıcı hesabında transfer başlatma, onay e-postaları, durum “tamam” doğrulaması ve son olarak DNS/yardımcı hizmetler. Bu sıra projeye göre oynamak zorunda kalabilir; fakat sıranın yazılı olmaması kaosu büyütür.

İkinci kod planı, ilk kodun yanlış girilmesi veya süre dolması riskine karşı konur. Plan yoksa taraflar birbirini suçlar; oysa risk yönetimi meselesidir.

Tatil ve hafta sonu destek saatleri transfer süresini uzatabilir. Bu yüzden iş takvimi insan desteği ihtimalini içermelidir.

ccTLD ve özel durumlar için ek kontroller

Bazı ccTLD politikaları el değiştirmeyi kısıtlar veya yerel temsil isteyebilir. Bu, “domain satıyorum” ile “teknik olarak transfer mümkün” arasında fark yaratır. Satıcı, bu politikaları gizlememelidir; çünkü alıcı sonradan fark ettiğinde güven kırılır.

Marka koruma veya ihtar geçmişi varsa transfer teknik olarak mümkün olsa bile hukuki risk taşır. Bu riskler domain rehberinin dışında ama satış sürecinin parçasıdır.

Premium domainlerde ek ücret veya özel transfer süreçleri olabilir. Bu maliyetler veya sürprizler fiyat pazarlığına dahil edilmelidir.

DNS, e-posta ve yan hizmetlerin sırası

Transfer tamamlanırken e-posta hizmeti kesintiye uğrayabilir: MX kayıtları veya doğrulama e-postaları etkilenir. Bu yüzden kritik kutular için yedek iletişim kanalı planlanmalıdır. Bazı kurulumlarda DKIM seçicileri eski registrar panelinde bağlıdır; transfer sonrası yeniden kurulmalıdır.

SSL sertifikaları ve alt alan yapısı transfer sonrası kontrol edilmelidir. Otomatik yenileme araçları eski hesapta kalabilir. Bu sızıntılar sessiz kesinti üretir.

CDN veya güvenlik duvarı hesapları alan adına bağlı olabilir; transfer ile otomatik taşınmayabilir. Entegrasyon checklistine eklenmelidir.

Hata ayıklama: transfer neden takıldı

Sık nedenler: süresi dolmuş kod, yanlış registrar hedefi, eksik WHOIS doğrulaması, kurumsal onay bekleyen politika, ücret veya bakiye sorunu, yanlış alan adı yazımı. Bu nedenleri tek tek elemek için registrar durum kodunu okuyun ve destek bileti açmadan önce otomatik mesajları kaydedin.

Destek bileti açarken kısa zaman çizelgesi ve yapılan adımlar listesi eklemek çözüm süresini kısaltır. Uzun duygusal mesajlar yerine olgu listesi daha işe yarar.

Taraflar arasında “transferin teknik olarak mümkün olduğu” önceden test edilmeden tam ödeme yapılmamalıdır. Bu öneri, risk dengesi içindir; tek hukuki yöntem değildir, işlem tasarımıdır.

Kapanış: güvenli ve öngörülebilir transfer kültürü

Auth code bir “sihirli kelime” değildir; registrar politikaları, iletişim güvenilirliği ve zaman yönetimi ile birlikte anlam kazanır. İyi bir süreç, panik yerine kontrol listesi üretir. Bu rehber pratik hatırlatmadır; uzantıya özel zorunluluklar için registrar belgeleri ve gerekiyorsa hukuki danışmanlık başvurulmalıdır.

Satılık domain devrinde güven, hızdan daha pahalıdır. Acele isteyen taraf, çoğu zaman ya bilgisizdir ya da baskı kurar. Yazılı takvim ve makul doğrulama adımları, iki tarafı da korur.

Son olarak, DNS değişiklikleri ile transfer işlemini aynı güne sıkıştırmamak genellikle daha güvenlidir; çünkü hata ayıklama iki olayı birbirine karıştırır. Parçalayın, doğrulayın ve sonra kapatın.

Satılık domain pazarlığında teknik ve hukuki hatayı ayırın

Transfer takıldığında çoğu tartışma “kim hatalı” yerine “hangi politika” sorusuna kaymalıdır. Teknik ekip transferin blokajını ararken hukuk tarafı sözleşme kapsamını kontrol eder; iki soru birbirinin yerine konursa süreç uzar. Bu ayrım, özellikle uzantıya özel belge isteyen ccTLD’lerde önemlidir çünkü blokaj insan hatası değil politikadır.

Satıcı bazen “transfer garantisi” verir; fakat garanti kapsamı politika dışı bir engelle karşılaşıldığında ne olacağını söylemez. Net yazılmayan garanti, iki tarafı da mağdur eder. Doğru yaklaşım, makul çaba tanımı ve alternatif yollar (örneğin registrar içi hesap devri, geçici DNS çözümü) listesidir.

Alıcı tarafında erken doğrulama, transferin teknik olarak mümkün olduğunu değil, aynı zamanda hukuken tartışmasız devredilebilir olduğunu da işaret etmelidir. İkincisi her zaman garanti edilemez; fakat bilinen risklerin yazılması yanlış beyan riskini azaltır.

Ek notlar: süreler, destek biletleri ve kötü senaryo planı

Registrar destek biletleri beklenenden uzun sürebilir. Bu yüzden zaman çizelgesinde “insan onayı” penceresi bırakın. Kötü senaryo planı şunları içermelidir: kod süresi doldu, yanlış registrarda işlem başlatıldı, onay e-postası yanlış kutuya düştü, kimlik doğrulama cihazı kayboldu. Bu senaryolar için sırayla ne yapılacağı yazılı olunca panik azalır.

Çok adımlı transferlerde küçük ücretler veya bakiye yükleme gereksinimleri çıkabilir. Tutar küçük olsa bile prosedür eksik kalırsa takılır. Bu nedenle masraf ve yetki hazırlığı peşin yapılmalıdır.

Son olarak, bu rehber genel teknik süreç özetidir; uzantı bazlı zorunluluklar değişebilir. Kesin adım listesi için registrar dokümantasyonu ve gerekiyorsa hukuk danışmanlığı birlikte kullanılmalıdır. İyi planlanmış transfer, hem alıcı hem satıcı için beklenen riski küçültür ve vitrin güvenini güçlendirir.

Transfer öncesi ve sonrası iletişim planı (satıcı-alıcı senkronu)

Transfer sürecinde en çok zaman kaybettiren unsur, “kim bekliyor” belirsizliğidir. Günlük kısa durum notu (auth code üretildi, transfer başlatıldı, onay bekleniyor, tamamlandı) paniği kırar. Notlar tek kanaldan ve mümkünse tek metin dosyasında birikirse mesaj dağınıklığı azalır.

Satıcı tarafında registrant e-postasının güncellenmesi gerekiyorsa bu işlem bazı panellerde ek onay gerektirir; alıcı bunu “gecikti” sanmadan önce resmi prosedür süresini yazılı paylaşmalıdır. Alıcı tarafında ise transfer isteği başlatılırken yanlış registrara veya yanlış eşleşmeye düşmek sık görülür; iki kez kontrol kültürü küçük harf büyük harf duyarlılığından daha önemlidir.

Transfer sonrası ilk 48 saatte DNS ve e-posta hatlarında görülen uyumsuzluklar bazen “transfer başarısız” sanılarak panik üretir; oysa çoğu durum nameserver veya TTL ile ilgilidir. Bu yüzden olay ayrıştırma disiplini gerekir: önce nameserver ve MX, sonra SSL ve uygulama katmanı. Ayrıştırma yapılmadan paralel müdahale yanlış teşhis üretir.

Yüksek bedelli işlemlerde, tarafların aynı “runbook” metnini kullanması faydalıdır: adım adım ekran başlıkları yerine, tamamlanması gereken olaylar listesi. Çünkü registrar arayüzleri değişkendir; sabit ekran isminden çok doğrulanacak olay dili daha dayanıklıdır.

Son olarak, registrar politikaları değişebilir; bu yüzden rehberin kendisi de güncellenmeyi bekler. Transfer macerasında tek gerçek sabit, yazılı iletişim ve tutarlı zaman çizelgesidir. Bu ikisi varsa teknik engellerin çoğu çözülebilir; yoksa küçük engeller bile ihtilafa dönüşür.

Son bir pratik ekleme: transfer tamamlandığında adım adım “doğrulama turu” yapın—WHOIS kaydı, nameserver listesi, kritik subdomainlerin çözümü ve e-posta doğrulama testi. Bu tur, “transfer oldu sanıyorduk ama eski panele takılı kaldık” senaryolarını erken yakalar.

Ek güvence için, transfer tamamlandıktan sonra alan adı yönetim panelinde yöneticiler listesini ve gerekiyorsa alt kullanıcıları gözden geçirin. Eski paylaşılan tokenlar veya API anahtarları varsa yeniden üretim ve iptal planına bağlayın; çünkü transfer teknik olarak bitsin de hesap yan hizmetleri eski kurallarla yaşamaya devam edebilir.

Bu ek adım çoğu zaman “sonradan yapalım” denerek atlanır; oysa hesap sınırı ve güvenlik açısından ucuz bir sigorta gibidir.

Bu rehberi kapatırken kritik uyarı şudur: aynı alan için hem eski registrar hesabında kalan yan API bağlantılarını hem de yeni hesaptaki otomasyonların birbirinin üzerine yazabileceği kısa pencereleri tek bir çizelgede yazın. Küçük pencereler bile üretimi etkileyebildiğinden iki taraf bu çizelgeyi “kesin tarih olarak kabul etmek” yerine risk notu olarak bile paylaşırsa daha az kriz çıkar çünkü herkes beklenenden fazla sıkışma yaşanabileceğini önceden fiyatlıyordur.

Bu kapanış için bir ek daha: kimi ccTLD ve karma uluslararası senaryolarda ek doğrulama, kimlik doğrulama zinciri veya IDN uyumu transfer takvimini uzatabilir; çünkü panelde doğru görünen alan adı kaydı ile registrar tarafında işleyen kurallar aynı hızda dönmeyebilir. Bu yüzden “aynı uzantı, aynı hız” varsayımı yerine çıkış planına küçük bir bölgesel doğrulama süresi kutusu eklemek profesyonelliği yükseltir; taraflar olası belge ya da ek onay gereksinimini erken tarih sıralı kabul etmek için yazıya bağlarsa son güne kalan gereksiz sürprizler azalır.