Domain Bayisi Nasıl Olunur Domain Bayisi Nasıl Olunur: Eksiksiz Rehber

Domain bayisi olmak, kendi markanız altında alan adı satmak — genellikle hosting, SSL sertifikası ve e-posta gibi ilgili hizmetlerle birlikte — anlamına gelir; bunu yaparken kendiniz ICANN akreditasyonuna sahip olmanıza gerek yoktur. Alan adlarını akredite bir registrar veya bir bayilik platformundan toptan fiyattan alır, üzerine kâr marjı koyar ve kendi web sitenizden, kendi markanızla, kendi fiyatlarınızla müşterilerinize satarsınız.

Bu iş modeli, internette tekrarlayan (recurring) gelir üzerine kurulmuş en erişilebilir işlerden biridir. Alan adları her yıl yenilenir; bu yüzden bugün kazandığınız bir müşteri, kötü bir hizmet veya beceriksiz bir transfer süreciyle kaybetmediğiniz sürece yıllarca fatura kestiğiniz bir müşteriye dönüşür. Ama bu, garantili bir pasif gelir yolu değildir. Domain başına marjlar incedir, rekabet gerçektir ve operasyonel detaylar — DNS, WHOIS, transferler, redemption süreleri — çoğu yeni bayinin tahmin ettiğinden çok daha fazla önem taşır.

Bu rehber; bir domain bayisinin gerçekte ne yaptığını, işin perde arkasında nasıl işlediğini, başlamanın maliyetini, doğru platformu nasıl seçeceğinizi ve gerçek hataların nerede yapıldığını adım adım anlatır. Hosting firmaları, ajanslar, freelancer’lar ve domain bayiliğinin işlerine uyup uymadığını değerlendiren girişimciler için yazılmıştır — ve uyuyorsa, bunu doğru şekilde nasıl yapacağınızı gösterir.

Domain Bayisi Nedir?

Domain bayisi, bir partner registrar’ın altyapısını ve ICANN akreditasyonunu kullanarak son kullanıcılara alan adı kaydı, transferi ve yenilemesi satan işletme veya kişidir. Bayinin doğrudan ICANN tarafından akredite edilmesine gerek yoktur. Bunun yerine, bu akreditasyona zaten sahip bir şirketle — bazen “ana registrar” veya “backend registrar” olarak adlandırılan — bir bayilik anlaşması altında çalışır.

Pratikte bu, size bir kontrol paneline veya API’ye, toptan fiyat listesine ve müşterileriniz adına domain kaydetme, yenileme ve transfer etme yetkisine erişim sağlar demektir. Müşterileriniz sizin markanızı, sizin faturalarınızı ve sizin desteğinizi görür — backend registrar onlar için görünmezdir.

Domain Bayiliği Gerçekte Nasıl Çalışır?

Mekanizma çoğu yeni başlayanın sandığından daha basittir, ama anlaşılması gereken bir ilişkiler zinciri vardır:

• ICANN, registrar’ları akredite eder ve domainlerin nasıl kaydedileceği, transfer edileceği ve yenileneceğine dair temel kuralları belirler.
• Registry’ler, belirli üst düzey alan adlarını (TLD) işletir — örneğin Verisign .com ve .net’i işletirken, ülke kodlu registry’ler kendi ccTLD’lerini (.de, .tr gibi) yönetir.
• Registrar’lar, ICANN tarafından (ve gerektiğinde bireysel ccTLD registry’leri tarafından) domainleri doğrudan halka ve bayilere satmak üzere akredite edilir.
• Bayiler — yani siz — registrar’ın toptan fiyat listesinden alır, perakende olarak satarsınız; kendi akreditasyonunuza ihtiyacınız yoktur.

Bir müşteri sitenizden domain kaydettiğinde, sipariş backend registrar’ın sistemine iletilir; ancak domain, WHOIS/kayıt verilerinde müşteri (veya modelinize bağlı olarak işletmeniz) adına kaydedilir. Ödemeyi siz tahsil edersiniz, registrar toptan ücretini alır, aradaki fark sizin marjınızdır.

İsteğin akışı en yalın haliyle şöyledir:
Müşteri
   │  vitrininizde bir domain arar ve satın alır
   ▼
Web Siteniz / Ödeme Ekranı
   │  sipariş API veya panel üzerinden registrar'a iletilir
   ▼
Bayi API'si (REST veya SOAP)
   │  Reseller ID + API Key ile kimlik doğrulanır
   ▼
Backend Registrar
   │  registrar kaydı registry'e iletir
   ▼
Registry (örn. .com için Verisign)
   │  domain oluşturulur, WHOIS/RDAP kaydı yayınlanır
   ▼
Onay
   API çağrınıza döner, ardından müşterinize e-postayla iletilir

Bayilik programlarının başlaması bu kadar erişilebilir görünmesinin nedeni de budur: registry seviyesinde bir altyapı kurmuyorsunuz. Başka birinin zaten işlettiği altyapının üzerine bir vitrin, bir faturalama sistemi ve bir destek süreci inşa ediyorsunuz. Bir registrar’ın API’sini gerçek müşteri hacmine geçmeden önce değerlendiriyorsanız, arama → kayıt → onay akışının tamamını önce bir sandbox ortamında denemek, bir müşteriye ulaşmadan entegrasyon sorunlarını yakalamanın en hızlı yoludur.

Registrar mı, Registry mi, Bayi mi?

Bu üç terim sürekli birbirine karıştırılır ve bu karışıklık gerçek sorunlara yol açar — örneğin bayilerin TLD politikası üzerinde doğrudan söz sahibi olduklarını sanmaları veya müşterilere yalnızca bir registry’nin yapabileceği bir şeyi vaat etmeleri gibi.

Bayinin ilişkisi registry ile değil, registrar iledir. Registry düzeyinde bir politika değiştiğinde — örneğin bir ccTLD için WHOIS gizliliğine dair yeni bir kural — bu değişiklik registrar üzerinden size ulaşır, siz de müşterilerinize aktarırsınız.

Kimler Domain Bayisi Olmalı?

Domain bayiliği, zaten domaine ihtiyaç duyan müşterilerle ilişkisi olan veya onlara ulaşacak bir kanalı bulunan işletmeler için mantıklıdır.

• Hosting firmaları — müşteriler hosting’den önce domaine ihtiyaç duyar; ikisini birlikte sunmak satışı hızlandırır.
• Dijital ajanslar ve web tasarımcılar — zaten müşterileriniz için domain kaydediyorsunuz; bayilik bunu bir maliyetten bir marja çevirir.
• Freelancer’lar ve BT danışmanları — proje işini tamamlayan küçük ama istikrarlı bir gelir kaynağı.
• SaaS kurucuları — özellikle ürününüz web sitesi, marka veya çevrimiçi varlıkla ilgiliyse.
• İSS’ler ve mevcut registrar’lar — komşu TLD’lere veya pazarlara genişleme.
• Geliştiriciler ve API entegratörleri — mevcut bir ürüne domain arama, kayıt veya yönetim özellikleri ekleme.
• White-label platform kuran girişimler — bayilik, tamamen domain odaklı bir ürünün temelini oluşturur.

Bunlardan hiçbiri size uymuyorsa — mevcut bir kitleniz yoksa ve bir tane oluşturma planınız da yoksa — başka bir ürünü çapa olarak kullanmadan yalnızca domain bayiliğiyle bir iş büyütmek, dışarıdan göründüğünden daha zordur.

Bayi Olmalı mısınız? Hızlı Karar Ağacı

Bu rehberi okuyan herkesin bir bayilik işi kurması gerekmiyor. En yaygın başlangıç noktalarını kapsayan basit bir karar yolu:

Zaten müşterilerinize hosting, web tasarım veya BT hizmeti satıyor musunuz?
   │
   ├─ EVET → Müşteri domainleri için bugün perakende fiyat mı ödüyorsunuz?
   │           │
   │           ├─ EVET → Bayi olun. Müşteriler zaten sizde;
   │           │         bayilik bir maliyet kalemini
   │           │         kâr marjına çevirir.
   │           │
   │           └─ HAYIR → Muhtemelen zaten gayriresmi şekilde
   │                      bayilik yapıyorsunuz. Gerçek bir bayi
   │                      hesabı ve otomatik yenilemelerle
   │                      bunu resmileştirin.
   │
   └─ HAYIR → Domainin doğal bir ek satış olacağı bir kitleniz
             veya ajans müşteriniz var mı?
                │
                ├─ EVET → Bayilik işe yarayabilir, ama destek ve
                │         müşteri kazanımı için gerçek zaman
                │         ayırmayı planlayın.
                │
                └─ HAYIR → Bir affiliate (komisyon) programı —
                          operasyonel yük olmadan yönlendirme
                          başına kazanç — genelde daha düşük
                          riskli bir başlangıç noktasıdır.

Domain Bayiliği İş Modelleri

Bu işi yürütmenin tek bir yolu yoktur. Birkaç yaygın kalıp:

• Hosting ile paketlenmiş. Domain giriş noktasıdır; hosting, e-posta ve diğer hizmetler daha yüksek yaşam boyu değeri taşır.
• Salt domain bayiliği. Tamamen domain satışına odaklanan bir vitrin; genellikle fiyat, TLD çeşitliliği veya bir nişle rekabet eder (örneğin sektöre özel uzantılar).
• Ajans üzerinden marjlı geçiş. Ajanslar, proje kapsamında müşteri domainlerini kaydeder ve mütevazı bir yıllık yönetim ücreti keser.
• API odaklı, ürüne gömülü bayilik. Bir SaaS veya platform, domain kaydını kendi ürün akışına entegre eder — bir web sitesi oluşturucunun kullanıcıların uygulamadan çıkmadan domain satın almasına izin vermesi yaygın bir örnektir.
• White-label bayi-üstü-bayi. Bazı işletmeler, bir bayilik platformuna erişimi yeniden satar; kendi marj ve markalarını mevcut bir bayilik programının üzerine katmanlar. Buna genellikle “alt bayilik (sub-reseller)” denir ve çoğu modern bayilik platformu çok katmanlı alt bayi hiyerarşilerini doğal olarak destekler; yani kendi bayileriniz hesabınızın altında markalı panellerle çalışabilir.

Her modelin farklı bir maliyet yapısı ve farklı bir büyüme tavanı vardır; bu yüzden platform seçmeden önce gerçekte hangisini kurduğunuza erken karar vermek işe yarar.

Gerçek Senaryolar: Beş İşletme, Beş Yol

Soyut tavsiyeler somut bir referans noktasıyla daha kolay uygulanır. Bayilik kararının beş yaygın işletme türünde tipik olarak nasıl işlediği:

Web tasarım ajansı. Ayda 15-20 müşteri domaini kaydeden ve bunu daha önce salt bir maliyet olarak gören bir ajans, bayi olur ve küçük bir yıllık domain yönetim ücretiyle birlikte mütevazı bir marj uygulamaya başlar. Bu değişiklik yeni bir satış çabası gerektirmez — ajansın zaten yaptığı işi paraya çevirir.

Hosting firması. Kendi domain satışı olmayan bir hosting sağlayıcısı, “tek ödeme ekranında domain + hosting” sunan rakiplere önemli miktarda kayıt kaybeder. API veya bir WHMCS modülü üzerinden bayilik entegrasyonu eklemek bu boşluğu kapatır ve satın alma niyetinin en yüksek olduğu anda — satış noktasında — ortalama sipariş değerini artırır.

Bölgesel İSS. Mevcut geniş bant müşteri tabanına sahip bir İSS, domain ve hosting yeniden satışını düşük maliyetli, yüksek güvenli bir ek satış olarak ekler — müşteriler zaten bir faturalama ilişkisine sahip olduğundan, paketlenmiş bir domain-artı-hosting teklifindeki dönüşüm oranları soğuk pazardan çok daha yüksek seyreder.

SaaS kurucusu (web sitesi oluşturucu veya uygulama platformu). Bir SaaS ürünü kullanıcıların özel domain bağlamasına izin verir. Domain arama ve kaydını doğrudan onboarding sürecine — kullanıcıları üçüncü taraf bir registrar’a yönlendirmek yerine bir REST API ile — gömmek, tüm kayıt akışını ürünün içinde tutar ve yaygın bir terk noktasını ortadan kaldırır.

Bağımsız web tasarımcı / freelancer. Yılda beş-on müşteri sitesi yöneten bir freelancer, domain kaydı ve yenileme yönetimini kalıcı bir hizmet olarak ekler; tek seferlik proje ücretini her müşteriyle gerçekten tekrarlayan küçük bir ilişkiye dönüştürür.

Kâr Marjları ve Gerçekçi Gelir Senaryoları

Domain marjları hosting veya SaaS’a kıyasla incedir. Toptan bir .com domaini bir bayiye yılda genellikle 8-11 dolar arasında mal olur; .com için perakende fiyatlandırma ise pazara ve marka konumlandırmasına bağlı olarak genellikle 10-20 dolar arasında seyreder. Bu, ödeme işlem ücretleri ve destek maliyetleri düşülmeden önce domain başına yılda kabaca 2-10 dolarlık bir marj bırakır.

Kârlılığı gerçekte belirleyen rakam, domain başına marj değil — yenileme oranıdır. Yüksek kayıp (churn) yaşayan bir domain işi yerinde saymak için koşar; güçlü yenileme oranına sahip bir işletme ise yıldan yıla katlanarak büyür, çünkü o müşteriyi kazanma maliyeti zaten birinci yılda ödenmiştir. Destek kalitesinin ve transfer sürtünmesinden kaçınmanın fiyatlandırma kadar önemli olmasının sebebi budur.

Premium domain satışları, ccTLD uzmanlaşması ve paketlenmiş hizmetler (SSL, e-posta, hosting), çoğu kârlı bayilik işinin asıl para kazandığı yerdir — ince marjlı düz .com yeniden satışı tek başına bir işi nadiren taşır. Birçok bayilik programı ayrıca hacme dayalı toptan kademeler sunar; kayıt hacminiz veya hesap bakiyeniz büyüdükçe fiyatlandırma otomatik olarak iyileşir — bu, uzun vadeli herhangi bir marj projeksiyonunda hesaba katılması gereken bir faktördür.

Başlangıç Maliyetleri

Çoğu çevrimiçi işe kıyasla giriş bariyeri gerçekten düşüktür. Planlanması zor olan maliyet zamandır: destek süreçleri kurmak, DNS ve transfer mekaniğini öğrenmek ve fiyatlandırmayı doğru yapmak, hesabı kurmaktan daha uzun sürer.

Doğru Bayilik Platformunu Seçmek

Seçtiğiniz platform, aşağı akışta neredeyse her şeyi belirler — marjlarınızı, otomasyon seçeneklerinizi ve müşterilerinizin yaşadığı sürtünmeyi. Kayıt olmadan önce değerlendirilmesi gereken birkaç şey:

• TLD kapsamı. İlgili ccTLD’ler ve yeni gTLD’ler dahil, müşterilerinizin gerçekten istediği uzantıları destekliyor mu? 800 veya daha fazla uzantı sunan programlar, ikinci bir bayilik hesabına gerek kalmadan niş ve uluslararası müşterilere hizmet verme alanı sağlar.
• Toptan fiyatlandırma ve hacim indirimleri. Fiyatlar şeffaf mı, hacminiz büyüdükçe iyileşiyor mu? Kademeli programlar (genellikle Standart, Premium, Platinum ve VIP tarzı seviyeler şeklinde yapılandırılır) bakiyeniz veya kayıt hacminiz arttıkça büyümeyi otomatik olarak ödüllendirir.
• API kalitesi ve dokümantasyon. Herhangi bir şeyi otomatikleştirmeyi planlıyorsanız bu, kontrol panelinden daha önemlidir. Hem REST hem SOAP desteğine özellikle bakın; REST modern, dile bağımsız yapılara uyarken SOAP hâlâ eski kurumsal faturalama sistemlerinde yaygındır.
• WHMCS veya faturalama sistemi uyumluluğu. WHMCS, WiseCP, HostBill, Blesta, ClientExec, FOSSBilling veya Upmind için mevcut, bakımı yapılan bir entegrasyon var mı, yoksa sıfırdan mı geliştirmeniz gerekecek?
• Destek yanıt hızı. Bir domain transferi gece 23:00’te takıldığında kimi arayacaksınız ve ne kadar hızlı yanıt alacaksınız? Bilet, telefon ve canlı sohbet üzerinden gerçek 7/24 kapsama evrensel değildir — varsaymak yerine doğrulayın.
• Uyumluluk ve ICANN politika yönetimi. Platform, politika değişikliklerini (WHOIS/RDAP, transfer kuralları, registrar kilidi gereksinimleri, iletişim doğrulaması) takip ediyor mu, yoksa bunu manuel olarak siz mi izlemek zorunda kalacaksınız?

Alt bayilik / white-label derinliği. Kendi müşterilerinizin sizin markanız altında yeniden satış yapmasına izin vermeyi planlıyorsanız, platformun yalnızca tek katmanlı bir white-label panel değil, çok katmanlı alt bayi hiyerarşilerini desteklediğini doğrulayın.

Bu listeyi bir kontrol listesine dönüştürmek, değerlendirdiğiniz herhangi bir platformu puanlamayı kolaylaştırır:

Bu tam olarak DomainNameAPI’nin domain bayilik programına bakarken değerlendirilmesi gereken kriter setidir: 40.000’den fazla bayi, 200’den fazla ülkede tam olarak bu kontrol listesi üzerinden çalışıyor — bu da, müşteri hacmini herhangi bir sağlayıcıya emanet etmeden önce makul bir kıyas noktasıdır. DomainNameAPI’nin Türkçe teknik destek sunması da Türkiye pazarındaki bayiler için ayrıca değerlendirilmeye değer bir ayrıntıdır.

API mi, Kontrol Paneli mi?

Büyüyen bayilik işlerinin çoğu er ya da geç kontrol panelinden API odaklı otomasyona geçer; çünkü manuel kayıt ve yenileme yönetimi birkaç yüz domainden sonra yönetilemez hale gelir. Gerçek hacim bekliyorsanız, göç etmek zorunda kalmadan önce erkenden Domain API Entegrasyonu seçeneklerini değerlendirmek işe yarar — iki yaklaşım birlikte de kullanılabilir: hızlı manuel işler için panel, otomatik sipariş akışı için API.

White-Label Çözümler

White-label bir bayilik kurulumu, backend registrar’ın adının müşterinize hiçbir yerde görünmemesi demektir — ne vitrinde, ne onay e-postalarında, ne de gizlilik ayarlarının izin verdiği durumlarda WHOIS iletişim bilgilerinde. Bu, göründüğünden daha fazla önem taşır: müşteriler kayıt oldukları markaya güvenir ve görünür herhangi bir uyumsuzluk (bir yenileme e-postasında tanımadıkları bir şirket adı gibi) destek biletleri üretir ve güveni zedeler.

Bir platforma bağlanmadan önce, white-label’ın ne kadar kapsamlı uygulandığını kontrol edin — bazı platformlar paneli white-label yapar ama otomatik e-postaları yapmaz; bu yaygın ve önlenebilir bir hatadır. Alt bayi hiyerarşilerinin desteklenip desteklenmediğini de kontrol edin; bu, aynı white-label markalamayı yalnızca doğrudan müşterilerinize değil, tedarik ettiğiniz işletmelere kadar uzatmanızı sağlar. Bu, pazarlama sayfasına güvenmek yerine test etmeye değer alanlardan biridir — bir test domaini kaydedin, bir yenileme hatırlatması tetikleyin ve gerçek hacme geçmeden önce müşterinizin alacağı e-postayı okuyun.

Domain Bayilik API’si Ayrıntılı Anlatım

Anlamlı bir hacim planlayan her bayi için, platformun en önemli parçası API’dir — panelin görsel tasarımından, pazarlama sayfasından daha önemlidir. Yetkin bir domain bayilik API’sinin genel olarak şunları kapsaması gerekir:

• REST API. Standart HTTP metotlarını (GET, POST, PUT, DELETE) kullanan, genellikle JSON veya XML döndüren, dile bağımsız ve durumsuz bir arayüz. Python, Node.js, Ruby, Go veya herhangi bir modern yığında özel uygulamalar için doğru seçimdir ve mikroservis mimarilerine iyi uyar.
• SOAP API. Eski kurumsal faturalama ve provizyon sistemlerinde hâlâ yaygındır; hem REST hem SOAP sunan bir platform, eski yığına sahip müşterileri yeniden yazıma zorlamaktan kaçınır.
• SDK’lar. Yaygın diller için hazır kütüphaneler — hosting ve bayilik alanında en çok kullanılanlar .NET ve PHP SDK’larıdır — ham HTTP çağrıları sıfırdan yazmaya kıyasla ilk entegrasyon süresini önemli ölçüde kısaltır.
• Toplu işlemler. Yüzlerce veya binlerce domain yönettiğinizde toplu domain arama, toplu kayıt ve toplu TLD/fiyat içe aktarma önem kazanır; bunları tek tek işlemek ölçeklenmez.
• DNS API. A, AAAA, CNAME, MX ve TXT kayıtlarının, ayrıca nameserver değişikliklerinin programatik yönetimi; DNS güncellemelerinin ayrı bir panele gitmeden kendi panelinizden tetiklenebilmesini sağlar.
• Transfer API. Gelen ve giden transferleri başlatma, EPP/auth kodlarını alma ve transfer kilitlerini programatik olarak yönetme.
• Premium domain sorgulama. Aramada registry-premium fiyatlandırmayı tanımlayan özel bir uç nokta veya bayrak; vitrininizin, aslında premium fiyattan faturalanacak bir domain için standart fiyat göstermesini engeller.
• Sandbox / OT&E ortamı. Gerçek müşteri verisine veya canlı faturalamaya dokunmadan üretimi taklit eden, bazen OT&E (Operational Test & Evaluation) olarak da adlandırılan tamamen ayrı bir test ortamı. Domain Name API Test Platformu, tam olarak bu tür bir kurulumu belgeler: canlı ortamdan ayrı sandbox kimlik bilgileri ve uç noktalar.
• Hızlı Yanıt: Herhangi bir modern dilde yeni, özel bir uygulama geliştiriyorsanız REST’i tercih edin; SOAP’ı yalnızca bunu zaten bekleyen mevcut bir eski faturalama sistemine entegre oluyorsanız seçin. Her ikisini de sunan çoğu platform, işleve göre karıştırıp eşleştirmenize izin verir.

Yeni başlayanların hafife aldığı bir detay: toplu API kullanımı hız limitlerine (rate limit) takılır. Entegrasyona değer herhangi bir registrar, kısıtlama kurallarını ve HTTP 429 (“çok fazla istek”) davranışını, önerilen geri çekilme (backoff) stratejileriyle birlikte belgeler — bu dokümantasyon yoksa, limitleri en yoğun haftanızda, üretimde, zor yoldan öğreneceğinizi varsayın.

Gerçek bir entegrasyon senaryosu. Bir SaaS web sitesi oluşturucusu, kullanıcıların onboarding sırasında uygulamadan çıkmadan domain satın almasını istiyor. Pratikte bu akış, tek bir “Bu domaini satın al” düğmesinin arkasına zincirlenmiş üç API çağrısıdır: arama uç noktasına karşı bir uygunluk kontrolü, ödeme tamamlandığında bir kayıt çağrısı ve yeni domaini platformun hosting’ine yönlendiren bir DNS API çağrısı. Bu zincirin tamamını önce bir sandbox/OT&E ortamında test etmek — Domain Name API Test Platformu’nun belgelediği şekilde — alınmış bir domain veya reddedilen bir ödeme gibi uç durumları, üretim faturalamasına ulaşmadan yakalar.

Ekosistemin her katmanının bayi olarak sizin göreceli konumunuz şöyledir:
ICANN
  │  registrar'ları akredite eder, küresel politikayı belirler (RAA, transfer politikası, ERRP)
  ▼
Registry'ler  (.com için Verisign, .de için DENIC, ...)
  │  her TLD için yetkili veritabanını işletir
  ▼
Akredite Registrar  (bayilik hesabınızın arkasındaki backend)
  │  RAA'ya sahiptir, ICANN ücretlerini öder, her registry'e bağlanır
  ▼
Bayi  (siz)
  │  toptan alır, perakende satar, müşteri ilişkisinin sahibidir
  ▼
Son Müşteri
   kaydeder, yeniler, transfer eder — genellikle bu çizginin üstündeki hiçbir şeyi görmez

WHMCS ve Faturalama Otomasyonu

WHMCS, hosting firmaları ve domain bayileri arasında en yaygın kullanılan faturalama ve otomasyon platformudur; çünkü zaten provizyon, faturalama ve domain yaşam döngüsü yönetimi için modüllere sahiptir. Doğru yapılandırılmış bir WHMCS entegrasyonu tipik olarak şunları yönetir:

• Otomatik kayıt. Ödemesi tamamlanan bir sipariş, hiçbir manuel adım olmadan registrar modülü üzerinden otomatik olarak domain kaydını tetikler.
• Otomatik yenileme ve otomatik transfer. Yenileme ve transfer istekleri, personelin bitiş tarihlerini manuel takip etmesini gerektirmeden faturalama durumuna göre tetiklenir.
• Domain Sync ve TLD Sync. Domain Sync, WHMCS’teki bitiş tarihlerini registry’nin gerçek kayıtlarıyla hizalı tutar — burada bir uyumsuzluk, domainlerin beklenmedik şekilde düşmesinin en yaygın nedenlerinden biridir. TLD Sync, registrar’ınızın toptan fiyatlandırmasını WHMCS fiyat tablonuzla toplu olarak karşılaştırır; tedarikçi fiyat değişikliği sonrası marjınızın eridiği uzantıları işaretler.
• Lookup provider yapılandırması. Registrar’ınızı domain uygunluk sorgulama sağlayıcısı olarak ayarlamak, müşterilere önbelleğe alınmış veya üçüncü taraf bir kaynak yerine gerçek zamanlı arama sonuçları sunar.
• Cron tabanlı otomasyon. WHMCS’in cron işi, ilişkinin zamanlanmış tarafını yönetir — yenileme hatırlatmaları, otomatik yenileme faturalama çalıştırmaları ve durum senkronizasyonları — böylece hiçbir şey birinin bir düğmeye basmayı hatırlamasına bağlı kalmaz.
• Dolandırıcılık kontrolleri. Domain siparişleri, ödeme dolandırıcılığı için bilinen bir hedeftir; çünkü kaydedilen bir domain hızla yeniden satılabilir veya başka amaçla kullanılabilir. WHMCS’in dolandırıcılık modüllerini ve manuel inceleme kuyruklarını varsayılan ayarlarda bırakmak yerine yapılandırmaya değer.
• Bilet ve destek entegrasyonu. Yenileme başarısızlıkları, transfer sorunları ve WHOIS güncelleme istekleri, müşterinin geçmişini tek bir yerde tutarak faturalamayla aynı destek sistemi üzerinden akar.
• Modül günlükleme. WHMCS ile registrar arasındaki her istek ve yanıtı kaydeden bir hata ayıklama günlükleme modu, belirli bir sipariş başarısız olduğunda ve API’nin gerçekte ne döndürdüğünü tahmin etmek yerine görmeniz gerektiğinde paha biçilmezdir.

Bakımı yapılan bir Domain Reseller WHMCS Entegrasyonu, genellikle bir hosting firmasını en hızlı şekilde pazara ulaştırır; çünkü domain provizyonu, yenileme hatırlatmaları ve iptal yönetimi zaten kurduğunuz faturalamaya bağlanır — TLD Sync’i düzenli bir programda (aylık yaygındır) çalıştırmak, toptan fiyatlar değiştikçe yenileme yılı marjını korumanın en basit alışkanlıklarından biridir.

Pratik İpucu: Bu işteki en yaygın WHMCS destek bileti, WHMCS’te “Aktif” görünen ama registry’de aslında süresi dolmuş veya askıya alınmış bir domaindir. Vakaların yüzde doksanında neden, Domain Sync’in kapalı veya yanlış yapılandırılmış olmasıdır. Bunu bir faturalama hatası sanmadan önce kontrol edin.

API mi, WHMCS Modülü mü?

Fiyatlandırma Stratejisi ve Toptan Kademeler

Üç genel perakende fiyatlandırma yaklaşımı vardır:

• Maliyet-artı. Toptan fiyata sabit bir marj ekleyin. Basit, öngörülebilir, müşteriye açıklaması kolay.
• Pazara göre. Rakiplere yakın fiyatlandırın, farkı hizmet, paketleme veya niş odakla yaratın.
• Yeni müşteride zarar, yenileme ve ek satışlarda kâr. Hosting paketlerinde yaygındır — domain ilk yıl ucuz veya ücretsizdir, işletme hosting, yenileme ve ek satışlardan kazanır.

Toptan tarafta, kurulu bayilik programlarının çoğu kendi fiyatlandırmasını da bayilere kademeli sunar — genellikle Standart, Premium, Platinum ve VIP eşdeğeri seviyeler olarak yapılandırılır — burada domain başına maliyetiniz, hesap bakiyeniz veya kayıt hacminiz belirli eşikleri geçtikçe otomatik olarak iyileşir. Bazı programlar bunu yüksek hacimli bayiler için partner veya pazarlama fonu düzenlemeleriyle birleştirir; kayıt hacmi ölçeklendikçe daha iyi birim ekonomisiyle birlikte ortak pazarlama desteği sunar.

Hangi perakende yaklaşımını seçerseniz seçin, yenileme fiyatlandırması konusunda şeffaf olun. İlk yıl indirimleri sunup ardından açıklanmayan sert yenileme artışlarıyla gelen bir yem-değiştir taktiği, chargeback, olumsuz yorum ve destek yükü üretmenin en hızlı yollarından biridir — ve müşterilerin giderek daha fazla tanıyıp kaçındığı bir kalıptır.

Müşteri Desteği Beklentileri

Domain sorunları müşteri için nadiren düşük risklidir. Süresi dolan bir domain, bir işletmenin e-postasını ve web sitesini aynı anda çökertebilir. Planlamanız gereken destek sorumlulukları:

• Müşterilere gelen ve giden domain transferlerinde, EPP/auth kodları ve kilit açma dahil, yardımcı olmak.
• Yenileme zamanlamasını açıkça, son tarihten önce anlatmak, sonra değil. 60, 30, 14 ve 7 gün öncesinde gönderilen aşamalı bir hatırlatma dizisi, tek bir bildirime kıyasla kazara yenilenmeme oranını anlamlı şekilde azaltır.
• WHOIS/RDAP iletişim düzeltmelerini ve ICANN politikasının yeni kayıtlar ile kayıt sahibi değişikliklerinde zorunlu tuttuğu iletişim doğrulama e-postalarını yönetmek.
• Güncel olmayan iletişim bilgileri nedeniyle bir domain askıya alındığında hızlı yanıt vermek — bu varsayımsal değil, gerçek bir ICANN kaynaklı risktir.
• Bir domain süresi dolup redemption sürecine girdiğinde veya daha kötüsü serbest bırakıldığında, neyin kurtarılabilir neyin kurtarılamaz olduğu konusunda dürüst olmak.

Yanıt hızı ve netlik, çoğu yeni bayinin beklediğinden daha önemlidir. Bu, tek bir kötü yönetilen yenilemenin bir müşteriyi kalıcı olarak kaybettirebileceği bir iştir. Destek hacminiz bunu haklı çıkaracak kadar büyükse, daha iyi backend registrar’ların kendilerinin sunduğu bilet, telefon ve canlı sohbet üzerinden gerçek 7/24 kapsamaya doğru inşa etmeye değer — çünkü domain acil durumları mesai saatlerini beklemez.

Hatırlatma sıklığının kendisi, tek bir e-posta değil bir huni olarak ele alınmaya değerdir:

Yenileme bildirim süreci en yalın haliyle şöyledir:

60 gün kala
   │  ilk bildirim gönderilir; bilgilendirici bir ton kullanılır, aciliyet oluşturulmaz
   ▼
30 gün kala
   │  ikinci bildirim gönderilir; yenileme fiyatı açık ve net şekilde gösterilir
   ▼
14 gün kala
   │  aciliyet artırılır; “şimdi harekete geçin” mesajı öne çıkarılır
   ▼
7 gün kala
   │  redemption ücretleri devreye girmeden önce son uyarı gönderilir
   ▼
0. gün (süre dolumu)
   │  domainin kayıt süresi sona erer ve alan adı yenileme grace dönemine girer (ERRP)

DNS Yönetimi Temelleri

• Çoğu bayilik platformu temel DNS barındırmayı paket olarak sunar; müşterilerin A, CNAME, MX ve TXT kayıtlarını düzenleyerek domainlerini bir web sitesine, e-posta hizmetine veya üçüncü taraf bir hosta yönlendirmesine izin verir. Bir bayi olarak müşterilerinize düzenli olarak şu konularda yardımcı olursunuz:
• Bir domaini yeni bir hosta yönlendirmek (A/AAAA kayıtlarını veya nameserver’ları güncellemek).
• E-posta teslimatını kurmak (MX ve SPF/DKIM TXT kayıtları).
• Üçüncü taraf hizmetler için domain sahipliğini doğrulamak (TXT kayıt doğrulaması).
• Bir müşteri birden fazla domaini tek bir hedefte topladığında domain yönlendirmeleri (301/302) kurmak.
• Normal ve beklenen olmasına rağmen müşteriler tarafından sıklıkla “bir şeyler bozuk” olarak yanlış anlaşılan yayılma (propagation) gecikmelerini gidermek.

Domain bayiliği yapmak için DNS uzmanı olmanıza gerek yok, ancak yaygın kayıt türleri hakkında çalışan bir bilgi, ciddi miktarda destek zamanı kazandırır. Platformunuz DNS yönetimini API üzerinden sunuyorsa, aynı işlevselliği müşterileri ayrı bir üçüncü taraf panele göndermek yerine kendi müşteri panelinizde sunmak, bütün bir destek bileti kategorisini ortadan kaldırır.

Domain Transferleri Açıklaması

Bir domaini registrar’lar arasında transfer etmek, bu işteki en destek yoğun süreçlerden biridir; ilk müşterinize gerek duymadan önce mekanizmayı anlamaya değer:

Domain transfer süreci en yalın haliyle şöyledir:

1. Kaybeden Registrar
   │  domainin registrar kilidi kaldırılır
   ▼
2. EPP / Auth Kodu
   │  transfer kodu kaybeden registrar'dan alınır
   ▼
3. Kazanan Registrar
   │  EPP/auth kodu kullanılarak transfer işlemi başlatılır
   ▼
4. Transfer Onayı
   │  kaybeden registrar'ın transferi onaylamak veya reddetmek için yaklaşık 5 günü vardır
   │  süreç FOA ve ICANN transfer politikası kapsamında ilerler
   ▼
5. Transfer Tamamlanır
   │  işlem genellikle toplamda yaklaşık bir hafta içinde sonuçlanır

Domainler genellikle ilk kayıttan sonraki 60 gün içinde transfer edilemez ve bir transfer tamamlandıktan sonra başka bir transfer yapılabilmesi için genellikle 60 günlük bir kilit uygulanır — bu, ICANN Transfer Politikası’nın standart 60 günlük kilididir, platforma özel bir kural değildir. Sahiplik değişiklikleri registrar transferlerinden ayrı ele alınır: bir Change of Registrant (bazen bir Designated Agent üzerinden yürütülür), domaini mutlaka yeni bir registrar’a taşımadan yasal kontrolün kimde olduğunu günceller; ICANN’ın kuralları, değişiklik tamamlanmadan önce her iki taraf için de belirli onay adımları gerektirir.

Zaman çizelgesine döküldüğünde, tipik bir transfer şöyle görünür:

Yenilemeler ve Domain Yaşam Döngüsü

Domain yaşam döngüsü en yalın haliyle şöyledir:

 AKTİF
   │  kayıt dönemi iyi durumda
   ▼
 SÜRESİ DOLDU
   │  kayıt dönemi yenilenmeden sona erer
   ▼
 YENİLEME GRACE DÖNEMİ  (ERRP — genellikle 45 güne kadar)
   │  genellikle hâlâ normal fiyattan yenilenebilir
   ▼
 REDEMPTION GRACE DÖNEMİ  (RGP — genellikle yaklaşık 30 gün)
   │  domain askıya alınır; yalnızca daha yüksek bir ücretle kurtarılabilir
   ▼
 PENDING DELETE
   │  kısa son pencere, genellikle yaklaşık 5 gün
   ▼
 SERBEST BIRAKILDI
    domain yeniden kayda halka açık hale gelir

Bu akış, ICANN’ın Expired Registration Recovery Policy (ERRP) politikası ve registry düzeyindeki Redemption Grace Period (RGP) ile resmileştirilmiştir — ikisi de akredite registrar’lar genelinde standarttır, herhangi bir tek bayilik platformunun icadı değildir. Bir domain pending delete’e ulaştığında, o müşteri için etkin biçimde bitmiştir. Proaktif yenileme hatırlatmalarının — ve redemption ücretleri hakkında net iletişimin — bir bayilik işinin doğru yapabileceği en yüksek etkili şeylerden biri olmasının nedeni budur.

Süresi Dolan Domainler ve Redemption Süreci

Redemption ücretleri, silinmiş ama henüz serbest bırakılmamış durumdaki bir domaini kurtarmanın, registry’nin bir silme sürecini tersine çevirmesini gerektirmesinden kaynaklanır ve registry’ler bunun için ücret alır. Redemption ücretleri genellikle normal bir yenilemenin çok üzerinde seyreder — bazen yıllık kayıt ücretinin birkaç katı — bu yüzden müşteri beklentilerini bu yaşanmadan önce ayarlamaya değer, sonrasındaki panik anında değil.

Bazı bayiler, domainler serbest bırakılır bırakılmaz kaydetme üzerine kurulu ikincil bir gelir akışı — yaygın adıyla “drop catching” — inşa eder, ancak bu özel araçlar gerektirir ve çoğu işletme için standart bayilik operasyonlarının bir parçası değildir.

Premium Domainler

Premium domainler, registry’nin veya özel bir sahibin — genellikle uzunluk, akılda kalıcılık veya anahtar kelime değeri nedeniyle — standart toptan oranların üzerinde fiyatlandırdığı isimlerdir. Bir bayi olarak iki türle karşılaşırsınız:

• Registry premium domainler — ilk kayıtta mevcut, registry’nin kendisi tarafından bazen önemli ölçüde daha yüksek fiyatlandırılır. Güvenilir bir API, arama anında premium durumu ve premium yenileme fiyatını gösterir; böylece vitriniz asla premium bir isim için standart kademe fiyatı sunmaz.
• İkincil piyasa (aftermarket) premium domainler — zaten kayıtlı ve mevcut sahibi tarafından genellikle standart kayıt yerine bir pazar yeri üzerinden yeniden satışa sunulmuş domainler.

Yeni gTLD lansmanları da bilinmeye değer iki politika penceresi getirir: marka sahiplerine eşleşen isimleri kaydetmede ilk hakkı veren Sunrise dönemi ve Sunrise sonrası, kayıtlı bir markayla eşleşen bir ismin talep edildiğinde hem kayıt sahibini hem marka sahibini uyaran bir bildirim dönemi olan Trademark Claims. İkisi de ICANN’ın zorunlu tuttuğu marka koruma mekanizmalarıdır, bir registry’nin atlayabileceği isteğe bağlı ekstralar değildir.

Ülke Kodlu Uzantılar (ccTLD) ve Yeni gTLD’ler

Tüm TLD’ler aynı şekilde çalışmaz. ccTLD’ler (.de, .jp, .uk, .fr ve diğerleri) ülkeye özgü registry’ler tarafından işletilir ve genellikle yerel gereksinimler taşır — ülkeye bağlı olarak yerel varlık, belirli bir iletişim formu veya belge gibi. Türkiye’nin .tr ve .com.tr uzantıları iyi bir örnektir: kayıt ve transferler, standart ICANN politikasının üzerine kendi kurallarını uygulayan ulusal registry sistemi TRABIS üzerinden yürütülür — .tr destekleyen bir bayinin, genel bir ccTLD desteği değil, özellikle TRABIS uyumluluğu için kurulmuş bir platforma ihtiyacı vardır.

Yeni gTLD’ler (.app, .shop, .ai ve 2012’den bu yana tanıtılan yüzlerce diğeri) daha geniş bir registry operatörü yelpazesi tarafından işletilir ve bazen kendi kayıt politikalarını taşır — .app için zorunlu SSL veya yeni lansmanlar için yukarıda anlatılan Sunrise/Trademark Claims pencereleri gibi.

Bir ccTLD veya daha yeni bir gTLD’yi öne çıkarmadan önce, bayilik platformunuzun bunu gerçekten desteklediğini ve yerel kayıt gereksinimlerini anladığını doğrulayın — bu platformdan platforma önemli ölçüde değişir ve yaygın bir eksikliktir.

Güvenlik ve ICANN Uyumluluğu

Yalnızca registrar’ları değil, doğrudan bayileri de ilgilendiren birkaç uyumluluk alanı vardır:

• WHOIS/RDAP doğruluğu. Kayıt sahiplerinin iletişim bilgilerini doğru tutması zorunludur; yanlış veri domain askıya alınmasına yol açabilir. ICANN, yeni kayıtlarda ve kayıt sahibi değişikliklerinde iletişim doğrulama e-postaları gerektirir; bu doğrulama başarısız olursa registrar’ların harekete geçmesi zorunludur.
• WHOIS gizlilik koruması. Kayıt sahibi iletişim bilgilerini herkese açık WHOIS/RDAP sorgularından gizlemek artık premium bir ekstra değil, standart bir uygulamadır — örneğin DomainNameAPI desteklenen TLD’lerde bunu ücretsiz sunar; bu, sağlayıcılar arasında “gizlilik dahil” ifadesinin gerçekte ne anlama geldiğini karşılaştırırken bir referans noktası olarak kullanılmaya değer.
• RDAP. Registration Data Access Protocol, eski WHOIS sorgularının yapılandırılmış, makine tarafından okunabilir halefidir; mevcut registrar sistemlerinin çoğu geçiş süresince ikisini de destekler ve RDAP giderek registrar ve üçüncü taraf araçların varsayılan olarak sorguladığı protokol haline gelmektedir.
• Registrar kilidi. Çoğu platform bunu yetkisiz transferleri önlemek için otomatik uygular — platformunuzun uyguladığından ve müşterilerin kilidi açmanın ne anlama geldiğini anladığından emin olun.
• Registry kilidi. Standart bir registrar kilidinden daha güçlü, registry düzeyinde uygulanan ve kaldırmak için genellikle bant dışı bir doğrulama adımı gerektiren bir koruma — yüksek değerli veya yüksek riskli müşterilere (finans, e-ticaret, tanınmış markalar) ücretli bir ek hizmet olarak sunulmaya değer.
• DNSSEC. Domain Name System Security Extensions, DNS yanıtlarına kriptografik imzalama ekleyerek belirli spoofing ve önbellek zehirleme saldırılarına karşı koruma sağlar. Bayilik platformları, DNSSEC yapılandırmasını giderek standart DNS yönetimiyle aynı panel veya API üzerinden sunuyor.
• Bayilik hesabınızın kendisinde iki faktörlü kimlik doğrulama, çünkü hesap düzeyinde erişim yönettiğiniz her domaini kontrol eder.
• Avrupalı müşterilere hizmet veriyorsanız özellikle ilgili olan, WHOIS iletişim verisi etrafında veri gizliliği (GDPR ve benzeri bölgesel kurallar).
• Registrar kötüye kullanım (abuse) yönetimi. Registrar’ların kötüye kullanım raporlarına belirli süreler içinde yanıt vermesi zorunludur; backend sağlayıcınızın bunu nasıl ele aldığını anlayın, çünkü bu doğrudan müşterilerinizi etkiler ve düzenleyicilerin sıkılaştırdığı bir alandır (örneğin Avrupa’nın NIS2 direktifi daha katı doğrulama ve kötüye kullanım yönetimi yükümlülükleri getirir).

Bunların hiçbiri egzotik değildir, ama bunları atlamak yeni bayilerin askıya alınmış hesaplar veya kızgın müşterilerle karşılaşmasının en yaygın yollarından biridir.

Backend registrar’ınızın ICANN’a ne ödediğini bilmek de faydalıdır, çünkü bu maliyetler gördüğünüz her toptan fiyatın içine gizlidir — burada kıl payı marjlarla çalışan bir registrar’ın kötü bir çeyreği absorbe edecek alanı, sağlıklı hacme sahip birinden daha azdır:

2026’da Domain Sektörü: Takip Edilmesi Gereken Eğilimler

2026’nın geri kalanına girerken izlenmeye değer birkaç değişim var, çünkü bunlar müşterilerin ne istediğini ve platformların neyi desteklemesi gerektiğini değiştiriyor:

• Yapay zeka destekli domain arama ve marka adı üretimi. Müşteriler, ilk tercihleri alınmışken düz bir TLD varyasyonu listesi yerine, uygun ve markalanabilir alternatifler öneren bir arama kutusu bekliyor.
• Yapay zeka destekli WHOIS/RDAP sorguları. Kayıt verisi üzerinde doğal dil arayüzleri, teknik olmayan kullanıcılar için ham WHOIS çıktısının yerini almaya başlıyor.
• Varsayılan olarak RDAP, eski WHOIS giderek birincil sorgulama yöntemi değil bir yedek olarak görülüyor.
• DNSSEC benimsenmesi tırmanmaya devam ediyor, özellikle daha fazla registry ve hosting platformu bunu isteğe bağlı yerine varsayılan olarak etkinleştirdikçe.
• Registry kilidi ana akım bir teklife dönüşüyor, artık yalnızca kurumsal bir özellik değil — yüksek değerli domainlere yönelik hesap ele geçirme ve sosyal mühendislik saldırıları manşetlere çıkmaya devam ettikçe.
• Toplu API ve hız limiti olgunluğu. Bayilik operasyonları ölçeklendikçe, registrar’lar daha net kısıtlama ve geri çekilme dokümantasyonu yayınlıyor; çünkü belgelenmemiş hız limitleri başarısız toplu işlemlerin tekrarlayan bir nedeni.
• Domain portföy izleme ve sıfır dokunuş otomasyonu. Büyük bayiler, tek tek kayıtları manuel izlemek yerine, tüm portföy genelinde süresi dolan, askıya alınan veya risk altındaki domainler için otomatik uyarılar bekliyor.
• Yenileme oranı baskısı. Kısa, akılda kalıcı isimler kıtlaştıkça ve premium ikincil piyasa fiyatlandırması bu talebin daha fazlasını emdikçe, sektör genelinde yenileme oranları tarihsel zirvelerden geriledi — bu da elde tutma stratejisine geçmiş yıllara göre daha fazla ağırlık veriyor.

Bu eğilimlerin arkasındaki rakamlar, Verisign’ın 2026’nın ilk çeyreği için Domain Name Industry Brief raporundan:

Öne Çıkan Noktalar - RDAP, varsayılan sorgulama yöntemi haline geliyor; eski WHOIS giderek bir yedek konumunda. - Registry kilidi ve DNSSEC, yalnızca kurumsal seçenekten ana akım tekliflere doğru kayıyor. - Yeni gTLD’ler pazarın en hızlı büyüyen segmenti, ama yenileme oranları klasik TLD’lerin gerisinde kalıyor; bu da özellikle bu segment için elde tutma stratejisinin değerini artırıyor.

Yeni Bayilerin Sık Yaptığı Hatalar

• Yenileme yılı marjını hesaba katmadan düşük fiyatlandırma, ardından bir müşteri kaldığı anda para kaybetmek.
• Registrar kilidi ve transfer ayarlarını göz ardı etmek, domain hırsızlığına veya kazara yetkisiz transferlere yol açmak.
• WHOIS/RDAP iletişim doğruluğunu isteğe bağlı görmek, askıya alınma riski taşımak.
• Otomatik yenileme hatırlatması olmaması, önlenebilir müşteri kayıplarına ve redemption ücreti anlaşmazlıklarına yol açmak.
• Bir platformu yalnızca fiyata göre seçmek, API güvenilirliğini, destek yanıt hızını veya TLD kapsamını kontrol etmeden.
• Destek yükünü hafife almak. Domainler, çoğu dijital üründen gelir dolar başına daha fazla destek bileti üretir.
• Bayilik sözleşmesinin ince yazısını okumamak, minimum bakiyeler, hareketsizlik ücretleri veya fesih koşulları konusunda.
• Toplu API hız limitlerini görmezden gelmek, büyük bir toplu işlem üretimde yarıda başarısız olana kadar.

Bu hataların çoğu, entegrasyon yapmadan önce platformun kendi dokümantasyonunu okumakla önlenebilir — Domain API Entegrasyonu referansı bu dokümantasyonun neyi kapsaması gerektiğine dair makul bir örnektir.

Öne Çıkan Noktalar - Yenileme yılı marjını hesaba katmadan düşük fiyatlandırma, en yaygın finansal hatadır. - Otomatik yenileme hatırlatmaları, en yüksek etkili, en ucuz önlemdir. - Bir platformu yalnızca fiyata göre seçmek, genellikle daha sonra API veya destek sorunları olarak geri döner.

Ne Zaman Domain Bayisi Olunmamalı?

Domain bayiliği herkes için doğru adım değildir:

• Mevcut bir müşteri ilişkiniz veya bir tane oluşturacak kanalınız yoksa, düşük marjlı bir ürün için sıfırdan müşteri kazanmak gerçekten zordur.
• Pasif, elinizi değdirmeden işleyen bir gelir akışı arıyorsanız — özellikle transferler ve yenilemeler etrafındaki destek yükü gerçek ve süreklidir.
• İşletmeniz zaten doğal olarak domainlere dokunmuyorsa (hosting yok, web tasarımı yok, web sitesine bağlı bir SaaS ürünü yok), müşterilere sunduğunuz değer önerisi daha zayıftır.
• Uyumluluk ve güvenlik sorumluluklarını, temel düzeyde bile olsa, üstlenmeye hazır değilseniz.

Bu durumların çoğunda, mevcut bir registrar için affiliate olmak — operasyonel sorumluluk olmadan komisyon kazanmak — tam bayilikten daha düşük riskli bir başlangıç noktasıdır.

Doğru Bayilik Sağlayıcısını Nasıl Seçersiniz?

Kayıt olmadan önce sorulacak sorular:

• Beklediğim hacimde gerçek toptan fiyat nedir, gizli ücretler dahil mi?
• Hangi TLD’ler destekleniyor ve müşterilerimin ihtiyaç duyduğu uzantılar dahil mi? (800+ uzantı makul bir taban çizgisidir.)
• Minimum bir bakiye var mı, altına düşersem ne olur — yoksa platform minimum/maksimum depozito gereksinimini tamamen kaldırıyor mu?
• API ne kadar olgun ve canlıya geçmeden önce test edebileceğim bir sandbox/OT&E ortamı dahil gerçek bir dokümantasyon var mı?
• WHMCS, WiseCP, HostBill, Blesta, ClientExec veya FOSSBilling için bakımı yapılan bir modül var mı, yoksa özel geliştirme mi gerekecek?
• Destek SLA’sı nedir ve acil transfer sorunları için 7/24 bir kanal — bilet, telefon ve canlı sohbet — var mı?
• White-label nasıl uygulanıyor — yalnızca panel mi, e-postalar ve WHOIS iletişim bilgileri de mi? Bayilere yeniden satış yapmayı planlıyorsam alt bayi hiyerarşilerine kadar uzanıyor mu?
• Süresi dolan domainler için redemption ücret yapısı nedir?
• Sözleşme kilitlenmesi var mı, yoksa uzun vadeli bir taahhüt olmadan öde-kullan mı?
• Daha yüksek hacim kademelerinde fiyatlandırma otomatik olarak iyileşiyor mu ve büyüyen bayiler için partner veya pazarlama fonu programları var mı?
• Gerçek hacme geçmeden önce bir platformu elle değerlendirmenin hızlı bir yolu, Domain Name API Test Platformu üzerinden geçmektir; burada üretimden ayrı bir sandbox ortamı ve kimlik bilgileriyle API davranışını ve panel kullanılabilirliğini kontrol edebilirsiniz.
• Hızlı Yanıt: Bayilik sağlayıcılarını kısa listeye almanın en hızlı yolu, bu soru listesini iki veya üç aday üzerinde yan yana çalıştırmak, ardından imzalamadan önce API veya paneli gerçekten bir sandbox’ta test etmektir — pazarlama sayfaları nadiren destek kalitesini veya white-label derinliğini ortaya koyar, ama bir sandbox testi genellikle bir saat içinde ortaya koyar.

Öne Çıkan Noktalar - Gerçek hacminizdeki toptan fiyatı sorun, reklamdaki başlık oranını değil. - Kayıt olmadan önce sandbox erişimini, destek SLA’sını ve white-label derinliğini doğrulayın. - Herhangi bir gerçek müşteri hacmini taşımadan önce platformu elle test edin.

İşi Büyütmek

• Domain bayiliğinde büyüme genellikle üç yerden gelir: TLD tekliflerini genişletmek, elde tutmayı (yenileme oranı) iyileştirmek ve ek hizmetleri paketlemek. Birkaç yüz domainin ötesinde otomasyon isteğe bağlı olmaktan çıkar — manuel yenileme ve provizyon süreçleri hacim altında çöker; sorunsuz büyüyen işletmeler, buna zorunlu kalmadan önce API odaklı iş akışlarına geçmiş olanlardır.
• Büyüme yolu, başlangıç noktasından bağımsız olarak genellikle aynı dört aşamayı izler:

Aşama 1: Manuel         (1–200 domain)
  Kontrol paneli, manuel kayıt, tablo tabanlı takip
        ↓ otomasyon kurulum maliyetine değecek noktaya gelir
Aşama 2: Otomatik       (200–2.000 domain)
  WHMCS veya eşdeğeri, cron tabanlı yenilemeler, TLD Sync çalışıyor
        ↓ hacim doğrudan entegrasyonu haklı çıkarır
Aşama 3: API Odaklı       (2.000–20.000 domain)
  Özel API entegrasyonu, toplu işlemler, portföy izleme
        ↓ büyüme doğrudan satıştan kanala kayar
Aşama 4: Çok Katmanlı        (20.000+ domain)
  Alt bayi ağı, white-label partnerler, kademeli toptan fiyatlandırma
Aşama 1’den doğrudan Aşama 3’e atlamak nadirdir — çoğu işletme manuel süreçleri kademeli olarak aşar ve erken otomatikleştirmenin amacı, hacim bir tablo ve kontrol panelinin takip edebileceğinin ötesine geçtiğinde acı verici bir telaşı önlemektir.

Daha büyük bayilerin ayrıca platformlarının büyümeyi doğrudan ödüllendirip ödüllendirmediğine bakması gerekir: hacim arttıkça otomatik olarak iyileşen kademeli toptan fiyatlandırma ve kayıt hacmi belirli eşikleri geçtiğinde ortak pazarlama desteği sunan partner veya pazarlama fonu programları, başlangıç kademesinde görünmeyen bir şekilde ölçekte birim ekonomisini anlamlı biçimde değiştirir.

Domain Bayileri için Pazarlama ve SEO

Domain satışları rekabetçi, fiyata duyarlı bir pazardır; bu yüzden farklılaşma genellikle büyük registrar’larla doğrudan fiyat rekabetinden çok bir niş veya bir paketten gelir:

• Niş TLD odağı (sektöre özel veya bölgesel uzantılar), .com fiyatlandırmasında geniş çapta rekabet etmek yerine.
• Gerçek alıcı sorularını yanıtlayan içerik — TLD karşılaştırmaları, transfer rehberleri, yenileme açıklamaları — ki bu tam olarak yapay zeka destekli arama araçlarının doğrudan öne çıkardığı içerik türüdür.
• Domainin izole satılmaması için hosting, e-posta veya tasarım hizmetleriyle paketleme.
• Birçok rakip bunu gizlediği için bir güven sinyali ve farklılaştırıcı olarak şeffaf yenileme fiyatlandırması.
• Teklif istemeyi zorunlu kılmak yerine canlı Domain Fiyatlandırması’nı halka açık şekilde karşılaştırmak — ilk yıl maliyeti, yenileme maliyeti ve transfer maliyetini yan yana göstermek, satıştan önce güven inşa eder.

Ortaya döküldüğünde, tipik müşteri yolculuğu tek bir “şimdi satın al” tıklamasının önerdiğinden daha fazla adım içerir — ve terk oranının çoğu satın alma sonrasında değil, arama ile ödeme arasında yaşanır:

 Arama            "[domain] uygun mu?"
    ↓
 Karşılaştırma    fiyat, TLD seçenekleri, yenileme maliyeti (yalnızca 1. yıl fiyatı değil)
    ↓
 Ödeme            kayıt + iletişim bilgileri + ödeme
    ↓
 Onboarding       DNS kurulumu, nameserver yönlendirme, ilk yenileme hatırlatması
    ↓
 Yenileme         bunun tek seferlik bir satış mı yoksa çok yıllı bir ilişki mi
    │             olduğuna karar veren an
    ↓
 Ek Satış         güven kurulduktan sonra hosting, e-posta, SSL

Ek Satış: Hosting, Güvenlik, E-posta ve Ötesi

Domainler düşük marjlı bir giriş noktasıdır; bayilikte başarılı olan işletmeler neredeyse her zaman bu ilk satışın etrafına daha yüksek marjlı hizmetler ekler:

• Hosting (paylaşımlı, bulut, VPS veya sunucu) — en doğal eşleşmedir, çünkü hosting olmadan bir domain kendi başına işe yaramaz. Müşteriler giriş seviyesi hostingi aştıkça VPS ve sunucular, paylaşımlı planlardan anlamlı derecede daha yüksek marj taşır.
• SSL sertifikaları — artık varsayılan olarak beklenen bir özellik olsa da, genişletilmiş doğrulama veya çoklu domain sertifikaları için hâlâ meşru bir ek satıştır.
• Profesyonel / kurumsal e-posta — özel bir domainle doğal olarak eşleşen, tekrarlayan ve yapışkan bir hizmet; müşteriler bir kez kurulduktan sonra e-postayı nadiren taşıdığından kategorideki en yapışkan bağlanma oranına sahip ürünlerden biri.
• Web sitesi oluşturucular, yapay zeka destekli olanlar dahil — bir müşteriyi “az önce bir domain aldım” durumundan tek oturumda canlı bir siteye taşır; teknik olmayan alıcılar için domain satın almasının güçlü bir tamamlayıcısıdır.
• Yedekleme ve CDN hizmetleri — sizde zaten hosting bulunan müşteriler için düşük temaslı, yüksek elde tutmalı ek hizmetler.
• E-posta güvenliği ve spam koruması, ayrıca iş üretkenliği paketleri (“Office” tarzı bir paket) — ikisi de bağımsız bir satıştan çok kurumsal e-posta ile birlikte doğal olarak paketlenir.

Yalnızca domain satın alan bir müşteri düşük marjlı bir müşteridir. Domain, hosting ve e-posta satın alan bir müşteri, önemli ölçüde farklı bir iş ilişkisidir — her ek hizmet, hem müşteri başına geliri artırır hem de müşterinin tek bir kalem fiyat farkı yüzünden bir rakibe geçme olasılığını azaltır.

Tipik ek satış yolu, müşterinin her hizmete gerçekten ihtiyaç hissettiği zamana kabaca uyan, öngörülebilir bir sırayı izler:

Domain satın alma
      ↓  "şimdi bir web sitesi koyacak bir yere ihtiyacım var"
 Hosting
      ↓  "şimdi insanların yeni siteme güvenmesine ve e-posta göndermesine ihtiyacım var"
 SSL + Profesyonel E-posta
      ↓  "şimdi hızlıca inşa edilmesine ihtiyacım var"
 Web Sitesi Oluşturucu (veya yapay zeka destekli oluşturucu)
      ↓  "şimdi korunmasına ve yedeklenmesine ihtiyacım var"
 Yedekleme / CDN / E-posta Güvenliği

Müşteri başına gelir, dönüşümle aynı şekilde katmanlanır — üstünde çok daha büyük bir tekrarlayan hizmet katmanını destekleyen ince bir domain marjı tabanı:

Vaka Analizi: Gerçekçi Bir ROI Örneği

Zaten ayda 15-20 müşteri domaini kaydeden ve bunu daha önce salt bir maliyet olarak gören küçük bir web tasarım ajansını düşünün. Bayi olarak mütevazı bir marj artı aylık 5 dolarlık bir DNS yönetim ücreti ekleyerek, bu ajans ilk çeyrekte aylık kabaca 150-250 dolarlık tekrarlayan marj kazanır — yeni müşterilerden değil, zaten yapmakta olduğu işten. Bir yıl içinde, domain tabanı büyüdükçe ve yenilemeler birikince, bu tekrarlayan marj orantılı bir yeni satış çabası olmadan katlanır. Bu, bayilik kârlılığına giden en yaygın ve en gerçekçi yoldur: soğuk bir başlangıçtan bir domain işi kurmak yerine, zaten yaptığınız işi paraya çevirmek.

Destek kalitesi düşerse yenileme oranı riski

Adım Adım Kontrol Listesi

Domain Bayiliği İşine Başlama Adımları

• Hangi iş modelinin uyduğuna karar verin (paketli, salt bayilik, ajans geçişi, gömülü API, white-label).
• TLD kapsamı, fiyatlandırma, API kalitesi ve destek açısından 2-3 bayilik platformunu değerlendirin.
• Hacme geçmeden önce platformu bir sandbox/OT&E ortamında test edin.
• Vitrininizi kurun veya API/WHMCS modülünü entegre edin.
• İlk satışınızdan önce, sonra değil, yenileme hatırlatma otomasyonunu kurun.
• Fiyatlandırmanızı belirleyin (maliyet-artı, pazara göre veya paketli zarar-lideri).
• Transferler, yenilemeler ve WHOIS güncellemeleri için destek sürecinizi belgeleyin.
• Daha geniş pazarlamadan önce mevcut müşterilere veya kanala lansman yapın.
• Yalnızca yeni satışları değil, birincil sağlık metriğiniz olarak yenileme oranını izleyin.

Temel domain akışı istikrar kazandığında ek satışları (hosting, SSL, e-posta, yedekleme) katmanlayın.

Sıkça Sorulan Sorular

Son Tavsiyeler

Yeni başlıyorsanız: tek bir bayilik platformu seçin, bir sandbox/OT&E ortamında test edin, soğuk pazarlama yerine mevcut müşterilerinizle veya danışanlarınızla başlayın ve ilk satışınızdan önce yenileme hatırlatma otomasyonunu çalışır hale getirin.

Yerleşik bir ajans veya hosting firmasıysanız: hacim haklı çıkardığı anda kontrol panelinden API/WHMCS odaklı otomasyona geçin ve yeni kayıtları değil, yenileme oranını temel büyüme metriğiniz olarak ele alın.

Kurumsal veya SaaS ölçeğinde inşa ediyorsanız: API entegrasyonuna erken yatırım yapın ve bir white-label veya alt bayi modeli düşünün; çünkü otomasyonu manuel bir sürecin üzerine sonradan eklemek, en baştan inşa etmekten çok daha pahalıdır.

Domain bayiliği, agresif pazarlamadan çok sabrı ve operasyonel disiplini ödüllendirir. Temelleri doğru yapın — net fiyatlandırma, güvenilir yenilemeler, dürüst destek — ve işin tekrarlayan doğası, zaman içinde işin geri kalanının çoğunu sizin için yapar.