Yeni bir müşteriyle anlaştığınızda, tasarım, içerik ve reklam stratejileri kadar kritik bir konu daha masaya gelir: mevcut hosting ve DNS altyapısı. İlk aylarda yaşanan performans sorunları, e‑posta problemleri veya kesintiler, mevcut teknik borçtan ve dağınık DNS ayarlarından kaynaklanabilir. Standartlaştırılmış bir hosting ve DNS denetim listesi, bu riskleri proje başlamadan belirlemeye ve ajansınızın operasyonunu planlamaya yardımcı olur.
Bu yazıda, ajansların yeni müşteri alırken kullanabileceği detaylı ve uygulanabilir bir kontrol listesi paylaşacağız. Amaç; her yeni müşteri için aynı soruları sormak, aynı adımları izlemek ve altyapıyı netleştirmeden kampanya ya da geliştirme sürecine başlamamaktır. Böylece müşteriye yapılandırılmış bir onboarding süreci sunar; ileride yaşanabilecek SEO kayıpları, e‑posta teslim problemleri, DNS hataları ve beklenmedik kesinti risklerini azaltabilirsiniz.
Neden Standart Bir Denetim Listesine İhtiyacınız Var?
Ajans perspektifinden bakınca, her müşterinin hosting ve DNS geçmişi farklıdır: Kiminde yıllar önce açılmış paylaşımlı bir hosting hesabı, kiminde yurt içinde bir sağlayıcı, kiminde ise karma bir mimaride dağınık DNS kayıtları bulunur. Eğer bu tabloyu en başta netleştirmezseniz, proje ilerledikçe karşınıza şu baş ağrıtan durumlar çıkabilir:
- Alan adı başka bir firmada, DNS başka yerde, hosting bambaşka bir sunucuda; kimsenin tam hakim olmadığı dağınık yapı
- Reklam kampanyalarına başlamışken çalışmayan formlar ve spam klasörüne düşen e‑postalar
- Yanlış TTL ve plansız DNS değişiklikleri nedeniyle uzun süren DNS yayılım sorunları
- Yedekleme politikası olmayan sunucular ve ufak bir hata sonrası geri dönemediğiniz web siteleri
Bu yazıdaki kontrol listesini ajansınızın kendi dokümantasyonuna entegre edip, örneğin yeni müşteri onboarding dosyanızda bir sayfa olarak tutabilirsiniz. DNS tarafını daha derinlemesine anlamak için, müşterinin mevcut kayıtlarını incelerken DNS kayıtları A’dan Z’ye rehberimizi yan sekmede açık tutmanız da işinizi kolaylaştırır.
Adım 1: Alan Adı ve Mülkiyet Kontrolleri
Whois ve kayıt kuruluşu bilgilerini netleştirin
Her şey alan adıyla başlar. İlk toplantıda müşteriden mutlaka ana alan adlarını (ör. example.com, example.com.tr) isteyin ve şu soruları sorun:
- Alan adları hangi firmada kayıtlı? (Kayıt operatörü / registrar)
- Kimin hesabında duruyor? Gerçek kişi mi, şirket hesabı mı?
- Kayıt kuruluşu panelindeki alan adı sahibi ve iletişim bilgileri doğru mu? Kamuya açık Whois bilgilerinde görünmeyen alanları da yetkili hesap üzerinden doğrulayabiliyor musunuz?
Bir alan adı transferi planlarken, alan adı taşırken e‑posta kesintisini önlemek rehberindeki önerileri geçiş planınıza dahil ederek e‑posta kesintisi riskini azaltabilirsiniz.
Yetkili kişi ve iletişim kanallarını belirleyin
Alan adını yönetecek asıl yetkili kişi ve e‑posta adresi mutlaka net olmalı. Sık yapılan hatalardan bazıları:
- Eski bir çalışan üzerine açılmış alan adı hesapları
- Artık aktif olmayan info@… veya kişisel e‑posta adresleri
- Farklı şirketler adına açılmış, ama birleşmiş veya devrolmuş markalar
Onboarding formunuza şu alanları ekleyebilirsiniz:
- Alan adı yönetim paneli adresi
- Kullanıcı adı / ID (şifreyi asla maille istemeyin, güvenli paylaşım araçlarını tercih edin)
- Yetkili kişi adı, soyadı, telefon ve iş e‑posta adresi
Ajans perspektifinden bakınca, en sağlıklısı, alan adının mülkiyetinin her zaman müşteriye ait olması, DCHost veya başka bir sağlayıcıda olsa bile panel erişimlerinin müşteride kalmasıdır. Siz ise ajans olarak teknik kullanıcı veya ikincil iletişim noktası olarak tanımlanabilirsiniz.
Adım 2: DNS Altyapısı ve Kayıtların Analizi
Nameserver yapısı ve DNS sağlayıcısını tespit edin
İkinci adım, alan adının hangi nameserver’ları kullandığını anlamaktır. Bunun için alan adının NS kayıtlarına bakın ve şu soruları cevaplayın:
- DNS, alan adı registrar’ında mı tutuluyor, yoksa ayrı bir DNS sağlayıcısı mı kullanılıyor?
- DNS ile hosting aynı yerde mi, yoksa ayrılmış bir mimari mi var?
- Nameserver’lar yedekli ve farklı IP bloklarında mı konumlanmış?
Ajanslar için sağlıklı model, DNS’in merkezi ve yönetilebilir bir yerde olması ve kimlerin erişimi olduğu bilgisinin dokümante edilmesidir. Bu noktada, ajans ekibinizin erişimlerini nasıl yöneteceğiniz konusunda, ajanslar için DNS ve alan adı erişimi yönetimi rehberimiz pratik bir çerçeve sunuyor.
Temel DNS kayıtlarını envanterleyin
Yeni bir müşteri için DNS envanteri çıkarmadan hiçbir değişiklik yapmayın. Özellikle şu kayıtları mutlaka listeleyin:
- Web sitesi için A ve/veya AAAA kayıtları
- www alt alan adı için CNAME veya A kaydı
- MX kayıtları (e‑posta altyapısı)
- TXT kayıtları (SPF, doğrulama kayıtları, 3. parti servisler)
- Özel subdomain’ler (app., api., panel., mail. vb.)
Bu listeyi bir tabloya aktarıp, her kayıt için şu sütunları eklemeniz işinizi kolaylaştırır:
- Alt alan adı (host)
- Kayıt türü (A, AAAA, CNAME, MX, TXT vb.)
- Değer (IP, hedef domain vb.)
- TTL
- Açıklama (“Kurumsal site”, “Eski CRM”, “Kullanılmıyor” vb.)
Özellikle yıllardır gözden geçirilmemiş DNS bölgelerinde, kullanılmayan veya boşta kalmış subdomain kayıtlarını güvenlik açısından değerlendirin. Subdomain takeover ve boşta kalan DNS kayıtları yazımızda anlattığımız gibi, kullanılmayan fakat hala canlı görünen alt alanlar ciddi güvenlik açığı yaratabilir.
TTL, yayılım ve değişiklik stratejisini planlayın
Ajanslar için en kritik pratiklerden biri, DNS değişikliklerine önceden TTL planlaması ile hazırlanmaktır. Yeni bir projede:
- Taşıma veya büyük bir DNS değişikliği planlıyorsanız, değişecek kayıtların TTL değerini geçişten en az bir mevcut TTL süresi önce düşürün (örneğin 3600 sn → 300 sn). Birkaç günlük hazırlık ancak mevcut TTL süresini karşılıyorsa yeterlidir.
- Geçiş tamamlanıp her şey yoluna girdikten sonra TTL değerlerini tekrar yükseltin (örn. 4–6 saat).
Bu yaklaşım, zero-downtime taşıma için TTL stratejileri yazımızda detaylandırdığımız kesintisiz geçiş mantığının temelidir. Ajans içi prosedürünüze “DNS değişikliği öncesi TTL düşürme” adımını mutlaka ekleyin.
Adım 3: E‑Posta Altyapısı ve Gönderim İtibarı
MX kayıtlarını ve mimariyi anlayın
E‑posta altyapısı çoğu müşteri için web sitesinden bile kritiktir. Bu yüzden MX kayıtlarına çok dikkatli bakın:
- MX kayıtları hangi sunucuları işaret ediyor? (mail.marka.com mu, dış servis mi, hibrit yapı mı?)
- Birden fazla MX kaydı varsa öncelik (priority) değerleri doğru mu ayarlanmış?
- Backup MX veya yedekli bir e‑posta altyapısı var mı?
Ajanslar için pratik bir yaklaşım, müşterinin iş sürekliliği beklentisine göre e‑posta mimarisini netleştirmektir. Daha karmaşık yapılarda, birden fazla MX kaydı ve backup MX gibi stratejiler devreye girebilir.
SPF, DKIM ve DMARC kayıtlarını kontrol edin
Müşterinizin pazarlama, transactional (sipariş, bildirim) ve kurumsal e‑postalarının kimlik doğrulamasında üç mekanizma kritik önem taşır. Bunların doğru yapılandırılması, tek başına spam klasörüne düşmeyi önlemez:
- SPF: Gönderen IP adresinin SMTP zarfındaki MAIL FROM veya HELO alan adı için yetkili olup olmadığını denetler; görünen From adresini doğrudan doğrulamaz.
- DKIM: Seçili başlıkları ve ileti gövdesini kriptografik olarak imzalar. Başarılı doğrulama, imzalanan bölümlerin DKIM’in normalleştirme kuralları kapsamında korunduğunu gösterir; içeriğin güvenli olduğunu kanıtlamaz.
- DMARC: Görünen From alan adıyla hizalanmış en az bir başarılı SPF MAIL FROM veya DKIM sonucu arar; SPF’nin HELO sonucu DMARC için kullanılmaz. Bu koşul sağlanmazsa alan adı sahibinin talep ettiği işlem politikasını bildirir; nihai karar alıcıya aittir.
Yeni müşteri denetim listesine şu soruları ekleyin:
- SPF kaydı var mı, geçerli mi? İç içe değerlendirmeler dahil DNS sorgusu gerektiren include, a, mx, ptr, exists ve redirect terimleri için toplam 10 sınırı aşılıyor mu?
- DKIM imzası aktif mi, anahtar uzunluğu güncel en iyi pratiklere uygun mu?
- DMARC kaydı var mı, politika (none/quarantine/reject) ne durumda?
Birden fazla e‑posta servisi kullanılan yapılarda, SPF kaydı karmaşıklaşır. Bunun için gelişmiş SPF yönetimi rehberimizi kontrol listesine referans olarak ekleyebilirsiniz.
Adım 4: Hosting Tipi, Kaynaklar ve Erişim Modeli
Mevcut hosting türünü ve kapasitesini analiz edin
Yeni müşterinizin web sitesi veya uygulaması şu ortamlardan herhangi birinde olabilir:
- Klasik paylaşımlı hosting
- Reseller (bayi) hosting
- VPS (sanal sunucu)
- Dedicated (fiziksel) sunucu
- Veri merkezinde colocation ile barındırılan kendi fiziksel sunucusu
Ajans için önemli olan, mevcut mimarinin planlanan trafiğe, büyüme hedeflerine ve entegrasyonlara uygun olup olmadığını değerlendirmektir. Bir müşteride onlarca site veya mikro proje barındıracaksanız, ajans odaklı bir mimari için ajanslar ve freelancerlar için hosting mimarisi rehberindeki önerileri dikkate alabilirsiniz.
Ajanslar, müşteri ihtiyaçlarına uygun hosting türlerini seçerken DNS yönetimi, yedekleme ve erişim yetkilerinin ortak prosedürlerle yönetilip yönetilemeyeceğini değerlendirmelidir. Tek platform kullanımı, bu süreçlerin kendiliğinden standartlaşacağı anlamına gelmez.
Panel, SFTP/SSH ve ajans erişimini standartlaştırın
Denetim listesinde mutlaka şu erişim kalemleri olsun:
- Hangi kontrol paneli kullanılıyor? (cPanel, DirectAdmin, Plesk veya panelsiz VPS)
- FTP mi yoksa SFTP/SSH mi kullanılıyor? (Güvenlik için SFTP/SSH önerin)
- Ajans için ayrı kullanıcı hesapları açılmış mı, yoksa müşterinin ana hesabı mı kullanılıyor?
Ajans ekibi için uygun bir yaklaşım; müşteri hesaplarını birbirinden ayırmak ve kullanılan panelin desteklediği ölçüde ajans personeline özel, görevleriyle sınırlı yetkilere sahip kişisel kullanıcılar tanımlamaktır. Her müşteri için ayrı VPS gerekip gerekmediği ise izolasyon ve kaynak ihtiyaçlarına bağlıdır. Bu konuda adım adım bir çerçeveye ihtiyaç duyuyorsanız, ajanslar için hosting paneli erişim yönetimi rehberimiz size uygulanabilir bir model sunar.
Adım 5: Güvenlik, SSL ve DDoS Perspektifi
SSL/TLS sertifikası ve HTTPS durumunu kontrol edin
Yeni müşteri sitelerinde kontrol edilmesi gereken olası problemler:
- Süresi dolmak üzere olan veya çoktan süresi dolmuş SSL sertifikaları
- HTTP’den HTTPS’e eksik veya yanlış yönlendirmeler
- Mixed content uyarıları (güvensiz http içerik çağrıları)
Denetim listenize şu maddeleri ekleyin:
- Alan adı için geçerli bir SSL sertifikası var mı?
- www / non-www ve web hizmeti sunan diğer alt alanlar doğru şekilde HTTPS’e yönlendiriliyor mu?
- HSTS (HTTP Strict Transport Security) kullanılıyorsa politika süresi kontrol edildi mi? Politikanın kapsadığı tüm web alanları, alt alanlar dahil ediliyorsa onlar da, geçerli HTTPS hizmetini sürdürebiliyor mu? Etkinleştirme düşünülüyorsa önce bu koşulları doğrulayın.
SSL tarafındaki kronik hataları çözmek için, özellikle lansman öncesi SSL sertifika hataları rehberimizi kontrol eden bir ekip üyesi atamanız çok faydalı olur.
Alan adı ve DNS güvenliğini değerlendirin
Müşterinizin markası büyüdükçe alan adı, şirketin en kritik dijital varlıklarından biri haline gelir. Şu başlıkları mutlaka kontrol edin:
- Alan adı için transfer kilidi (Registrar Lock) açık mı?
- Mümkünse DNSSEC etkin mi? (DNS cevaplarının bütünlüğü için)
- DNS paneline erişimlerde 2FA (iki aşamalı doğrulama) kullanılıyor mu?
- Hosting veya CDN sağlayıcısının DDoS koruma kapsamı, hizmet sınırları ve saldırı sırasında iletişime geçilecek sorumlu belgelendi mi?
Daha kurumsal yapılarda, alan adı güvenliği rehberimiz ajansın müşteriye sunabileceği ekstra danışmanlık adımlarını da içeriyor. Bunları onboarding sürecinde teklif ederek hem güvenlik seviyesini yükseltebilir, hem de katma değerli hizmetlerinizi artırabilirsiniz.
Adım 6: Yedekleme, Felaket Kurtarma ve Taşıma Hazırlığı
Mevcut yedekleme politikasını çıkarın
Yeni müşteriyle çalışmaya başlamadan önce şu soruları mutlaka sorun:
- Hosting sağlayıcısının otomatik yedeği var mı, hangi sıklıkta alınıyor?
- Yedekler nerede saklanıyor? Aynı sunucuda mı, farklı bir depolama alanında mı?
- Yedeklerden geri dönüş hiç test edilmiş mi, edilmediyse plan var mı? Geri yükleme testini izole bir test ortamında, dışarıya e-posta gönderimi, ödeme işlemleri ve üretim entegrasyonları devre dışıyken yapın; geri yüklenen verileri ve uygulamanın çalışmasını doğrulayın.
Ajans olarak kendi bağımsız yedekleme stratejinizi kurmanız da iyi bir pratiktir. Onboarding için asgari standart olarak en az günlük yedeklemeyi ve en az bir tesis dışı yedek kopyasını benimseyebilirsiniz. Örneğin, seçilen planın yedek dışa aktarma ve otomasyon olanakları uygunsa VPS veya hosting hesaplarından harici object storage’a günlük yedek kopyaları aktarabilir, geri dönüş testlerini düzenli planlayabilirsiniz. Harici depolamanın gerçekten tesis dışında olup olmadığını doğrulayın; sıklığı müşterinin RPO hedefine göre artırın.
Gelecekteki geçiş ve ölçeklenme planını konuşun
Yeni müşterinin mevcut hosting altyapısı bugün idare ediyor olabilir, ancak planlanan trafik, içerik ve kampanya artışları yükü ciddi şekilde artırabilir. Bu yüzden daha ilk toplantılarda:
- Önümüzdeki 6–12 ay için trafik ve büyüme hedeflerini
- Planlanan kampanya dönemlerini (Black Friday, lansmanlar, yoğun sezonlar)
- Muhtemel yeni projeleri (yeni mikro siteler, kampanya sayfaları, SaaS panelleri vb.)
konuşup not almakta fayda var. Özellikle yoğun kampanya dönemlerine hazırlık için, yoğun trafikli kampanyalar için hosting ölçeklendirme rehberimiz ajansların müşteriye sunabileceği net kapasite planlama adımlarını içeriyor.
Pratik Örnek: Ajans Onboarding Dosyanız İçin Örnek Kontrol Listesi
Aşağıdaki listeyi, ajansınızın onboarding şablonuna birebir ekleyebilir veya kendi süreçlerinize göre uyarlayabilirsiniz. Her yeni müşteri için bu listeyi doldurmak, sonraki teknik işler için ortak bir referans oluşturur.
1. Alan adı ve mülkiyet
- Ana alan adları (com, com.tr vb.) listelendi
- Alan adı hangi firmada kayıtlı, panel adresi ve hesap sahibi not edildi
- Kamuya açık Whois bilgilerinde görülebilen şirket ve iletişim bilgileri kontrol edildi; eksik veya gizli bilgiler için kayıt kuruluşu panelindeki bilgiler yetkili kişiyle doğrulandı
- Registrar Lock (transfer kilidi) açık mı kontrol edildi
- Ajansın teknik kullanıcı/iletişim bilgileri sisteme eklendi
2. DNS altyapısı
- Mevcut nameserver’lar ve DNS sağlayıcısı kaydedildi
- Tüm A, AAAA, CNAME, MX, TXT, SRV ve önemli subdomain kayıtları envanterlendi
- Kullanılmayan veya riskli subdomain kayıtları işaretlendi
- Önemli kayıtlar için mevcut TTL değerleri not edildi
- Planlanan taşıma/değişiklikler için TTL düşürme/geri yükseltme planı oluşturuldu
3. E‑posta ve teslim edilebilirlik
- MX kayıtları ve e‑posta sağlayıcısı netleştirildi
- SPF kaydı var, geçerli ve 10 lookup limitine takılmıyor
- DKIM imzası aktif, anahtar uzunluğu güncel
- DMARC kaydı mevcut, politika seviyesi müşteriyle konuşuldu (none/quarantine/reject)
- Önemli e‑posta adresleri (info@, destek@, satış@ vb.) ve sorumluları listelendi
4. Hosting türü, kaynaklar ve erişim
- Mevcut hosting türü (paylaşımlı, reseller, VPS, dedicated, colocation) belirlendi
- CPU, RAM, disk ve trafik limitleri not edildi
- Kullanılan kontrol paneli (cPanel, DirectAdmin, Plesk veya yok) listelendi
- Ajans için ayrı kullanıcı hesapları tanımlandı veya planlandı
- FTP yerine SFTP/SSH erişimi kullanılması kararlaştırıldı
5. Güvenlik ve SSL
- Alan adının geçerli bir SSL sertifikası olduğu doğrulandı
- HTTP → HTTPS yönlendirmeleri test edildi, www/non‑www tutarlı hale getirildi
- Mixed content problemleri için hızlı bir tarama yapıldı
- Alan adı için mümkünse DNSSEC etkinleştirme planlandı
- DNS ve panel erişimlerinde 2FA kullanımı kontrol edildi
6. Yedekleme ve felaket kurtarma
- Hosting sağlayıcısının yedekleme politikası (sıklık, saklama süresi) öğrenildi
- Yedeklerin nerede saklandığı ve nasıl geri dönüleceği test edildi veya planlandı
- Ajansın bağımsız yedekleme stratejisi (harici depolama, object storage vb.) belirlendi
- Felaket senaryosu için kabul edilebilir azami veri kaybı süresi (RPO) ve hizmeti geri getirme süresi (RTO) hedefleri müşteriyle belirlendi
Sonuç: Ajanslar İçin Tekrarlanabilir Bir Hosting ve DNS Süreci Kurmak
“Kimsenin tam hakim olmadığı” altyapılarla çalışmak, ajanslar için teknik belirsizlik yaratır. Bu yazıda paylaştığımız hosting ve DNS denetim listesini her yeni müşteri için sistematik olarak uyguladığınızda, daha proje başlamadan riskleri görür, sorumlulukları netleştirir ve müşteriye güven veren bir teknik çerçeve sunarsınız. Alan adı mülkiyetinden DNS kayıtlarına, e‑posta teslim edilebilirliğinden SSL ve yedeklemeye kadar her kalemi baştan konuşmak, ileride yaşanabilecek krizleri önlemeye ve müdahale sorumluluklarını belirlemeye yardımcı olur.
Ajansınız büyüdükçe müşterilerinizi ortak bir yönetim modelinde toplamak isterseniz, reseller hosting, VPS, dedicated sunucu ve colocation seçeneklerini bu listedeki kaynak, erişim ve yedekleme gereksinimlerine göre karşılaştırın. Teknik ekibinizle birlikte, bu yazıdaki maddeleri kendi iç prosedürünüze dönüştürün ve her yeni projede aynı adımları tekrarlayın. Bu kayıtlar, ekibin ve müşterinin hangi kontrollerin tamamlandığını ve hangi işlerin açık kaldığını takip etmesini sağlar.
