Domain Tescil Sağlayıcısıyla İletişim: Müşteri Hizmetleri, Kimlik Doğrulama ve Destek Süreçleri

Bir domain tescil sağlayıcısı (registrar) ile iletişim — yüzeyde basit görünen, ama iş ciddileştiğinde işletmenin kaderini belirleyen bir konudur. Bir alan adı kaybetme tehdidi, transfer süresi içinde geri dönmeyen bir e-posta, kimlik doğrulama nedeniyle kilitli kalan bir panel, ya da yanlış kişiye geçmiş bir WHOIS sahipliği — her biri saatler içinde çözülmesi gereken kriz senaryolarıdır. Bu rehber, isim tescil iletişim başlığı altında bir registrar'ın müşteri hizmetleri kanallarını nasıl etkili kullanacağınızı, hangi belgeleri önceden hazırlayacağınızı, hangi durumlarda ICANN veya TRABİS gibi düzenleyici otoritelere başvurabileceğinizi ve yaygın 30+ destek senaryosunda doğru iletişim akışının nasıl kurulacağını adım adım anlatıyor.

Yazı, vendor-neutral bir bakışla yazılmıştır — yani belirli bir firmayı tavsiye etmek için değil, sektörel standartları (ICANN ERRP, RAA, TRABİS yönetmeliği, RFC 5733 EPP komutları) ve Türkiye'deki uygulama pratiklerini şeffaf biçimde aktarmak için. Sonunda hangi kanaldan, hangi formatta, hangi belgelerle iletişime geçmeniz gerektiğini netleştirmiş olacaksınız.

İlgili rehberler: Domain nedir ve WHOIS sorgulama · Domain sorgulama araçları (WHOIS, RDAP, DNS) · DNS ayarları · Let's Encrypt ile SSL · SSL sertifikası nasıl alınır

Registrar İletişiminin Sektörel Çerçevesi: ICANN, TRABİS ve RAA

Türkiye'de bir alan adı tescil ettiğinizde, sağlayıcınız iki katmanlı bir düzenleyici çerçeve altında çalışır. Birincisi ICANN (Internet Corporation for Assigned Names and Numbers) — gTLD'ler (.com,.net,.org,.info,.io vs.) için akreditasyon, RAA (Registrar Accreditation Agreement) sözleşmesi ve şikayet mekanizmasını işleten kurum. İkincisi TRABİS (Bilgi Teknolojileri ve İletişim Kurumu bünyesinde işletilen.tr Ağ Bilgi Sistemi) —.tr ve alt uzantıları (.com.tr,.net.tr,.org.tr,.av.tr,.gen.tr,.biz.tr,.info.tr, vs.) için kayıt operatörü.

Bu ikili yapı, bir destek talebi açtığınızda hangi kuralların geçerli olacağını doğrudan etkiler. Örneğin bir .com domain transferinde sağlayıcı ICANN'in Transfer Policy kurallarına uymak zorundadır; oysa bir .com.tr transferinde TRABİS'in kayıt yönetmeliği geçerlidir ve süreç teknik olarak farklı işler. Sağlayıcıyla iletişimde hangi uzantıdan bahsettiğinizi en başta belirtmek, doğru destek ekibine yönlendirilmek için kritiktir.

ICANN Akreditasyon Numarası ve RAA Yükümlülükleri

Bir registrar'ın ICANN akreditasyon numarası (IANA ID) o firmanın gTLD satma yetkisinin teyididir. IANA registrar listesi üzerinden herhangi bir sağlayıcının akreditasyon durumunu doğrulayabilirsiniz. RAA, registrar'ı şu yükümlülüklere bağlar: 5 günlük yenileme bildirimi (ERRP — Expired Registration Recovery Policy), kayıt sahibinin verilerinin doğruluğunun yıllık teyidi, yetkili şikayet hattının (abuse contact) sürekli açık tutulması, iş günü içinde 24 saatlik yanıt süresi (ICANN compliance bildirimi durumunda).

TRABİS ve.tr Uzantıları

2018 sonrasında ODTÜ Nic.tr'den TRABİS'e devredilen.tr operasyonu, kayıt operatörü-kayıt kuruluşu (registrar) modelini benimsedi. Bir.com.tr veya.av.tr için sağlayıcınızla iletişiminizde, sağlayıcının da TRABİS ile API üzerinden iletişim kurduğunu unutmayın — yani iki katmanlı bir bürokratik akış vardır..tr uzantıları için .com.tr uzantısı almak rehberi yazımız ek detay sunar;.tr'ye özel .av.tr gibi belge gerektiren uzantılar için ise .av.tr domain alma rehberi'ne göz atın.

İletişim Kanalları: Hangi Sorun, Hangi Kanaldan Çözülür?

Türkiye'deki yerel domain sağlayıcılarında — İsimTescil, Natro, Turhost, Turkticaret, Hostinger TR, GoDaddy TR ve diğerleri — birbirine benzer bir iletişim kanalı seti karşımıza çıkar. Ama her kanalın uygun olduğu farklı senaryolar vardır. Yanlış kanal, sürekli ping-pong ve saatlerce gecikme demektir.

• Telefon: Acil hesap kilidi, ödeme alındı ama ürün açılmadı, panel erişimi yok gibi zaman kritik senaryolar için. 7/24 hatlar genelde 0850 ile başlar (yerel ücretli) ve PBX yönlendirmesi yapar.
• Canlı destek (live chat): Domain seçimi, paket karşılaştırma, fatura sorularında ideal. Genelde 09:00-23:00 saatleri arasında insan temsilcisi, dışında AI asistan/bot.
• Ticket (destek talebi): Teknik hata, log analizi gereken durumlar, kalıcı kayıt gerektiren talepler için. Tipik SLA: 30 dakika–4 saat ilk yanıt, 24 saat çözüm hedefi.
• E-posta: Belge eki gerektiren işlemler (kimlik doğrulama, transfer onayı, fatura iadesi). Genel adresler: destek@, info@, kimlik@, finans@, abuse@.
• WhatsApp Business / Sosyal medya DM: Resmi destek olmasa da bazı sağlayıcılar burada hızlı geri dönüş sağlar; ancak hassas veri paylaşılmamalı.
• Şikayet siteleri (Şikayetvar, ekşi sözlük): Resmi kanaldan dönüş alamadığınız durumlarda kamuya açık baskı kanalı; bazı sağlayıcılar bu kanalları aktif yönetip 1-2 saatte iletişime geçer.

Acil Durum Karar Ağacı

Sorununuzu hangi kanala götüreceğinize karar verirken üç soruyu sorun: (1) dakika cinsinden mi acil, yoksa saat-gün cinsinden mi? (2) belge eki gerekiyor mu? (3) kayıt altına alınmalı mı (denetim, hukuki süreç ihtimali)? Bu üç soruya verdiğiniz cevaplar kanalınızı belirler.

Kimlik Doğrulama: En Sık Karşılaşılan Engel

Domain panelinizde GSM güncelleme, e-posta değişikliği, sahiplik transferi, fatura bilgisi değişikliği, paneldeki yetkili kişi değişikliği — bu işlemlerin tamamı kimlik doğrulama gerektirir. Türkiye'deki sağlayıcılar tipik olarak şu üç yöntemden birini kullanır.

• Kimlik fotokopisi + dilekçe: Bireysel hesaplar için. T.C. kimlik kartının ön-arka taraması, üzerine 'Sadece [şirket adı] hesap güncellemesi içindir' notu ve tarih. KVKK gereği fotokopinin diğer alanları kapatılabilir; ancak ad-soyad, T.C. no ve fotoğraf görünmelidir.
• İmza sirküleri + faaliyet belgesi + vergi levhası: Kurumsal hesaplar için. İmza sirküleri 6 aydan eski olmamalı, faaliyet belgesi son 6 ay içinde alınmış olmalı.
• e-Devlet üzerinden teyit: Bazı modern sağlayıcılar, e-Devlet'e bağlanarak SMS/Push doğrulama yapar. En hızlı yöntem; saniyeler içinde tamamlanır.

GSM Numarası Güncelleme: Klasik Senaryo

Cep telefonu numaranızı kaybettiyseniz veya değiştirdiyseniz, paneldeki SMS doğrulama tetiklenmeyeceği için tek başınıza işlem yapamazsınız. Sağlayıcı bu durumda elle güncelleme yapar — ama sizden formel bir talep ister.

Önemli güvenlik notu: Kimlik fotokopisini gönderirken üzerine filigran ekleyin — örneğin 'Sadece [Sağlayıcı] GSM güncelleme talebi içindir, başka amaçla kullanılamaz'. Bu hem KVKK uyum gereği hem de fotokopinin yetkisiz ellerde başka işlemlerde kullanılmasını engelleyen bir önlemdir. WHOIS Sorgulama aracımız ile kayıtlı bilgilerinizi anonim olarak da kontrol edebilirsiniz.

E-posta Güncelleme ve İki Faktörlü Kayıp

Hesabınıza bağlı e-posta hesabını kaybettiyseniz (hesap kapanmış, kontrolünü kaybettiniz, eski iş yerinde kalmış) süreç biraz daha uzar. Sağlayıcı bu durumda hem kimliğinizi hem de domainin gerçek sahibi olduğunuzu doğrulamak için ek belgeler ister: domain'in faturası (sizden çıkmış olmalı), kayıt anındaki e-posta için DNS MX kayıtları (eski bir e-posta servisi varsa) ya da panele en son giriş yaptığınız IP adresi.

Eğer iki faktörlü doğrulama (2FA) aktifse ve hem GSM'i hem 2FA app'ini kaybettiyseniz, kurtarma kodlarını (recovery codes) hesabı kurarken kaydetmiş olmanız gerekir. Aksi halde 'sıfırdan kimlik doğrulama' süreci başlar — bu 2-7 iş günü sürebilir.

Sahiplik (Owner) Değişikliği ve Trade İşlemleri

Bir domain'in sahibini değiştirme işlemine ICANN Change of Registrant der;.tr uzantılarında ise Trade olarak geçer. Her iki süreç de kayıt sahibi (registrant) bilgilerinin değişmesi anlamına gelir ve sağlayıcının iletişim ekibiyle yoğun yazışma gerektirir.

• Eski sahibin onayı (kimlik fotokopisi + dilekçe): işlemin başlatılabilmesi için.
• Yeni sahibin kabulü (kimlik fotokopisi + dilekçe): yeni kaydın oluşması için.
• 60 günlük transfer kilidi (gTLD'lerde): Change of Registrant sonrası ICANN kuralı gereği başka bir registrar'a transfer 60 gün boyunca kilitlenir..tr'de bu kilit yoktur ama 7-14 günlük teknik bekleme süreleri olabilir.
• WHOIS doğrulama e-postası: Yeni kayıt sahibine gelen e-postaya 15 gün içinde tıklanmazsa domain askıya alınır.

Sahiplik değişikliği iletişiminde dikkat: Sağlayıcı, eski sahibin yazılı onayı olmadan asla işlemi başlatmamalıdır. Eğer 'eski sahip ulaşılamıyor' senaryosundaysanız (vefat, fesih, anlaşmazlık), iş hukuki bir sürece döner — sağlayıcının kendi başına çözebileceği bir konu değildir; mahkeme kararı, veraset belgesi veya tasfiye kararı gibi resmî belgeler gerekir.

Transfer İşlemleri: EPP Kodu ve Auth-Info Süreçleri

Domain'inizi başka bir registrar'a taşımak için (transfer-out / transfer-in), kaynak sağlayıcıdan bir EPP kodu (Auth-Info Code, transfer authorization code) almanız gerekir. RFC 5731 ve 5732'de tanımlı olan bu kod, domain'in kontrolünün el değiştirmesi için kullanılan tek seferlik bir kimlik doğrulama jetonudur.

EPP kodunu alma süreciyle ilgili sağlayıcıya yapacağınız tipik talep iki adımdan oluşur: önce panel üzerinden 'transfer kilidi'ni kapatın (clientTransferProhibited statüsünü kaldırın), sonra 'auth code göster' butonuna tıklayın. Bazı sağlayıcılar EPP kodunu otomatik göstermez ve destek talebi açmanızı ister — bu yasal değildir; ICANN Transfer Policy gereği auth code 5 gün içinde sağlanmak zorundadır.

Transfer Reddi (NACK): Olası Nedenler

Transfer talebiniz reddedilirse (NACK) sağlayıcının size yazılı gerekçe sunması gerekir. ICANN Transfer Policy'de tanımlı olan kabul edilebilir 8 ret sebebi vardır: kayıt sahibinin yazılı itirazı, hukuki anlaşmazlık, ödenmemiş borç, transfer kilidi (60 günlük), domainin son 60 günde başka bir kayıt sahibine geçmiş olması, fraud şüphesi, RAA ihlali ve teknik arıza. Bunların dışında bir gerekçeyle reddedilen transfer hakkında ICANN'e şikayet edebilirsiniz.

Abuse Bildirimi: Kötüye Kullanım Şikayetleri

Bir domain üzerinden phishing, spam, malware dağıtımı, telif hakkı ihlali (DMCA), kişilik haklarına saldırı veya çocuk istismarı içeriği yapılıyorsa, sağlayıcının abuse@ adresine bildirim yapabilirsiniz. RFC 6650, ARF (Abuse Reporting Format) standardını tanımlar — sağlayıcılar bu formatta gelen şikayetleri otomatik işleyebilir.

Türkiye'deki çoğu sağlayıcı abuse şikayetlerini 24-72 saat içinde sonuçlandırır. Sonuç şu olabilir: domain askıya alma (suspension), DNS sıfırlama (clientHold), nameserver değişimi engelleme. Eğer sağlayıcı yanıt vermiyorsa şikayetinizi ICANN Compliance üzerinden iletebilirsiniz.

Faturalandırma ve İade Talepleri

Kredi kartı ekstresine yansıyan ama hesabınızda görünmeyen ödemeler, çift çekim, yanlış paket aktivasyonu, otomatik yenileme nedeniyle istenmeyen ödeme — finansal iletişim de en sık karşılaşılan destek konularındandır. Türkiye'de tüketici hukuku gereği 14 günlük cayma hakkı dijital hizmetlerde de çoğunlukla geçerlidir; ancak domain tescili 'kişiye özel hazırlanan dijital ürün' kapsamında değerlendirilip iade dışı tutulabilir. Bu ayrıntıyı sağlayıcının iade politikası sayfasında her zaman önceden okuyun.

• Yenileme iadeleri: Otomatik yenileme nedeniyle istenmeyen ödeme — çoğu sağlayıcı 30-45 gün içinde tam iade yapar.
• Kullanılmamış hosting paketleri: 14 gün içinde iade; sonrasında pro-rata.
• Domain tescili iadesi: ICANN registry üzerinden 5 gün içinde 'AGP delete' yapılabiliyorsa mümkün, sonrasında değil.
• Çift çekim: PSP (ödeme kuruluşu) loglarıyla kanıtlanırsa 1-3 iş gününde iade.
• SSL iadesi: Aktivasyon yapılmamışsa tam iade; CSR oluşturulduysa kısmi/sıfır.

İade Talebi Şablonu

DNS, Nameserver ve Kayıt Sorunları

Bir DNS değişikliği yaptınız, 24 saat geçti, hâlâ propagasyon tamamlanmadı — sağlayıcıyla iletişimde sıkça karşılaşılan bir senaryo. Çoğu zaman sorun TTL değerinden, eski cache'lerden veya DNSSEC imzasının yanlış kayıtlanmasından kaynaklanır. Detaylı DNS arıza analizi için DNS rehberimize başvurun.

Bu çıktıları sağlayıcıya yazdığınız tickete eklemek, ilk yanıt süresini en az %50 kısaltır. Çünkü destek temsilcisi 'önce siz şu komutları çalıştırın' yazışması yapmadan doğrudan analiz başlatabilir. Ek olarak, DNS Sorgulama aracımızı da bulgularınızı paylaşmak için kullanabilirsiniz.

Nameserver Değişikliği Reddediliyor

Nameserver değiştirmeye çalışıyorsunuz, panel 'işlem başarısız' diyor. Yaygın nedenler: (1) clientUpdateProhibited statüsü aktif — sağlayıcı güvenlik kilidi koymuş; (2) DNSSEC DS kaydı eski nameserver'a bağlı, önce DS kaldırılmalı; (3) glue record gerektiren child nameserver'lar ama parent zone'a glue eklenmemiş. Bu üç nedeni ticket'ta açıkça sorun, çözüm 5 dakika içinde gelir.

Müşteri Hizmetleri SLA'ları: Gerçekçi Beklentiler

Isim tescil müşteri hizmetleri için pazarlama materyallerinde sıkça '7/24 destek', 'ortalama 30 dakikada yanıt' gibi vaatler okursunuz. Bu rakamlar — sektörden topladığımız 2024-2026 saha verisine göre — şu gerçek aralıklara denk geliyor:

• Telefon ilk yanıt: 30 saniye–4 dakika (mesai içi), 1-8 dakika (mesai dışı). Hat meşgul olabiliyor; ısrarlı arayın.
• Canlı chat ilk yanıt: 1-3 dakika (mesai içi). Mesai dışında AI asistan; bot 'sizi temsilciye bağlıyorum' der ama bağlamayabilir.
• Ticket ilk yanıt: vaat 30 dk; gerçek 30 dk–6 saat. Hafta sonu 6-24 saat.
• E-posta ilk yanıt: 2-24 saat; çözüm 1-3 iş günü.
• Kimlik doğrulama süreci: 1-3 iş günü (belgeler eksiksiz ise).
• Transfer/Trade işlemi: 5-7 gün (ICANN), 7-14 gün (.tr).
• Abuse şikayeti aksiyonu: 24-72 saat.
• İade işlemi: 5-15 iş günü (banka tarafına yansıma).

Bu rakamlar Türkiye pazarındaki ortalamadır; bireysel sağlayıcılarda farklılık gösterebilir. Önemli olan, kendi tickedinizi açtığınızda sağlayıcının yazılı SLA'sını referans alıp süre aşıldığında kibar ama net bir şekilde 'bu süreniz aşıldı, eskalasyon istiyorum' demektir.

Eskalasyon: Çözülmeyen Sorunlar İçin

İlk yanıt geldi ama sorununuz çözülmedi. Aynı temsilci aynı yanıtı tekrarlıyor. Burada eskalasyon devreye girer. Sağlayıcı içi ve dışı eskalasyon yolları vardır.

Sağlayıcı İçi Eskalasyon

• Adım 1: Aynı ticket'ta 'lütfen kıdemli temsilciye eskale edin' yazın. Çoğu sağlayıcıda bu otomatik bir kuyruğa gider.
• Adım 2: Müşteri hizmetleri yöneticisine yazılı talep — ad-soyad ile 'müşteri ilişkileri direktörüne ulaşmak istiyorum'.
• Adım 3: Resmi şikayet formu — sağlayıcının 'kurumsal' veya 'iletişim' sayfasında genelde bir 'şikayet/öneri' formu vardır; bu form CRM yerine üst yönetim e-postasına düşer.

Sağlayıcı Dışı Eskalasyon: Düzenleyici Otoriteler

• ICANN Compliance (gTLD'ler için): icann.org/compliance üzerinden web formu. Tipik dosyalama süresi: 30-90 gün. Bağlayıcı kararlar ve registrar'a uyum baskısı.
• TRABİS (.tr için): TRABİS portalı üzerinden uyuşmazlık çözüm hizmeti (UÇH). UDRP benzeri tahkim modeli.
• WIPO Arbitration and Mediation Center: UDRP başvurusu — özellikle marka hakkı ihlali içeren domain anlaşmazlıkları için. Ücretli (~1500 USD) ama bağlayıcı.
• Ticaret Bakanlığı – Tüketici Hakem Heyeti: Türkiye'de bireysel tüketici şikayetleri (10.280 TL altı işlemler — 2026 limitleri) için ücretsiz alternatif uyuşmazlık çözümü.
• BTK Tüketici Şikayeti: btk.gov.tr üzerinden elektronik haberleşme hizmetleri kapsamına giriyorsa şikayet edilebilir.
• KVKK: Kişisel veri ihlali içeren olaylar için kvkk.gov.tr üzerinden başvuru.

WHOIS Doğruluğu ve ICANN WDRP

ICANN her yıl bir kez registrar'lara, kayıt sahiplerine WHOIS bilgilerinin doğruluğunu teyit etmesi için e-posta göndertir — buna WDRP (WHOIS Data Reminder Policy) denir. Bu e-postaya yanıt vermezseniz veya WHOIS bilgileriniz yanlışsa (sahte ad, var olmayan e-posta), domain 15 gün içinde askıya alınabilir.

Ayrıca herhangi biri sizin domain'inizin WHOIS'ini 'yanlış' diye ICANN WHOIS Inaccuracy Complaint Form'a şikayet edebilir. Sağlayıcı 15 gün içinde sizi teyide çağırır; teyit etmezseniz domain askıya alınır. Bu nedenle iletişim bilgilerinizin her zaman güncel olması, panel hesabınıza erişiminizin korunması hayati önemde.

GDPR, KVKK ve WHOIS Maskeleme

2018 GDPR sonrasında ICANN, gTLD WHOIS verilerini varsayılan olarak maskeleyen bir politika benimsedi. Türkiye'de KVKK aynı yönde işliyor. Şu an Türkiye'deki bir kayıt sahibinin gTLD WHOIS'i sorgulandığında genelde sadece 'REDACTED FOR PRIVACY' veya 'Data Protected' yazısı görülür; gerçek isim, e-posta, telefon görünmez.

Bu durum hem avantaj hem dezavantaj: Sahibin gizliliği korunur, ama dolandırıcılık veya marka ihlali iddialarında karşı tarafa ulaşmak zorlaşır. Yetkili otoritelere başvurmadan WHOIS arkasındaki kişiyi öğrenmek için sağlayıcıya 'tiered access' başvurusu yapmanız gerekir — bu da hukuki gerekçe ister.

İletişim Öncesi Hazırlık Listesi

Bir destek talebine başlarken yanınızda hazır olması gereken minimum bilgi seti aşağıdadır. Bu seti her seferinde tekrar derlemek zorunda kalmamak için bir not dosyasında saklayın.

• Müşteri/üye numaranız (panelin sağ üstünde genelde 7-8 haneli sayı)
• Hesaba kayıtlı e-posta ve son 4 haneli telefon
• Domain adı (tam yazımıyla, IDN ise punycode da)
• İlgili sipariş/fatura numarası (varsa)
• Daha önce açılmış ticket numaraları (referans için)
• Ekran görüntüsü / hata mesajı (zaman damgası ile)
• İlgili IP adresleri (panele en son giriş, hata aldığınız anda kullandığınız)
• Tarayıcı + işletim sistemi versiyonu (UI bug'ları için)
• cURL/dig çıktıları (teknik sorunlar için)
• Beklenen sonuç ('domain'i transfere açmak istiyorum', 'hosting paketini iade ediyorum' gibi net hedef)

Etkili Bir Destek Talebi Yazma Sanatı

Aynı sorunu iki farklı şekilde anlatan iki kullanıcıdan biri saatler içinde yanıt alır, diğeri günlerce ping-pong eder. Fark, talebin yazımındadır. İyi bir ticket dört bölümden oluşur: özet (1 cümlede ne istiyorsun), bağlam (kim olduğun + ilgili nesne), belirtiler (ne oluyor, ne bekliyordun), denediklerin (sen ne yaptın, ne işe yaramadı).

Bu yapı, destek temsilcisinin sorunu 30 saniyede anlamasını sağlar — ve doğru ekibi (transfer ekibi) seçmesini kolaylaştırır. Yanlış: 'merhaba transfer yapamıyorum yardım edin'. Doğru: yukarıdaki gibi yapılandırılmış format.

Sosyal Medya, Şikayetvar ve Kamuya Açık Baskı Kanalları

Resmi kanallardan dönüş alamadıysanız, sağlayıcının resmi Twitter (X), Instagram veya LinkedIn hesabından genel bir mesaj atmak bazen 1-2 saatte özelden geri dönüş getirir — çünkü kurumsal iletişim ekibi marka itibarını korumak için müdahale eder. Hassas veri (kimlik no, kart bilgisi, ticket no) asla kamuya açık post'ta paylaşılmamalı; DM'de bile temsilcinin kimliğini doğruladıktan sonra paylaşın.

Şikayetvar.com sağlayıcıların yanıt oranını ve müşteri memnuniyet skorunu kamuya açık tutar. Çoğu sağlayıcı bu platformda %95+ yanıt oranı korumak için aktif izleme yapar — ortalama 2-6 saat içinde özel mesaj gelir. Ama bu kanal SLA değildir; hukuki bağlayıcılığı yoktur. Resmi ticket'inizi kapatmadan paralel kullanın. Sağlayıcı seçerken topluluğa açık skorlara da bakın: Şikayetvar memnuniyet skoru, Trustpilot, Google Reviews, ekşi sözlük entry'leri.

Mağduriyet Senaryoları ve Çözüm Yolları

Topluluğumuzdan ve sahadan derlediğimiz en yaygın 8 'iletişim mağduriyeti' senaryosu ve her birinin çözüm yolu:

• 1. Domain'in süresi yenilemeden geçti, redemption ücreti istiyorlar. ICANN ERRP gereği sağlayıcı 30 gün içinde size 2 e-posta + 1 SMS göndermek zorundadır; gönderilmediyse 'redemption ücretsiz olmalı' argümanını kullanın.
• 2. EPP kodu 5 günden uzun süredir verilmiyor. ICANN Transfer Policy ihlali; ICANN Compliance şikayeti hazırlayın.
• 3. Eski yetkili kişi şirketten ayrılmış, panele giriş yok. Şirket kaşesi + imza sirküleri + faaliyet belgesi + yeni yetkili imzası ile sağlayıcıya başvuru, 3-5 iş günü.
• 4. WHOIS'imdeki ad yanlış, düzeltmek 'sahiplik değişikliği' gerektiriyor diyorlar. Yazım düzeltmesi (typo) sahiplik değişikliği değildir; ICANN Change of Registrant Policy buna açıkça izin verir.
• 5. Domain üzerinde 'clientHold' var, sebebi açıklanmıyor. Hold sebebinin yazılı bildirimi RAA gereği zorunludur; 'WHOIS doğrulama bekliyor', 'fraud şüphesi', 'mahkeme kararı' gibi.
• 6. Ödedim ama domain açılmadı, destek 'ödeme görünmüyor' diyor. PSP referans numarasını paylaşın; sağlayıcının finans ekibi 24 saat içinde teyit etmek zorundadır.
• 7. Otomatik yenileme istemiyordum, çekildi. 14 gün içinde tam iade, 14 gün sonrası kısmi/redden — net iletişim yapın.
• 8. Sağlayıcı kapanma/iflas durumunda. ICANN 'De-Accreditation Process' devreye girer; tüm domainler bir 'gaining registrar'a otomatik aktarılır.

Yedeklilik: İletişim Hattını Hiç Kaybetmemek İçin

Önemli bir domain'iniz varsa — özellikle bir e-ticaret sitesinin, kurumsal kimliğin veya marka değerinin altında — sağlayıcıyla iletişim hattınızı koparmadan tutmanın birkaç pratiği vardır.

• Birden fazla yetkili e-postası: Hesap registrant + admin + technical + billing rollerinin farklı e-postalarda olması; tek bir e-postaya bağımlılık riski büyüktür.
• Kurumsal e-posta + 2 yedek: domain@sirket.com ana, itadmin@sirket.com yedek, kurucu-kişisel@gmail.com son çare.
• Yetki belgesi PDF olarak hazır tutulması: İmza sirküleri + faaliyet belgesi + vergi levhası tarayıcıda saklı, böylece kriz anında 5 dakikada gönderilebilir.
• Yedek 2FA cihazı: Authenticator uygulamasının ikinci telefonda da kurulu olması, recovery kodlarının basılı/güvenli yerde saklanması.
• Auto-renewal AÇIK: Önemli domainlerde 'unutma' riskini sıfırlar; ödeme kartının da expire datesini takvimde tutun.
• Registry lock (yüksek değerli domainler için): Sağlayıcı + registry seviyesinde değişiklikleri tamamen kilitler; herhangi bir değişiklik için telefonla parola + 2FA.

İletişim Logu Tutma: Hukuki Güvence İçin

Her destek temasını dijital olarak loglayın: ticket numarası, tarih, temsilci adı (mümkünse), verilen söz, gerçek sonuç. Basit bir YAML/Notion tablosu yeterli — hukuki bir uyuşmazlığa düştüğünüzde altın değerinde olur. Tipik kayıt: tarih, kanal, ticket_no, temsilci, konu, vaat, durum (pending/escalated/resolved), cozum_suresi. Vaat-sonuç eşleşmesini takip etmek SLA aşımlarını ICANN/TRABİS şikayetinde delil olarak sunmanıza imkan tanır.

Çoklu Sağlayıcı, Reseller ve Kurumsal Hesaplar

Mission-critical bir domain'iniz varsa — örneğin Türkiye'nin en büyük 100 e-ticaret sitesinden biri — domain'lerinizi tek bir registrar'da tutmak risklidir. Yaygın 'belt and suspenders' yaklaşımı: birincil registrar'da tut, ikincil bir 'soğuk yedek' hesap aç, kritik domainin DNS yetkisini ikinci tarafta bağımsız bir nameserver'da host et. Detaylı sağlayıcı seçim kriterleri için hosting türleri ve seçim rehberindeki prensipler domain için de geçerlidir: SLA garantileri, akreditasyon, finansal sağlık.

Bireysel müşterinin destek deneyimi ile kurumsal müşterinin deneyimi gece-gündüz farklıdır. Kurumsal hesaplar genelde atanmış key account manager (24 saat içinde dönüş garantili tek temas), Slack/Teams kanalı, %99.9+ uptime SLA sözleşmesi (finansal tazminat hakkı), yüksek API/EPP/WHOIS kotası ve banka havalesi/vadeli fatura gibi çoklu ödeme yöntemine sahip olur. 50+ domain'iniz varsa kurumsal hesap görüşmesi yapın — sözleşme metnindeki liability cap, service credit ve data export maddelerini avukatınıza inceletin.

Bazen aldığınız domain doğrudan ICANN-akredite registrar'dan değil, onun reseller'ından gelir. Bu durumda iletişim zinciri iki katmanlıdır: önce reseller, sonra registrar. Reseller cevap vermezse veya iflas ederse, registrar size doğrudan destek vermek zorundadır — RAA bunu açıkça gerektirir. Bir domain'in registrar'ını öğrenmek için WHOIS'in 'Registrar' alanına bakın.

Çağrı Merkezi ve Türkiye Pazarı Pratikleri

Telefon görüşmesi etkili ama tuzaklarla doludur. Sözlü vaat hukuki kanıt değildir; her telefon görüşmesi sonrası özet bir e-posta atın: 'Bugün saat... görüşmemizde [vaat] söylediniz; bu yazışma teyit içindir.' IVR'ı kısayolla geçin (çoğu hatta '0' tuşu operatöre çıkar), müşteri numaranızı ilk 10 saniyede söyleyin, KVKK kapsamında 'görüşme kayıt altında mı?' diye sorma hakkınız var. Tarih, saat ve temsilci adını mutlaka notlayın.

Türkiye pazarına özel notlar: WhatsApp Business yaygın bir kanal; e-Devlet entegrasyonu kullanan sağlayıcılarda kimlik doğrulama saniyeler içinde tamamlanıyor; e-Fatura/e-Arşiv GİB uyumlu sistemden otomatik geliyor (7 yıl saklama yükümlülüğü); 7/24 vaadine rağmen 23:00-09:00 arası ve hafta sonları gerçek yanıt süreleri ciddi uzar. Resmi tatil ve bayram öncesi otomatik yenilenecek domainleri 5-7 gün önce kontrol etmek hayati.

Gizlilik, Güvenlik ve Otomatize Edilen İşlemler

Müşteri hizmetleri yazışmalarında asla paylaşılmayacak bilgi sınıfları: kart numaranız (sadece son 4 hane), CVV, parolanız, 2FA gizli anahtarı, T.C. kimlik no'nun tam hali (son 3 hane yeterli). Bu sınırlara saygı göstermeyen temsilci yanlış bir adımdır; üst kademeye şikayet edilmelidir. Sağlayıcının resmi alan adından gelen e-postaları SPF/DKIM/DMARC ile doğrulayın — phishing saldırılarında en sık taklit edilen kaynak destek e-postalarıdır.

Otomatize panel işlemleri için ticket açmaya gerek yoktur: nameserver değiştirme, DNS kaydı yönetme, otomatik yenileme açma/kapama, fatura indirme, GSM doğrulamasıyla parola sıfırlama. Manuel destek gerektirenler: GSM kaybı sonrası güncelleme, Trade işlemi, iade, abuse incelemeleri, hukuki yazışmalar. Sözleşmesel temel olarak Üyelik Sözleşmesi, Hizmet Sözleşmesi, Mesafeli Satış Sözleşmesi (TKHK) ve KVKK Aydınlatma Metni'ni arşivlerinizde saklayın — sağlayıcı zamanla güncelleyebilir, sizin imzaladığınız versiyon geçerlidir. BTK sorgulama rehberinde değindiğimiz üzere, BTK kapsamına giren elektronik haberleşme hizmetleri için ayrı bir tüketici şikayet kanalı vardır.

Final: 12 Maddelik İletişim Hijyen Listesi

Tüm bu rehberden çıkan en pratik özet — bir 'iletişim hijyen' kontrol listesi. Yıllık olarak gözden geçirin.

• 1. WHOIS bilgileriniz güncel ve sizin kontrolünüzde bir e-postaya bağlı.
• 2. Hesap kurtarma kodları güvenli ama erişilebilir bir yerde.
• 3. Yedek 2FA cihazı kurulu.
• 4. Kimlik belgeleri PDF olarak hazır (filigranlı, KVKK uyumlu).
• 5. Otomatik yenileme önemli domainlerde açık, ödeme kartı güncel.
• 6. Birden fazla yetkili e-postası registrant/admin/tech/billing rollerinde.
• 7. Registry lock yüksek değerli domainlerde aktif.
• 8. İletişim logu tutuluyor — yıllar sonrası için.
• 9. Sağlayıcı SLA'sı okunmuş ve kaydedilmiş.
• 10. Eskalasyon yolları (ICANN, TRABİS, BTK, KVKK) biliniyor.
• 11. Yedek registrar hesabı mission-critical domainler için soğuk yedek.
• 12. Yıllık WHOIS doğrulama e-postası gözden kaçırılmıyor.

Sıkça Sorulan Sorular

Domain sağlayıcısı 30 dakika 'ortalama yanıt' diyor ama 4 saattir bekliyorum — ne yapmalıyım?

Yazılı SLA ile pazarlama vaadi farklı şeylerdir. Önce ticket içine 'SLA aşıldı, eskale ediyorum' yazın. 24 saat geçtiğinde sağlayıcının 'iletişim' formundan müşteri ilişkileri direktörüne yazın. 48 saat geçerse ICANN/TRABİS şikayetini değerlendirin.

Sağlayıcımı değiştirmek istiyorum, mevcut sağlayıcı zorluk çıkarıyor — yasal hakkım nedir?

ICANN Transfer Policy gereği: (1) 60 gün önce kayıt veya transfer edilmiş bir domainin transferi gecikmeli olabilir; (2) bu süre dışındaki tüm domainler için EPP kodu 5 gün içinde verilmek zorundadır; (3) reddin yazılı gerekçesi sunulmalıdır. Aksi halde ICANN Compliance'a şikayet edebilirsiniz. Çağrı merkezi sözlü vaatlerinde de görüşme sonrası özet e-posta atma alışkanlığını edinin — bu yazışma artık kanıttır.

Kaynaklar

• ICANN Transfer Policy
• ICANN — Akredite Registrar Listesi
• ICANN Compliance — uyum şikayet portalı
• ICANN WHOIS Inaccuracy Complaint Form
• IANA Registrar ID listesi
• RFC 5731 — EPP Domain Mapping
• RFC 5733 — EPP Contact Mapping
• RFC 6650 — Abuse Reporting Format (ARF)
• BTK — Bilgi Teknolojileri ve İletişim Kurumu
• KVKK — Kişisel Verileri Koruma Kurumu
• WIPO Arbitration and Mediation Center
• Ticaret Bakanlığı — Tüketici Hakem Heyeti

İlgili Yazılar

• Domain Adı Nedir? WHOIS Sorgulama ve Alan Adı Tescili
• Domain Sorgulama Araçları: WHOIS, RDAP ve DNS Rehberi
• DNS Nedir? DNS Ayarları, Değiştirme
• .com.tr Uzantısı Alma Rehberi
• .av.tr Domain Alma Rehberi
• BTK Sorgulama Rehberi
• Hosting Türleri ve Seçim Rehberi
• SSL Sertifikası Nasıl Alınır