Teknoloji

Reseller Hosting Yönetimi Rehberi: Paketler, Limitler ve İzolasyon

Reseller hosting yönetimi neden kritik?

Reseller hosting ile gelir modelinizi büyütmek istiyorsanız, teknik altyapı kadar önemli olan bir nokta var: yönetim kalitesi. Aynı sunucu üzerinde onlarca, hatta yüzlerce müşteri sitesi barındırırken; yanlış yapılandırılmış bir paket, eksik limitler veya zayıf izolasyon hem performansı hem de itibarı doğrudan etkiler. Tek bir hesabın CPU’yu sömürmesi, spam gönderen bir müşterinin tüm IP itibarını çökertmesi veya hacklenen bir sitenin diğer hesaplara sıçraması; zayıf yönetilen reseller altyapılarında çok sık gördüğümüz problemler.

DCHost tarafında onlarca ajans, freelancer ve SaaS geliştiricisiyle çalışırken şunu çok net görüyoruz: Başarılı reseller işletmeleri, teknik olarak iyi kurgulanmış paketlere ve tutarlı limit/izolasyon politikalarına sahip olanlar. Bu rehberde, reseller hesabınızı sadece “hesap aç-kapat” düzeyinde değil, gerçekten sürdürülebilir ve ölçeklenebilir bir iş olarak yönetebilmeniz için sahada işe yarayan yaklaşımları paylaşacağız. Paket tasarımından CPU/IO limitlerine, e-posta gönderim kurallarından müşteri izolasyonu ve yedeklemeye kadar somut öneriler bulacaksınız.

Reseller modeline konsept düzeyinde yeniyseniz, önce reseller hosting ile kârlı iş modeli kurma rehberimize göz atmanız, işin ticari tarafını netleştirmenize yardımcı olacaktır. Bu yazıda ise doğrudan teknik ve operasyonel yönetim tarafına odaklanıyoruz.

Altyapı ve kontrol panelini doğru seçmek

Sağlıklı bir reseller yapısının temeli, oturduğu altyapı ve kontrol panelidir. Kontrol paneli tarafında en yaygın seçenekler cPanel/WHM, DirectAdmin ve Plesk’tir. Her birinin lisans modeli, kaynak tüketimi ve özellik seti farklıdır; özellikle uzun vadeli ölçeklenme planlıyorsanız, bu seçim doğrudan maliyet ve yönetim modelinize yansır.

Farklı panelleri değerlendirme aşamasındaysanız, reseller hosting için doğru kontrol panelini seçme rehberimizde her panelin güçlü ve zayıf yönlerini detaylı karşılaştırdık. Burada, hangi paneli kullanırsanız kullanın geçerli olan prensiplere odaklanacağız.

Ajans, freelancer ve SaaS için farklı beklentiler

Reseller hosting kullanıcısı profiliniz, yönetim yaklaşımınızı doğrudan belirler:

  • Ajanslar: Çok sayıda küçük/orta ölçekli site, sık tasarım değişiklikleri, staging ortam ihtiyacı, zaman zaman yüksek trafikli kampanyalar.
  • Freelancer geliştiriciler: Daha sınırlı sayıda müşteri, teknik seviyeleri karışık, destek süreçlerini tek başına yürütme zorunluluğu.
  • SaaS projeleri: Uygulama merkezli yük, veritabanı yoğunluğu, arka planda cron job’lar ve API trafiği.

Bu profili doğru tanımlarsanız; paket sayısını, her paketin kaynaklarını ve limit politikanızı ona göre kurgulamanız çok daha kolay olur.

Paket oluşturma stratejisi: Kaynak ve fiyat dengesini kurmak

Paket oluştururken en sık gördüğümüz hata, “piyasadaki planlara bakıp” disk ve trafik rakamlarını kopyalamak. Oysa sürdürülebilir bir reseller modeli için, kendi müşteri kitlenize ve maliyetlerinize göre bir çerçeve çizmeniz gerekiyor.

Adım adım paket tasarlama

Pratik bir yaklaşım için şu adımları kullanabilirsiniz:

  1. Hedef müşteriyi tanımlayın: Ağırlıklı olarak kurumsal vitrin siteleri mi, içerik ağırlıklı bloglar mı, yoksa e-ticaret projeleri mi host edeceksiniz?
  2. Ortalama kaynak kullanımını tahmin edin: Var olan siteleriniz veya benzer projeler üzerinden; ortalama disk kullanımını, aylık trafik miktarını ve CPU/IO kullanımını analiz edin.
  3. Kademe yapısını belirleyin: Örneğin “Başlangıç / Standart / Profesyonel” gibi 3 kademeli bir yapı; hem satış hem de kaynak yönetimi açısından sade ve etkilidir.
  4. Her paket için temel metrikleri tanımlayın: Disk alanı, trafik, barındırılabilecek alan adı sayısı, e-posta hesap sayısı, veritabanı sayısı, yedekleme ve SSL politikası gibi.
  5. Overselling politikanızı belirleyin: Tamamen konservatif (overselling yok) bir model mi, yoksa güvenli oranlarla overselling yapacağınız bir model mi?

Kaynak planlarken, uzun vadeli maliyetleri de düşünmek önemli. Reseller hesabınız büyüdükçe, bir noktada VPS veya fiziksel sunucuya geçip kendi kaynak havuzunuzu yönetmek isteyebilirsiniz. Bu geçiş aşamasında doğru boyutlandırma için trafik ve depolamaya göre hosting maliyeti planlama rehberimizdeki yaklaşım işinizi kolaylaştıracaktır.

Panel üzerinde paketleri tanımlarken dikkat edilecek noktalar

cPanel/WHM veya benzeri bir panel kullanıyorsanız, paket (package) tanımlarken şu başlıkları mutlaka netleştirin:

  • Disk alanı: “Sınırsız” iddiasından kaçının. Kayıtların, yedeklerin ve e-postaların da aynı diskten yediğini unutmayın. Örn. küçük projeler için 2–5 GB, orta ölçek için 5–10 GB, daha üst için 10–20 GB mantıklı başlangıç aralığı olabilir.
  • Aylık bant genişliği (trafik): Gerçek kullanım istatistiklerine göre esnek ama kontrollü limitler koyun. Gerektiğinde ek trafik satışı yapabileceğiniz bir model düşünün.
  • Addon / parked domain limitleri: Birden çok siteyi aynı hesapta toplamayı teşvik etmek, izolasyonu zayıflatır. Mümkünse her site için ayrı cPanel hesabı kullanın; addon domain kullanımını düşük tutun.
  • Veritabanı ve e-posta limiti: Bu limitler, “kaynak suistimalini” engellemek için iyi bir araçtır. Örneğin, giriş seviye pakette 5–10 e-posta hesabı ve 3–5 veritabanı çoğu küçük işletme için yeterlidir.
  • Features (özellik listesi): SSH erişimi, cron job, Git entegrasyonu, otomatik yedek geri yükleme gibi özellikleri paketlere göre kademelendirmek hem güvenlik hem de satış tarafında faydalıdır.

Bu temel limitler, bir sonraki aşamada uygulayacağınız CPU/RAM/IO gibi daha teknik kaynak kotalarıyla beraber düşünülmelidir.

Limitlendirme en iyi uygulamalar

Limitler, reseller hosting yönetiminin omurgasıdır. Doğru konulmayan limitler iki uç problem doğurur: Ya performans sürekli sorun olur, ya da gereğinden ağır kısıtlamalarla müşterileri rahatsız edersiniz. Burada amaç, hesapların birbirini rahatsız etmesini önleyecek kadar sıkı, ama gerçekçi kullanım senaryolarını engellemeyecek kadar esnek limitler koymaktır.

CPU, RAM, IO ve eşzamanlı süreç limitleri

CloudLinux benzeri bir izolasyon katmanı kullanıyorsanız, her cPanel hesabı için LVE (Lightweight Virtual Environment) limitleri belirleyebilirsiniz. Kullanmasanız bile genel prensip aynı: Kaynakların hiçbir hesabın tek başına tüketemeyeceği şekilde bölünmesi.

cPanel üzerinden hesap bazlı kaynak tüketimi ve kısıtlamalar hakkında ayrıntılı bilgi için cPanel’de kaynak limitleri ve “Resource Limit Reached” hatası rehberimize mutlaka göz atın. Oradaki rakamsal önerileri reseller planlarınıza uyarlayabilirsiniz.

Başlangıç için şu tür değerler çoğu küçük/mid düzey site için makul bir çerçeve olabilir (örnek değerlerdir, iş yüküne göre güncellenmelidir):

  • CPU: 50–100% (1 vCPU’ya eşdeğer) – yoğun WooCommerce gibi siteler için üst pakette 150–200%.
  • RAM: 512 MB – 1 GB aralığı, daha yoğun siteler için 1–2 GB.
  • IO: 5–10 MB/s aralığı, IO yoğun iş yüklerinde 20 MB/s ve üzeri.
  • EP (Entry Process / eşzamanlı PHP süreçleri): 10–20 aralığı, trafik artarsa üst paketlerde 30–40.

Önemli olan, bu değerleri kaba bir tahminle bırakmamak. İlk aylarda izleyip; hangi müşterilerin sürekli limite takıldığını, hangilerinin neredeyse hiç kullanmadığını analiz ederek paketlerinizin değerlerini revize etmeniz gerekir.

PHP ve MySQL tarafında dengeli kısıtlar

Yalnızca CPU/RAM limitleri değil, PHP ayarları da (memory_limit, max_execution_time, max_input_vars, upload_max_filesize vb.) müşteri deneyimini doğrudan etkiler. Örneğin:

  • Küçük kurumsal siteler için PHP memory_limit değerini 128–256 MB aralığında tutmak çoğu zaman yeterli olur.
  • Yoğun eklenti kullanan WooCommerce sitelerinde 256–512 MB mantıklıdır; ancak bu siteleri genelde daha yüksek paketlere ya da doğrudan kendi VPS’lerine taşımayı da planlamalısınız.
  • max_execution_time için 60–120 sn aralığı, bakım işlemlerinde sorun yaşamamak adına iyi bir dengedir; çok uzun süreli script çalıştırma ihtiyacı varsa, bunu özel istisna olarak yönetmek daha doğrudur.

MySQL tarafında ise, her müşteri için ayrı kullanıcı ve veritabanı şeması kullanmak, yetkileri kısıtlamak ve gereksiz “GLOBAL” yetkiler vermemek temel güvenlik şartıdır. Ayrıca sorgu optimizasyonu yapılmamış ağır uygulamalar tespit edildiğinde, müşteriye danışmanlık verip (gerekirse ek ücretle) optimizasyon süreci teklif etmek; hem sizin hem de müşterinizin kazanacağı bir yaklaşımdır.

E-posta limitleri ve IP itibarını korumak

Reseller altyapılarında en sık ihmal edilen, ama en büyük zararı veren alanlardan biri de e-posta yönetimidir. Tek bir hesabın toplu bülten veya spam göndermesi, tüm IP adresinin kara listeye girmesine yol açabilir.

Bu nedenle:

  • Hesap başına saatlik/ günlük e-posta gönderim limitleri belirleyin (örneğin 200–300 mail/saat gibi).
  • Toplu mailing ve pazarlama e-postaları için müşterilerinizi, özel e-posta hizmetlerine veya kendi IP’sine sahip ayrı bir sunucuya yönlendirin.
  • Zorunlu SPF, DKIM ve tercihen DMARC kaydı kullanımını teşvik edin. Bu konuda adım adım teknik kurulum için SPF, DKIM, DMARC ve rDNS ile e-posta teslim edilebilirliğini artırma rehberimizden faydalanabilirsiniz.
  • Şüpheli gönderimlerde, ilgili hesabı hızlıca sınırlayıp logları inceleyin; çoğu zaman hacklenmiş bir WordPress veya kötü yapılandırılmış bir form script’i kaynağı oluşturur.

Müşteri izolasyonu: Güvenlik ve performans açısından zorunluluk

Reseller hosting’in en kritik yönetim konusu, müşteri hesaplarının birbirinden izole olmasıdır. Aynı sunucu üzerinde çok kiracılı (multi-tenant) bir mimari yürüttüğünüz için, tek bir zayıf halka tüm yapıyı etkileyebilir. İzolasyon sadece güvenlik açısından değil; performans ve hata ayıklama tarafında da büyük kolaylık sağlar.

Dosya sistemi ve hesap izolasyonu

İyi izole edilmemiş ortamlarda, bir kullanıcının başka hesapların dosyalarını okuması veya sembolik link açıklarından faydalanması gibi riskler ortaya çıkar. Bu nedenle:

  • “chroot” veya benzeri dosya sistemi izolasyonu sağlayan çözümleri aktif tutun (CageFS vb.).
  • PHP handler seçimini yaparken, kullanıcı bazlı çalışabilen ve dosya izinlerini daha güvenli kılan yöntemleri tercih edin (örn. lsapi, php-fpm + doğru user mapping).
  • Her alan adını mümkün olduğunca ayrı bir cPanel hesabında barındırın; tek hesabın altına onlarca site yığılmasını önleyin.

Bu yaklaşım, olası bir hack durumunda hasarı tek hesapla sınırlamanızı ve ilgili müşteriyi hızlıca başka bir sunucuya taşıyabilmenizi de kolaylaştırır.

Veritabanı, PHP ve süreç izolasyonu

İzolasyonun ikinci katmanı, veritabanı ve PHP süreçleridir. Aşağıdaki prensipleri standart hale getirmekte fayda var:

  • Her site için ayrı bir veritabanı ve kullanıcı oluşturun; aynı kullanıcıyı birden çok veritabanına geniş yetkilerle bağlamaktan kaçının.
  • PHP-FPM havuzlarını kullanıcı bazlı çalıştırarak, süreçlerin birbirinden ayrılmasını sağlayın.
  • Geliştirici müşteriler için SSH erişimi verecekseniz, mutlaka jailed shell gibi kısıtlı bir ortamda sunun.

Bu sayede hem performans sorunlarını tek tek hesap bazında tespit eder, hem de olası zararlı script’lerin diğer hesaplara yayılmasını önemli ölçüde engellersiniz.

Güvenlik sertleştirme ve WAF katmanı

Reseller ortamında, sizin kontrolünüz dışında yüzlerce tema ve eklenti kurulacaktır. Bu kaçınılmaz. Bu yüzden panel ve sunucu tarafında güvenlik sertleştirme uygulamalarını ihmal etmemeniz gerekiyor. cPanel servisleri, SSH, FTP ve PHP yapılandırmasını güvenli hale getirmek için hazırladığımız cPanel güvenlik sertleştirme kontrol listemizde pratik bir kontrol listesi bulacaksınız.

Bunlara ek olarak:

  • Web Application Firewall (WAF) kullanarak bilinen saldırı kalıplarını (SQL injection, XSS vb.) panel seviyesinde filtreleyin.
  • Otomatik malware taraması ve karantina araçları kullanın; özellikle WordPress siteleri için sık tarama planı oluşturun.
  • PHP versiyonlarını güncel tutun, eski ve desteklenmeyen sürümleri kapatın; ihtiyaç duyan müşterilere paket bazlı kontrollü “eski sürüm” erişimi tanımlayın.

Operasyonel yönetim: İzleme, yedek ve ölçeklendirme

Teknik olarak doğru paket ve limitleri tanımlamak ilk adımdır. Asıl sürdürülebilirlik, günlük operasyonu ne kadar görünür ve tekrarlanabilir hale getirdiğinizle ilgilidir. İzleme, yedekleme ve ölçeklendirme planı olmayan reseller yapıları, büyüdükçe kontrolü kaybeder.

Kaynak kullanımını izlemek ve erken uyarılar

Şu üç şeyi düzenli takip etmek, sorunların çoğunu daha kullanıcı şikâyetine dönüşmeden yakalamanızı sağlar:

  • Sunucu genel durumu: Load average, IO bekleme süreleri, bellek kullanımı, disk doluluk oranı.
  • Hesap bazlı tüketim: Hangi hesapların sürekli CPU/IO limitine takıldığı, hangilerinin disk kotasını zorladığı.
  • Log ve hata oranları: HTTP 5xx hataları, PHP fatal error logları, MySQL slow query log’ları.

Basit bir politika olarak; belirli eşiği geçen hesaplar için otomatik uyarı maili atabilir, ardından müşteriye “optimizasyon” veya “üst pakete geçiş” öneren bir süreç tasarlayabilirsiniz. Bu hem performans sorunlarını azaltır hem de ek satış fırsatları doğurur.

Yedekleme stratejisi: Sadece var olmak yetmez, gerçekten işe yaramalı

Reseller düzeyinde yedekleme, yalnızca günlük full backup almaktan ibaret olmamalı. Şu soruları netleştirmeniz gerekir:

  • Yedekleriniz kaç gün geriye gidiyor?
  • Yedekler fiziksel olarak farklı bir altyapıda mı tutuluyor?
  • Hesap bazında kendini geri yükleme imkânı sunuyor musunuz?
  • Yedekten geri dönüş süreleriniz (RTO) müşterilere ne olarak beyan ediliyor?

Sağlam bir çerçeve için, 3-2-1 yedekleme stratejisi rehberimizde anlattığımız modeli temel alabilirsiniz: 3 kopya, 2 farklı medya, 1 tanesi uzak lokasyonda. DCHost altyapısında, reseller müşterilerimiz için hesap bazlı otomatik yedekler ve isteğe bağlı uzak yedekleme çözümleriyle bu modeli pratik hale getiriyoruz.

Hangi müşteriyi ne zaman üst pakete veya VPS’e taşımalısınız?

Başarılı reseller işletmelerinde çok net bir kural vardır: Reseller, tüm yükü sonsuza kadar taşımak için değil, doğru müşterileri doğru zamanda üst segmentlere taşımak için vardır. Aşağıdaki sinyallerden birkaçını aynı anda görüyorsanız, ilgili müşteriyi daha yüksek bir plana, VPS’e veya dedicated sunucuya taşıma zamanı gelmiş demektir:

  • Aylık ortalama CPU/IO kullanımı, paket limitlerinin %70–80’inde geziniyorsa.
  • Yoğun kampanya dönemlerinde diğer hesapların da etkilendiği performans sıçramaları oluyorsa.
  • E-posta gönderim hacmi sürekli limite dayanıyorsa ve IP itibar riski artıyorsa.
  • Uygulama mimarisi (örneğin ağır bir WooCommerce + entegrasyonlar + background queue yapısı) artık paylaşımlı mimari için fazla karmaşık hâle geldiyse.

Bu durumda müşteriye, DCHost üzerinde VPS, dedicated sunucu veya gerekirse colocation seçenekleriyle bir üst seviyeye taşınmasını önerebilirsiniz. Bu hem sizin reseller ortamınızın sağlığını korur, hem de ilgili müşteri için daha öngörülebilir bir performans sunar.

DCHost üzerinde sağlıklı reseller mimarisi için pratik kontrol listesi

Rehberde anlattığımız prensipleri günlük iş akışınıza yansıtmak için aşağıdaki kısa kontrol listesini kullanabilirsiniz:

  • Paket tasarımı: En az 3 kademeli, net tanımlı disk, trafik ve özellik setleri var mı? “Sınırsız” söylemlerinden kaçınılıyor mu?
  • Kaynak limitleri: CPU, RAM, IO ve EP için her paket düzeyi için mantıklı başlangıç değerleri belirlendi mi ve düzenli gözden geçiriliyor mu?
  • İzolasyon: Dosya sistemi izolasyonu, kullanıcı bazlı PHP süreçleri ve ayrı veritabanı kullanıcı politikası standart hâle getirildi mi?
  • E-posta güvenliği: Hesap başına gönderim limitleri tanımlı mı, SPF/DKIM/DMARC kayıtları teşvik ediliyor mu?
  • Güvenlik sertleştirme: Panel ve sunucu için hazırladığınız güvenlik kontrol listesi düzenli uygulanıyor mu?
  • İzleme ve raporlama: Hesap bazlı kaynak tüketim raporlarını aylık olarak gözden geçiriyor musunuz?
  • Yedekleme: 3-2-1 prensibine yakın bir model uyguluyor musunuz, geri dönüş süreçlerini test ettiniz mi?
  • Ölçeklendirme: VPS/dedicated/colocation’a taşıma için hangi metrikleri eşik kabul edeceğiniz net mi?

Bu listeyi kendi süreçlerinize göre genişletebilir, ekip içi doküman hâline getirerek yeni katılan kişilerin de aynı standartlarla çalışmasını sağlayabilirsiniz.

Sonuç ve sonraki adımlar

Reseller hosting, doğru yönetildiğinde ajanslar, freelancer’lar ve ürün geliştiriciler için son derece kârlı ve esnek bir model sunuyor. Ancak iş yalnızca “uygun fiyatlı plan” bulmakla bitmiyor; asıl farkı yaratan, paketleri nasıl tasarladığınız, limitleri ne kadar bilinçli koyduğunuz ve müşteri hesaplarını ne kadar iyi izole ettiğiniz. Bu rehberde, DCHost ekibi olarak sahada günlük karşılaştığımız sorunlardan ve çözümlerden yola çıkarak; paket tasarımı, limitlendirme, güvenlik ve ölçeklendirme tarafında uygulanabilir bir yol haritası çizmeye çalıştık.

Şimdi sırada, bu prensipleri kendi reseller hesabınıza uyarlamak var. Mevcut planlarınızı gözden geçirip; disk/CPU/IO limitlerinizi, e-posta politikalarınızı ve yedekleme stratejinizi yeniden değerlendirerek başlayabilirsiniz. Kontrol panelinizdeki paketleri güncellerken bu yazıyı yan sekmede açık tutmanız işinizi kolaylaştıracaktır.

Eğer DCHost üzerinde reseller hesabı açmayı planlıyor veya mevcut hesabınızı bir üst seviyeye taşımak istiyorsanız, teknik ekibimizle birlikte mimariniz ve müşteri profiliniz için en uygun paket ve limit stratejisini birlikte tasarlayabiliriz. Sorularınızı, taşıma taleplerinizi veya “bu müşteri artık VPS’e geçmeli mi?” gibi kararsız kaldığınız durumları bizimle paylaşmaktan çekinmeyin; yıllardır yönettiğimiz reseller altyapılarından edindiğimiz deneyimi sizin senaryonuza uyarlamaktan memnuniyet duyarız.

Sıkça Sorulan Sorular

Paket sayısını belirlerken karmaşıklığı değil, yönetilebilirliği hedefleyin. Çoğu senaryoda 3–4 kademeli bir yapı (örneğin Başlangıç, Standart, Profesyonel, Kurumsal) yeterlidir. Önce müşteri kitlenizi analiz edin: Küçük vitrin siteleri, içerik odaklı projeler ve daha yoğun e-ticaret/SaaS yükleri için ayrı kademeler tanımlayın. Her paket, bir üst pakete geçişi rasyonel kılacak şekilde anlamlı farklar içermeli; sadece disk alanı değil, CPU/IO limitleri, yedekleme sıklığı, e-posta ve özellik seti (SSH, staging, Git vb.) de kademelendirilmelidir. Gerektiğinde çok özel ihtiyaçlar için "özel teklif" oluşturmak, paket sayısını şişirmekten daha sağlıklıdır.

CPU, RAM ve IO limitleri için tek bir sihirli değer yok; iş tamamen barındırdığınız sitelerin profilini anlamakla başlar. Önce birkaç ay boyunca ortalama kaynak tüketimini izleyin, ardından paket bazında mantıklı taban değerler belirleyin. Örneğin basit kurumsal siteler için 50–100% CPU, 512–1024 MB RAM ve 5–10 MB/s IO çoğu zaman yeterlidir; fakat WooCommerce gibi ağır uygulamalar için daha yüksek limitli üst paketler tasarlamalısınız. Önemli olan, limitleri ne çok gevşek (diğer müşterileri rahatsız eder) ne de gereksiz sert (sürekli hata ve şikâyet üretir) bırakmamak. Ayrıca limit politikanızı düzenli aralıklarla gözden geçirip ihtiyaç oldukça güncellemeniz gerekir.

Müşteri izolasyonu için minimumda şu adımları standart hale getirmenizi öneririz: Birincisi, her alan adını mümkün olduğunca ayrı bir hesapta barındırın; çok sayıda sitenin tek cPanel hesabında toplanmasından kaçının. İkincisi, dosya sistemi izolasyonu sağlayan çözümleri (chroot, CageFS vb.) aktif tutun ve PHP süreçlerini kullanıcı bazlı çalıştırın. Üçüncüsü, her site için ayrı veritabanı ve kullanıcı kullanarak yetkileri daraltın, SSH erişimi gerekiyorsa mutlaka jailed shell ile kısıtlayın. Dördüncü adım olarak, WAF, malware taraması ve güncel PHP sürümleriyle sunucu tarafı güvenlik sertleştirmesini tamamlayın. Bu temel set, olası hack vakalarında zararı tek hesapla sınırlamanıza büyük ölçüde yardımcı olacaktır.

Reseller ortamında spam yönetimi için teknik ve operasyonel önlemleri birlikte düşünmelisiniz. Teknik tarafta, hesap başına saatlik ve günlük e-posta gönderim limitleri tanımlayın, SMTP kimlik doğrulamasını zorunlu tutun ve SPF/DKIM/DMARC kayıtlarını standart hale getirin. Logları düzenli izleyip anormal gönderim paternlerini hızlıca tespit edecek uyarılar oluşturun. Operasyonel tarafta ise, toplu bülten gönderimi yapmak isteyen müşterileri bu amaçla tasarlanmış e-posta servislerine veya ayrı IP’ye sahip özel sunuculara yönlendirin; paylaşımlı IP üzerinden yüksek hacimli mailing’e izin vermeyin. Şüpheli aktivite gördüğünüzde ilgili hesabı sınırlandırıp müşteriye durumu net şekilde açıklayın; gerekirse sitenin enfekte olup olmadığını kontrol edip güvenlik temizliği önerin.

Aynı reseller hesabında çok sayıda yoğun trafik alan veya kaynak tüketimi yüksek müşteriniz oluştuğunda, kendi VPS veya dedicated sunucunuza geçmek daha mantıklı hale gelir. Özellikle bazı hesapların CPU/IO kullanımının düzenli olarak paket limitlerinin %70–80’ine dayandığını, kampanya dönemlerinde diğer müşterilerin de etkilendiğini ve özel yapılandırma ihtiyaçlarının (özel PHP modülleri, arka plan queue sistemleri, Redis, Elasticsearch vb.) arttığını görüyorsanız, bu güçlü bir sinyaldir. Böyle durumlarda ilgili müşterileri, DCHost üzerinde kendi VPS veya fiziksel sunucularına taşıyarak hem performansı stabilize edebilir hem de reseller ortamınızı daha hafif ve öngörülebilir hale getirebilirsiniz.