Alan Adı Portföyü: Yenileme, Fatura ve Marka Koruması

Alan Adı Portföyünde Yenileme, Maliyet ve Sorumluluk

Bir ajans, SaaS girişimi ya da kurumsal bir marka olarak işler büyüdükçe alan adı sayınız da sessizce artar: marka alan adları, projeye özel domain’ler, kampanya ve landing sayfaları, country-code (ccTLD) uzantıları, typo ve defansif kayıtlar… Bir süre sonra elinizde onlarca alan adından oluşan bir portföy bulunabilir. Sorun şu: Bu portföyü yenileme tarihleri, faturalar, yetkiler ve marka koruması açısından sistemli yönetmediğinizde yenileme e-postası gözden kaçabilir, kritik bir alan adının süresi dolabilir, fatura yanlış bütçeye gidebilir veya bir çalışan ayrıldığında hesaba erişim kaybolabilir.

Bir proje toplantısında kampanya alan adının hangi hesapta olduğunu kimsenin bilmediğini veya muhasebenin farklı faturaları birleştirerek yıllık domain maliyetini hesaplamaya çalıştığını düşünün. Böyle bir durumda ortak envanter, sorumlu kişiler ve kayıtlı bir yenileme süreci gerekir. Bu rehber, onlarca alan adını yenileme, faturalandırma ve marka koruması açısından düzenlemek için uygulanabilir bir çerçeve sunar.

Dağınık Hesaplar ve Kayıtlar Neden Sorun Oluşturur?

İşletmeler, alan adlarını planlı bir stratejiden çok, anlık ihtiyaçlarla satın almaya başlayabilir: yeni ürün çıkar, kampanya yapılır, yeni pazara girilir, yan proje test edilir… Yeni fikirler beraberinde yeni domain’ler getirebilir; ancak bu büyümeye bir portföy yönetim süreci eşlik etmeyebilir. Zamanla:

• Farklı registrar hesaplarına dağılmış alan adları,
• Kimde olduğu bilinmeyen yönetici şifreleri,
• Takibi yapılmayan yenileme tarihleri,
• Aynı markaya ait dağınık TLD ve country-code uzantıları,
• Farklı ekiplerin ödediği, muhasebede birleşmeyen faturalar

Bu dağınıklık yalnız ek yenileme veya kurtarma ücreti doğurmaz; alan adını kaybetme, web ve e-posta kesintisi, arama görünürlüğünün zarar görmesi ve hukuki uyuşmazlık riski de yaratabilir. Alan adı yaşam döngüsü rehberi grace ve redemption aşamalarını açıklar. Süreler ve uygulanabilirlik TLD ile kayıt kuruluşuna göre değişir; süre dolduktan sonraki kurtarma dönemleri hizmetin çalışacağını veya alan adını mutlaka geri alacağınızı garanti eden bir tampon değildir.

Alan Adı Envanterini Oluşturun

Önce hangi alan adlarının hangi kurum veya müşteriye ait olduğunu, hangi hesapta bulunduğunu ve ne için kullanıldığını belirleyin. Kayıt kuruluşu, DNS ve hosting ayrı hizmetler olabilir; aynı panelde görünmeleri sorumluluklarının aynı olduğu anlamına gelmez.

Dağınık Kayıtlardan Tek Envantere Geçiş

Başlangıç için erişimi sınırlandırılmış bir tablo yeterli olabilir. Tabloyu doldururken yönetmeye yetkili olduğunuz kaynakları kullanın:

• Kurumsal registrar ve panel hesaplarının alan adı listeleri.
• İlgili ekiplerin ve ajansların yetkili olarak yönettiği kayıtlar; çalışanların kişisel hesabında kalan şirket alan adları için belgeli erişim veya devir süreci.
• Satın alma, yenileme ve ödeme belgeleri.
• Eski projelerin DNS, web, e-posta ve yönlendirme kayıtları; kullanımının bittiği varsayılan alan adları dahil.

Tüm bu alan adlarını tek bir listede toplamak, gözden kaçmış kayıtları görünür kılar ve portföyün kapsamını netleştirir.

Envanter Tablosunda Olması Gereken Temel Alanlar

Alan adı envanteriniz için şu sütunları kullanabilirsiniz:

• Alan adı ve kayıt uzantısı: example.com veya example.com.tr gibi tam ad; kullanılan ccTLD/gTLD politikası.
• Registrar ve hesap: kayıt kuruluşu, hesap tanımlayıcısı ve erişim sorumlusu; parola veya kurtarma kodunu bu tabloya koymayın.
• Kayıt sahibi, iş sahibi ve teknik sorumlu: alan adının adına kayıtlı olduğu kişi/kurum ile günlük yönetimi yapan ekibi ayırın.
• Marka, proje ve işlev: web, e-posta, API, yönlendirme, defansif kayıt veya kullanım dışına çıkarılacak hizmet.
• Sona erme ve işlem tarihleri: kayıt süresinin sonu, izin verilen yenileme aralığı, varsa daha erken ödeme/işleme son tarihi ve kurum içi tamamlama hedefi.
• Otomatik yenileme: destek, açık/kapalı durumu, planlanan tahsilat zamanı, son denemenin sonucu.
• Maliyet: yenileme fiyatı, para birimi, vergi/ek ücret, maliyet merkezi, onaylayan ve ödeme belgesi.
• DNS ve e-posta bağımlılıkları: yetkili ad sunucuları, DNS sağlayıcısı ve önemli MX/kurtarma adresleri.
• Bağlı hosting/sunucu: paylaşımlı hosting, VPS veya diğer hizmetler; yönetim sorumluları.
• TLS ve güvenlik: sertifika uçları/yenileme sorumlusu, transfer kilidi, doğrulanmış DNSSEC durumu, MFA ve son kontrol tarihi.
• Karar ve gerekçe: tutulacak, devredilecek veya kullanımdan çıkarılacak; kararı onaylayan ve gözden geçirme tarihi.

Envanter ancak değişikliklerden sonra güncellenip registrar, DNS ve ödeme kayıtlarıyla karşılaştırılırsa güvenilir kalır. Yenileme onayı, başarılı ödeme ve uzamış kayıt süresi farklı kontrollerdir; yalnız tabloda “otomatik” yazmasına güvenmeyin.

Alan Adlarını İşlev ve Riskiyle Sınıflandırın

Elinizdeki ham listeyi anlamlı hale getirmek için, alan adlarını stratejik öneme göre sınıflandırmak gerekir. Bu sayede, yenileme zamanı geldiğinde hangi alan adının öncelikli olduğunu ve kararın hangi iş gereksinimine dayandığını görebilirsiniz.

Temel Kategori Önerileri

Pratik bir sınıflandırma şöyle olabilir:

• Çekirdek marka alan adları: Ana markanızın .com, .com.tr, .net gibi en kritik uzantıları. İş ve marka bağımlılıkları sürerken bunlara en yüksek koruma önceliğini verin.
• Stratejik ülke / bölge alan adları: Uluslararası açılım ve SEO amaçlı aldığınız ccTLD’ler. Bu konuya dair detaylı stratejileri alan adı stratejisi nasıl kurulur rehberimizde anlattık.
• Ürün / alt marka alan adları: Farklı ürün isimleri, alt markalar ve mikro markalar için aldığınız domain’ler.
• Kampanya ve kısa URL alan adları: Dönemsel kampanyalar, offline reklamlarda kullanılan kısa ve akılda kalıcı domain’ler.
• Defansif ve typo alan adları: Marka adınızın sık yapılan yazım hataları, Türkçe/İngilizce karakter varyasyonları gibi kayıtlar.
• Spekülatif / yatırım amaçlı alan adları: Doğrudan işinizle ilişkili olmayan, ilerde satma veya proje üretme niyetiyle aldığınız domain’ler.

Her domain’i bu kategorilerden birine oturttuğunuzda, portföyünüz bir anda daha okunabilir hale gelir. Ayrıca her kategoriye farklı yenileme ve bütçe politikaları tanımlayabilirsiniz.

Yenileme Önceliği Seviyeleri

Kategorilere ek olarak, her alan adına bir önem derecesi atamak işleri kolaylaştırır. Örneğin:

• Seviye 1 — Kritik: üretim sitesi, ana e-posta, oturum açma veya önemli müşteri hizmetleri. Yenileme ve kurtarma sorumluları açık olmalıdır.
• Seviye 2 — Yüksek: aktif gelir üreten projeler, önemli ülke kayıtları ve kullanılan yönlendirmeler.
• Seviye 3 — Orta: gelecekte kullanılabilecek projeler; elde tutulmasının gerekçesi ve bütçesi düzenli incelenir.
• Seviye 4 — Düşük: kalan hizmet veya hesap bağımlılığı bulunmayan, kaybının etkisi sınırlı denemeler.

Bir web sitesi açılmaması alan adının düşük riskli olduğunu göstermez: e-posta, eski bağlantılardan gelen yönlendirmeler veya hesap kurtarma hâlâ bu ada bağlı olabilir. Defansif kayıtları da trafik yerine yeniden kaydedilip kötüye kullanılma riskiyle değerlendirin.

Yenileme Takvimini ve Tamamlama Hedeflerini Belirleyin

Yenileme kararı ile işlemin tamamlanması arasına yeterli süre koyun. Geçersiz kart, yetersiz bakiye veya bekleyen doğrulama nedeniyle otomatik yenileme başarısız olabilir. Alan adı süresi dolduğunda izlenecek yol kurtarma seçeneklerini açıklar; esas hedef, alan adının kendi son tarihinden önce yenilemeyi doğrulamaktır.

Yenileme Takvimi ve Eşik Tarihleri

Yıllık bütçe takvimini, her alan adının bireysel yenileme takvimiyle birlikte kullanın. İnceleme zamanı ile yenilemenin yapılabildiği dönem aynı olmak zorunda değildir. Örnek bir kurum içi plan:

• Kritik alan adlarını sona ermeden 60–90 gün önce inceleyip yenileme kararını ve bütçeyi onaylayın.
• Diğer alan adlarında örneğin 30 gün önce karar kontrolü yapın; kural veya işlem süresi gerektiriyorsa daha erken başlayın.
• Her TLD ve registrar için yenilemenin ne zaman yapılabildiğini ve daha erken ödeme/işlem son tarihi olup olmadığını kontrol edin.
• İşlem o anda mümkünse tamamlayın; değilse açılan yenileme aralığına sorumlu ve tamamlama hedefi atayın. Sona erme veya daha erken geçerli son tarih öncesinde başarısız ödemeyi düzeltmek için zaman bırakın.
• Hatırlatıcıları yalnız incelemeye değil, işlem tamamlanmasına ve hata takibine de bağlayın; yeni sona erme tarihini kaydedin.

Bu süreler ICANN’in bütün uzantılara uyguladığı zorunlu takvimler değil, uyarlanabilir çalışma örnekleridir. Takvim veya iş takip aracındaki hatırlatıcıları varsa registrar bildirimleriyle birlikte kullanın. Son bir 7 günlük uyarı, önceki başarısızlığı veya geçerli daha erken son tarihi telafi etmeyebilir. Otomatik denemenin tarihi hedefinize uymuyorsa sağlayıcının desteklediği manuel seçeneği önceden değerlendirin.

Otomatik Yenileme mi, Manuel Yenileme mi?

Burada genellikle şu yaklaşımı öneriyoruz:

• Kritik ve önemli alan adları: destekleniyorsa otomatik yenilemeyi kullanın; tahsilat tarihi, ödeme yöntemi ve sonuç izlenmelidir. Desteklenmiyorsa sorumlusu belli manuel süreç kurun.
• Kampanya, deney ve yatırım kayıtları: ihtiyaç ve bütçeyi yenileme öncesinde değerlendirin. Düşük trafik tek başına bırakma gerekçesi değildir.
• Onaylı kullanım dışı bırakma: iş ve teknik sorumlular; web, yönlendirmeler, e-posta, sertifikalar, üçüncü taraf entegrasyonları ve kurtarma adreslerinin artık bağımlı olmadığını doğrulasın. Saklama yükümlülüğünü ve başkasının kaydetme riskini değerlendirin. Risk kabul edilemezse tutup yenileyin; aksi halde onayı/tarihi kaydedin, bağımlılıkları siz hâlâ alan adını kontrol ederken kaldırın, ardından otomatik yenilemeyi kapatın.

Yenilenmesini istediğiniz alan adlarında başarılı ödeme belgesini, registrar işlem durumunu ve güncel sona erme tarihini birlikte kontrol edin. Registry düzeyindeki otomatik uzatma görünümü veya paneldeki bir fatura tek başına sizin yenileme işleminizin tamamlandığının kanıtı değildir.

Fatura, Onay ve Maliyet Merkezlerini Eşleştirin

Teknik taraf kadar önemli bir diğer boyut da faturalandırma ve maliyet takibidir. Alan adları genellikle küçük kalemler gibi görünse de, portföy büyüdükçe yıllık ciddi bir rakama dönüşür. Ayrıca doğru muhasebeleştirilmediğinde, hangi projenin ne kadar alan adı maliyeti oluşturduğunu görmek zorlaşır.

Maliyet Merkezleri ve Bütçe Planlama

Envanter tablonuzda her alan adına bir maliyet merkezi veya proje kodu eklemek, yıllık bütçe planlamasında büyük kolaylık sağlar. Örneğin:

• Kurumsal site ve ana marka domain’leri: “GENEL-PAZARLAMA” bütçesi,
• Ürün bazlı domain’ler: İlgili ürün biriminin bütçesi,
• Kampanya domain’leri: Kampanya veya medya bütçesi,
• Spekülatif domain’ler: “YATIRIM / AR-GE” bütçesi.

Onaylayan kişi ve onay tarihini maliyet merkeziyle birlikte kaydedin. Şirket ödeme yöntemi kullanın; kişisel kart veya ayrılmış çalışanın posta kutusuna bağımlılığı kaldırın. Muhasebe raporunda yenileme fiyatını ilk yıl promosyonundan ayırın, para birimi ve ek ücretleri görünür tutun. Böylece hangi projenin ne kadar maliyeti olduğu ve harcamayı kimin onayladığı izlenebilir.

Kur Dalgalanmaları ve Uzun Dönemli Kayıtlar

Alan adı yenileme fiyatları TLD’ye ve sağlayıcıya göre değişebilir; yıllar içinde artışlar da olabilir. Aynı durum alan adı piyasasındaki birleşmelerin etkilerini anlattığımız yazıda da ele aldığımız gibi, politika ve finansal dinamiklerle yakından ilişkili. Bu nedenle:

• Kritik alan adlarında, ilgili TLD/registrar destekliyor ve bütçe uygunsa çok yıllı süreyi değerlendirin.
• Toplu incelemeleri bütçe dönemleriyle birleştirin; her alan adının kendi izin verilen yenileme aralığını ve son tarihini koruyun.
• Peşin ödeme tutarını, olası fiyat/kur değişimini ve kullanımın devam edeceği süreyi karşılaştırın.

Çok yıllı yenileme idari işlem sayısını ve gelecekteki maliyet belirsizliğini azaltabilir; tasarruf garantisi değildir. Normal yenileme mevcut kayıt süresine ek süre getirir, bütün alan adlarını istediğiniz ayda sona erecek biçimde otomatik hizalamaz. Desteklenen süreler ve erken yenileme koşulları uzantıya göre değişebilir. Uzun ödeme yapmadan önce alan adının işlevini ve tutma kararını doğrulayın.

Marka Korumasını Gerçek Risklere Göre Planlayın

Alan adları, sadece teknik birer adres değil; marka varlığınızın dijital omurgasıdır. Bu nedenle portföy yönetiminde en kritik boyutlardan biri de marka korumasıdır. Benzer alan adları phishing veya sahte kampanyalar için kullanılabilir; ancak her benzer kayıt kötü niyetli değildir. Savunma bütçesini olası zarara, müşteri davranışına ve gerçek pazar ihtiyacına göre belirleyin.

Defansif Kayıtlar: Hangi Alan Adlarını Ekstra Tutmalısınız?

Genellikle şu gruplarda defansif kayıt yapmayı öneriyoruz:

• Temel TLD varyasyonları: .com, .net, .org gibi klasik uzantılar; iş modelinize uygunsa .io, .ai vb.
• Ülke uzantıları: Hedeflediğiniz pazarlardaki ccTLD’ler (örn. .de, .fr) ve Türkiye’de .com.tr, .net.tr gibi uzantılar.
• Yazım varyasyonları ve typo kayıtlar: Marka adınızın sık yapılan yazım hataları (ör. q yerine k, w yerine v) gibi.
• Türkçe karakter varyasyonları: ş/s, ı/i, ö/o gibi farklar; ilgili kayıt operatörünün izin verdiği karakter ve IDN kuralları içinde.

Her olası varyasyonu almak yerine markanız için gerçek risk oluşturanları seçin. SEO ve marka için TLD seçimi rehberi pazar ve isim kararlarını ele alır. Savunma amaçlı alan adında web yönlendirmesi veya kontrollü park sayfası kullanılabilir, fakat bunlar e-posta sahteciliğini önlemez. Kayıt ve hesap güvenliğini sürdürün; posta göndermeyen alan adlarının e-posta politikalarını ayrıca değerlendirin.

RDAP, Kayıt Bilgileri ve ccTLD Kuralları

gTLD kayıt verileri için RDAP güncel sorgulama protokolüdür. ICANN kapsamındaki gTLD kayıt operatörleri ve registrar’lar RDAP sunar; WHOIS bazı hizmetlerde devam edebilir, bu nedenle “WHOIS her yerde kaldırıldı” demek doğru değildir. Sorgu sonucu kişisel verileri gizleyebilir; kamuya açık sonuç sahipliği, ödeme durumunu veya bütün iletişim bilgilerinin doğruluğunu tek başına kanıtlamaz. ICANN alan adı politikaları rehberi arka plan sunar; güncel gereklilik ve yürürlük tarihini ilgili resmi bildirimden kontrol edin.

Kayıt sahibi ve iletişim bilgilerindeki değişiklikleri, alan adını yönettiğiniz registrar’ın kayıt sahibi/iletişim düzenleme sürecinden yapın; RDAP arama ekranı bir düzenleme paneli değildir. Registrar doğrulama taleplerini takip edin. Kamuya açık sorguda verinin gizlenmesi (redaction), ayrıca seçilen bir privacy/proxy hizmetiyle aynı şey değildir ve böyle bir hizmetin alındığını göstermez. İlgili gizlilik hizmetinin şartları ayrıca değerlendirilir. Kamuya açık görünüm, kayıt kuruluşuna doğru iletişim bilgisi verme yükümlülüğünü kaldırmaz. ccTLD’lerde kayıt verisi, gizlilik, kayıt uygunluğu ve uyuşmazlık süreçleri ilgili operatörün kurallarına bağlıdır; gTLD kurallarını otomatik genellemeyin.

• Marka tescili, hedef pazar ve alan adı listesi birbirini destekliyor mu?
• Kötüye kullanım riski yüksek eksikler var mı; hangi kayıtlar gereksiz bütçe tüketiyor?
• Registrar’daki kayıt sahibi, firma unvanı ve iletişim bilgileri doğru mu; bekleyen doğrulama var mı?
• Kamuya açık RDAP/WHOIS sonucunda hangi veri gizleniyor ve varsa seçilmiş gizlilik hizmetinin kapsamı ne? Bunları hesap güvenliğiyle eş tutuyor muyuz?
• Marka uyuşmazlığında uygulanabilir politika hangisi? Marka tescili her benzer alan adının otomatik devrini sağlamaz; ccTLD kuralları farklı olabilir.

Hesap Güvenliği ve Kurtarma Yollarını Düzenleyin

Alan adı veya DNS yönetiminizin ele geçirilmesi, sunucularınız doğrudan ele geçirilmese bile hizmetlerinizin güvenliğini tehlikeye atabilir. Çünkü DNS kayıtlarını değiştirebilen biri, trafiğinizi sahte sunuculara yönlendirebilir, yeni gelen e-postaları kendi sunucusuna çekebilir veya alan adınız için TLS sertifikası edinmeye çalışabilir. Bu nedenle portföy yönetimi sadece “liste ve takvim” değil, güvenlik politikası da gerektirir.

Registrar Lock, DNSSEC, 2FA: Temel Güvenlik Katmanları

Minimum düzeyde şu önlemleri almanızı öneriyoruz:

• Registrar Lock: Alan adınızın başka bir kayıt kuruluşuna transferini kilit kaldırılana kadar engelleyen önlem. Özellikle çekirdek alan adlarınızda, planlı transferler dışında açık tutun; hesap ele geçirilmesine karşı tek başına yeterli değildir.
• DNSSEC: DNS verilerini kriptografik olarak imzalar; doğrulama zinciri doğru kurulduğunda, DNSSEC doğrulaması yapan çözümleyicilerin sahte veya değiştirilmiş yanıtları reddetmesini sağlar. Yetkili DNS yönetim hesabının ele geçirilmesini önlemez.
• İki faktörlü kimlik doğrulama (2FA): Alan adı ve DNS panellerine girişte, sadece şifre değil, ek bir doğrulama katmanı kullanın.
• Güçlü ve benzersiz şifreler: Özellikle yönetici hesaplarında parola yöneticisi kullanın.

Bu konuları daha derinlemesine ele aldığımız alan adı güvenliği rehberimizde adım adım uygulanabilir öneriler bulabilirsiniz.

Ekip İçinde Rol Bazlı Erişim

Kuruma ait alan adlarının günlük yönetimini tek kişinin erişimine bağlamayın. Kayıt sahibi, teknik yönetici ve faturayı ödeyen taraf farklı olabilir; müşteri adına yönetim yetkisi alan adının sahipliğini ajansa geçirmez. Kurumsal hesap ve yetkili kişilerin sorumluluklarını belgeleyin.

• Bildirimleri izlenen kurumsal grup posta kutusuna yönlendirin. Bu kutu yönetilen alan adına bağlıysa alan adı/DNS arızası sırasında tek kurtarma yolu olmasın.
• Sağlayıcının desteklediği bağımsız bir kurtarma kanalı kurun; MFA kurtarma kodlarını ve gereken erişim belgelerini güvenli, yetkili kişilerce erişilebilir bir kasada saklayın. Kurtarma kasası da yalnız aynı alan adının SSO veya e-postasına bağımlı olmamalıdır.
• Destekleniyorsa bireysel kullanıcı ve rol bazlı yetkiler kullanın; fatura görüntüleme, DNS değiştirme ve transfer yetkisini ayırın.
• Çalışan ayrılışında kullanıcı erişimlerini, aktif oturumları, API anahtarlarını ve kurtarma yollarını gözden geçirip gerektiğinde kaldırın veya yenileyin.

Kurtarma yolunun çalışabilirliğini sağlayıcının prosedürüyle, hizmeti kesintiye uğratmadan dönemsel olarak kontrol edin. Yetkili yedek sorumluyu belirleyin. Bu düzen erişim riskini azaltır; kişisel şifrelerin herkese dağıtılması veya MFA’nın kapatılması çözüm değildir.

Otomasyonu ve Düzenli Kontrolleri Kurun

Portföy belli bir büyüklüğü aştıktan sonra, her şeyi Excel ve manuel takvimlerle yönetmek yorucu hale gelir. İşte burada otomasyon ve entegre altyapı devreye girer. Örneğin, alan adı, DNS ve hosting kayıtlarını ortak bir envanter ve bildirim sürecinde birleştirmek, farklı panellerdeki bilgileri elle karşılaştırma yükünü azaltabilir.

DNS ve Hosting Tarafıyla Uyumlu Çalışan Yapı

Alan adlarının büyük kısmı zaten bir web sitesi, API veya e-posta altyapısına bağlıdır. Dolayısıyla alan adı portföyünüzü, hosting mimarinizden bağımsız düşünmek sağlıklı değildir. Örneğin:

• Kurumsal siteleriniz paylaşımlı hosting’de,
• Yüksek trafikli projeleriniz NVMe tabanlı VPS veya dedicated sunucularda,
• Kritik uygulamalarınız ise coğrafi yedekli mimariler üzerinde çalışıyor olabilir.

Alan adı kaydı, DNS ve hosting’i tek envanterde takip etmek için tek sağlayıcı kullanmanız gerekmez. Konsolidasyonu değerlendirirken yönetim kapsamını, yetki seçeneklerini, destek sorumluluğunu ve sağlayıcıya bağımlılığı kontrol edin. Alan adı transferi rehberi geçiş planlamasını açıklar. Registrar transferi, aynı sağlayıcıda hesap değişimi ve kayıt sahibinin değişmesi farklı işlemlerdir. Müşteri yetkilendirmelerini, gerekli onayları ve varsa transfer kısıtlarını netleştirin; DNS ve e-posta hizmetinin taşınmadan sonra sürmesi için ayrıca plan yapın.

Otomatik Bildirimler, Raporlar ve API Entegrasyonları

Daha ileri seviye ekipler için şu adımlar da gündeme gelebilir:

• Sağlayıcı destekliyorsa yenileme ve ödeme hatası bildirimlerini izlenen e-posta veya ekip aracına bağlayın.
• Envanteri ve değişiklik kayıtlarını erişimi sınırlandırılmış, geri alınabilir biçimde dışa aktarın; sırları raporlara koymayın.
• DNS, TLS sertifikası, web/e-posta erişimi ve alan adı sona erme tarihini ayrı ölçümler olarak izleyin; sitenin açılması yenilemenin tamamlandığını kanıtlamaz.
• API destekleniyorsa görev için en dar yetkiyi kullanın. Nameserver değişimi, transfer ve kullanım dışı bırakma gibi etkili işlemleri onay ve işlem kaydıyla yürütün.

Üç aylık incelemelerde yaklaşan 6–12 aylık yenilemeleri, maliyet merkezlerini ve tutma/bırakma kararlarını gözden geçirebilirsiniz. Yıllık denetimde sahiplik, erişim ve marka kapsamını doğrulayın; olay veya ekip değişikliğinde ara kontrol yapın. Bu periyodik toplantılar bireysel yenileme son tarihlerini ve anlık ödeme hatası takibini değiştirmez.

Örnek: Bir Ajansın Alan Adı Envanterini Düzenlemesi

Somutlaştırmak için varsayımsal bir senaryo ele alalım. Orta ölçekli bir dijital ajans düşünün: 60’tan fazla alan adı var. Bunların bir kısmı müşteriler adına, bir kısmı ajansın kendi markaları ve yan projeleri için alınmış. Domain’ler farklı yıllarda, farklı çalışanlar tarafından, farklı sağlayıcılarda açılan hesaplarla satın alınmış. Sonuç olarak:

• Hangi domain’in hangi projeye ait olduğuna dair net bir kayıt yok,
• Bazı kritik domain’lerin yenileme e-postaları eski çalışanların adresine gidiyor,
• Muhasebe, “domain masrafı” kalemini tek satır görüp detayına inemiyor,
• Bir müşterinin domain’i süresi dolduğu için çok kısa süreli de olsa yayından düşüyor.

Bu varsayımsal ajans için şu adımlar önerilebilir:

1. Yetkili registrar kayıtları ve faturalar birleştirilerek ortak envanter oluşturulur.
2. Her alan adının kayıt sahibi, müşteri/projesi, iş ve teknik sorumlusu belirlenir; kategori ile öncelik atanır.
3. Transfer gerekli görülürse müşterinin yetkisi, ilgili transfer koşulları, DNS ve e-posta sürekliliği kontrol edilir. Sadece envanter oluşturmak için transfer yapılması gerekmez.
4. TLD/registrar aralıklarına göre inceleme ve tamamlanma hedefleri kurulur; otomatik veya manuel yenilemenin sonucu izlenir.
5. Her domain maliyet merkezi ve onaylayanla eşleştirilir; ödeme kayıtları güncellenir.
6. Transfer kilidi, MFA, DNSSEC durumu ve bağımsız kurtarma yolları kontrol edilir. Kullanımdan çıkarma ancak bağımlılık ve yeniden kayıt riski incelendikten sonra onaylanır.

Bu düzenin amacı, ajansın alan adları için “kimde, nerede, ne zaman, ne kadar” sorularına tek envanterden yanıt bulabilmesidir. Düzenin korunması için yeni domain’ler eklenmeli; yenilemeler, ödemeler, sorumlular ve erişim yetkileri düzenli olarak kontrol edilmelidir.

Portföy Yönetimini Güncel Tutun

Onlarca hatta yüzlerce alan adı olan bir portföyü düzene sokmak, ilk bakışta göz korkutucu görünebilir. Ancak süreci adımlara böldüğünüzde aslında yapılacaklar oldukça net:

• Alan adlarının gerçek kayıt sahiplerini, işlevlerini ve sorumlularını ortak envanterde tutun.
• Önceliği web trafiğiyle sınırlamayın; e-posta, yönlendirme ve kurtarma bağımlılıklarını inceleyin.
• Yenileme kararı, izin verilen işlem aralığı ve başarılı tamamlanmayı ayrı takip edin.
• Faturayı doğru maliyet merkezi, ödeme ve onay kaydıyla eşleştirin.
• Marka korumasını gerçek risk ve ilgili TLD kurallarıyla değerlendirin.
• Registrar iletişim verilerini, MFA’yı, transfer kilidini, DNSSEC durumunu ve bağımsız kurtarma yolunu kontrol edin.
• Transfer veya kullanım dışı bırakma öncesinde sahiplik, yetki ve hizmet bağımlılıklarını doğrulayın.

İlk incelemede en yakın son tarihlere ve kritik hizmetlere odaklanın. Ardından kayıtları, sorumluları ve düzenli kontrol takvimini tamamlayın. Sağlayıcı değişikliği düşünüyorsanız gerekli hizmetleri ve yetkileri listeleyip hangi kapsamın hangi koşullarda desteklendiğini teyit edin. Her yenileme, devir ve erişim değişikliğinden sonra envanteri doğrulayarak güncelleyin.