Ajanslar İçin Multi-Tenant E-posta ve DNS Mimarisi

Ajanslar İçin Multi-Tenant E‑Posta ve DNS Neden Önemli?

Web ajansları, dijital pazarlama ekipleri ve freelance geliştiriciler için en büyük operasyonel yüklerden biri; onlarca hatta yüzlerce müşterinin alan adı, DNS ve e‑posta altyapısını dağınık halde yönetmek. Bir müşterinizin alan adı bir yerde, DNS kayıtları başka bir yerde, e‑posta bambaşka bir sağlayıcıda olunca; basit bir SPF güncellemesi bile saatler süren, riskli bir işe dönüşebiliyor. Yanlış bir MX kaydı gelen e‑postaların teslimini aksatabilir; hatalı bir SPF kaydı ise gönderilen e‑postaların alıcı politikasına göre reddedilmesine veya spam olarak değerlendirilmesine katkıda bulunabilir.

Bu ihtiyaca bir yanıt olarak ajanslar, multi-tenant (çok kiracılı) bir e‑posta ve DNS mimarisini tek bir VPS veya reseller hosting üzerinde kurmayı değerlendirebilir. Müşteri hesaplarının ayrılması ve erişim sınırlarının doğru yapılandırılmasıyla:

• Tüm müşterilerin DNS ve e‑posta ayarlarını tek panelden görebilir,
• Her müşterinin veri ve yönetim erişimini ayrı hesaplarla sınırlandırabilir,
• Şablonlar ve otomasyonla yeni müşteri kurulum süresini kısaltabilir,
• İtibar, güvenlik ve yedekleme politikalarını tüm portföyde tutarlı uygulayabilirsiniz.

Bu yazıda, VPS veya reseller hesap üzerinde çok müşterili e‑posta ve DNS yönetimini planlamak için mimari seçenekleri, güvenlik önlemlerini ve operasyon adımlarını ele alacağız. Bu bir panel ya da MTA kurulum kılavuzu değil; ayrıntılı kurulumlar için ilgili rehberlere bağlantı veren bir tasarım çerçevesidir. Tek sunucuyla başlangıcın sınırlarını ve ihtiyaç büyüdüğünde rollerin ayrı sunuculara dağıtılmasını da değerlendireceğiz.

Temel Kavramlar: Multi-Tenant, Tek VPS ve Reseller Yapısı

Önce üzerinde konuştuğumuz kavramları netleştirelim. Multi-tenant mimari, basitçe tek bir altyapı üzerinde birden çok bağımsız müşteriyi (tenant) izole şekilde barındırma yaklaşımıdır. Ajans senaryosunda her tenant genellikle “bir marka / bir şirket” anlamına gelir ve en az bir alan adı + e‑posta alan adından oluşur.

Ajanslar için multi-tenant e‑posta ve DNS yönetiminde ele alacağımız iki temel seçenek var:

• Tek VPS Üzerinde Multi-Tenant Panel
  DCHost VPS gibi bir sanal sunucuda, seçilen işletim sistemi ve kaynaklarla uyumlu cPanel, DirectAdmin veya benzeri bir panel kullanılabilir. Gerekli lisansları ve posta/DNS hizmeti koşullarını doğruladıktan sonra her müşteriye ayrı kullanıcı hesabı açarsınız. Panelin desteklediği DNS, e‑posta ve web barındırma işlevleri aynı yönetim noktasında toplanabilir.
• Reseller Hosting Üzerinde Çoklu Hesap
  Müşteri başına ayrı panel hesabı açmaya izin veren bir reseller paketinde, sunulan panele göre her müşteriye ayrı hesap tanımlarsınız. Sunucu yönetimi sağlayıcının sorumluluğundaysa daha çok paket ve kota tasarımına odaklanırsınız; bakım ve yönetim kapsamını sözleşmede netleştirmelisiniz.

Bu iki yaklaşımı detaylı karşılaştırdığımız “Reseller hosting mi VPS mi? Ajans ve freelancerlar için yol haritası” yazımıza mutlaka göz atmanızı öneririm. Burada ise özellikle e‑posta ve DNS mimarisi tarafını derinleştireceğiz.

Mimari Seçenekler: Tek VPS mi Reseller mı?

Seçim için temel soru şu: “Müşterilerin DNS ve e‑postasını bir VPS’te mi toplamalıyım, yoksa reseller hosting ile mi başlamalıyım?” Aşağıdaki müşteri sayıları yalnızca örnektir; kapasite eşiği veya tek kişinin yönetebileceği portföy büyüklüğü olarak okunmamalıdır. Kararı posta hacmi, site yükü, saklama ihtiyacı, hizmet koşulları ve ekibin operasyon kapasitesiyle birlikte verin.

Reseller Hosting Tercih Etmenin Mantıklı Olduğu Durumlar

• Sunucu yönetimiyle (OS güncelleme, güvenlik duvarı, SMTP tuning vb.) uğraşmak istemiyorsanız,
• Önceliğiniz hızlı devreye alma ve basit yönetim ise,
• Genelde standart kurumsal siteler + düşük hacimli kurumsal e‑posta barındırıyorsanız,
• Tek teknik kişiyle 30–40 müşteriyi taşımayı planlıyorsanız

Reseller paketini seçerken mail ve DNS servislerinin yönetim, izleme ve bakım kapsamını netleştirin. Bu işler sağlayıcının sorumluluğundaysa siz daha çok paket limitleri, şifre politikaları ve DNS şablonları tarafına odaklanabilirsiniz.

Tek VPS (veya Dedicated) Tercih Etmenin Mantıklı Olduğu Durumlar

• SMTP, DNS, güvenlik duvarı ve yedekleme üzerinde daha ince ayar yapmak istiyorsanız,
• Yüksek hacimli pazarlama e‑postaları veya transactional (sistem) e‑postaları da aynı altyapıdan gönderecekseniz,
• Her müşteriye özelleşmiş politikalar (farklı kota, farklı rate limit, farklı IP vb.) tanımlamak istiyorsanız,
• Günün sonunda 100+ domain seviyesinde bir portföyü merkezileştirmeyi hedefliyorsanız

Bu senaryoda yeterli disk performansı ve RAM/CPU kapasitesine sahip bir VPS, kendi çok kiracılı mail+DNS platformunuz için değerlendirilebilir. DCHost dahil herhangi bir sağlayıcıda plan seçmeden önce posta kullanım politikasını ve izin verilen gönderim türü/hacmini doğrulayın. Doğrudan alıcı sunuculara gönderim için dışarıya TCP 25 erişimi, kendi sunucunuzda internetten posta kabulü için de içeriye TCP 25 erişimi gerekir. PTR tanımlama/değiştirme sürecini ve ayrı çıkış IP’leri kullanacaksanız ek IP tahsis koşullarını ayrıca netleştirin; VPS satın almak bu olanakları tek başına doğrulamaz.

Reseller ortamında IP seçimi, PTR yönetimi ve MTA düzeyindeki gönderim limitleri ajansın yetkisinde olmayabilir. Hangi ayarların panelden yapılabildiğini, hangileri için sağlayıcı müdahalesi gerektiğini öğrenin. Gereksinimler karşılanmıyorsa uygun koşulları sunan bir plan veya harici SMTP gönderim hizmeti değerlendirilebilir. İhtiyaç büyüdüğünde dedicated sunucu veya colocation da genel altyapı seçenekleridir. Self-managed VPS modelinde işletim sistemi, uygulama, güvenlik ve veri koruma yönetimi, ayrıca bir hizmet kararlaştırılmadıkça size aittir.

DNS Mimarisi: Onlarca Müşteri İçin Yönetilebilir Yapı

DNS yönetiminde hata kaynakları arasında farklı registrar’lar, karışık nameserver’lar, TTL’ler ve unutulmuş eski kayıtlar bulunur. Multi-tenant DNS mimarisinde hedefimiz; tüm alan adlarını tek bir mantıklı çatı altında toplamak ve tekrar eden işlemleri otomatikleştirmek.

Nameserver ve Zone Stratejisi

Bir seçenek, DNS yönetimini destekleyen hosting veya VPS panelini merkezi DNS yönetim noktası olarak kullanmaktır:

• Tüm müşterilerin domain’lerini ilgili registrar’da tutup,
• Registrar’daki NS delegasyonunu seçtiğiniz yetkili DNS sunucularına yönlendirip,
• Her müşteri alan adı için ayrı bir DNS zone açmak.

Özel ad sunucuları için ns1/ns2 gibi adlar kullanılabilir; glue kaydı, özel ad sunucusunun kendisi değil, üst zone’da yayımlanan adres bilgisidir. Özellikle ad sunucusunun adı, hizmet verdiği alan adının altındaysa delegasyonun çözülebilmesi için glue gerekir. İki NS adını aynı VPS’e yönlendirmek sunucu arızasına karşı yedeklilik sağlamaz; yetkili DNS hizmetini ayrı hata alanlarına dağıtmak gerekir. Bu yapıyı adım adım anlattığımız özel ad sunucusu ve glue record rehberi, ajans tarafında kendi nameserver markanızı oluştururken çok işinize yarar.

Reseller tarafında ise sağlayıcının belirttiği yetkili nameserver adlarını kullanabilirsiniz. ns1.example.com / ns2.example.com gibi markalı adlar yalnızca temsili örneklerdir; kullanılabilmeleri için ayrıca yapılandırılmaları gerekir.

Ajanslarda Kaçınılması Gereken DNS Yönetim Desenleri

Yönetimi zorlaştırabilecek problemli desenler şunlar:

• Belgelenmemiş farklı NS stratejileri: Bir müşteri registrar DNS’inde, diğeri Cloud tabanlı DNS’te, diğeri hosting’in NS’inde olabilir. Bu çeşitlilik tek başına hata değildir; merkezi envanter ve tanımlı süreçler yoksa tüm portföyün durumunu izlemek zorlaşır.
• TTL’lerin plansız seçilmesi: Farklı kayıtlar için 14400, 300 veya 86400 saniye uygun olabilir. Taşıma öncesinde TTL’yi yeterince erken düşürmemek, eski değerle önbelleğe alınmış kayıtların kullanımını uzatabilir; eski hizmet erken kapatılırsa kesinti yaşanabilir.
• Boşta kalmış, eskiye yönlenen kayıtlar: Artık var olmayan sunuculara bakan A kayıtları, eski e‑posta servislerine bakan MX kayıtları.
• Alan adları ve DNS erişimlerinin dağınık olması: Kimde hangi panel erişimi var belli değil, kayıt değiştirme süreci uzuyor.

Bu konuları sistematik çözmek için hazırladığımız “Ajanslar için DNS ve alan adı erişimi yönetimi” rehberini mutlaka yanınızda tutun; burada anlatacağımız mimariyi o erişim modelinin üzerine inşa ettiğinizde operasyon çok daha temiz hale geliyor.

Gelişmiş DNS Güvenliği ve Otomasyon

Ajans olarak onlarca domain yönettiğinizde, “güvenlik ayarlarını sonra bakarız” deme lüksünüz kalmıyor. Özellikle e‑posta güvenliği ve marka koruması için aşağıdaki adımlar ajans mimarisinin parçası olmalı:

• DNSSEC: Alan adlarınız için DNS imzalama ile sahte kayıt riskini azaltırsınız. Temeli için DNSSEC kurulum rehberimize göz atabilirsiniz.
• CAA kayıtları: Hangi CA’ların sertifika üretebileceğini sınırlandırmak, özellikle çok domain’li yapılarda önemli bir güvenlik katmanı ekler.
• TXT ve SRV şablonları: SPF, DMARC, MTA-STS, BIMI, VoIP vb. kayıtlarını her yeni müşteri için manuel yazmak yerine panelde şablonlar oluşturun.

Otomasyon tarafında, seçilen DNS hizmetinin API’si ve uygun Terraform provider desteği varsa DNS’i kodla yönetmek de mümkündür. Genel yaklaşım ve entegrasyon örnekleri için VPS ve DNS otomasyonu rehberimize bakabilirsiniz.

E‑Posta Mimarisi: Teslim Edilebilirlik ve İtibar Odaklı Tasarım

DNS’i oturttuktan sonra asıl kritik konuya geliyoruz: e‑posta teslim edilebilirliği (deliverability) ve IP itibar yönetimi. Paylaşılan çıkış IP’sinde önemli bir risk şudur: Bir müşterinin yüksek şikâyet veya spam oranı üreten kampanyaları IP itibarını düşürebilir ve aynı IP’den gönderim yapan diğer müşterilerin teslim edilebilirliğini de olumsuz etkileyebilir.

Temel Kayıt Şablonu: MX, SPF, DKIM, DMARC

Multi-tenant mimaride her müşteri için en azından aşağıdaki temel şablonu standartlaştırmanız gerekir:

• MX: Müşterinin alan adına gelen e‑postayı, o alan adı için posta kabul edecek şekilde yapılandırılmış sunucuya yönlendirin.
• SPF: SMTP MAIL FROM (zarf göndereni) veya HELO alan adını hangi sunucuların kullanmaya yetkili olduğunu beyan edin; bu, görünen From adresini tek başına doğrulamaz.
• DKIM: Gönderici sunucuda imzalamayı etkinleştirin ve açık anahtarı DNS’te yayımlayın. DKIM, imzalayan alan adını ve imzalanan içeriğin bütünlüğünü doğrulamaya yardımcı olur; tek başına tüm sahteciliği önlemez.
• DMARC: Görünen From alan adıyla hizalı SPF veya DKIM doğrulamasından en az birinin başarılı olması gerekir. Bu koşul sağlanmadığında alıcıya uygulanmasını istediğiniz politikayı bildirirsiniz; nihai işlem alıcının yerel politikasına da bağlıdır.

Bu temeli sıfırdan nasıl kuracağınızı adım adım anlattığımız SPF, DKIM ve DMARC rehberi, multi-tenant mail mimarisi için bu temel kayıtların kurulumunu açıklar.

Panel destekliyorsa yeni açılan her hesapta gerekli kayıtları şablondan oluşturun; ardından değerleri müşterinin gerçek gönderim servisleriyle karşılaştırın ve yetkili DNS’te yayımlandıklarını doğrulayın. DNS kaydı oluşturmak, sunucuda DKIM imzalamasını etkinleştirmenin yerine geçmez.

IP Adresi, Reverse DNS ve IP Isıtma

Tek VPS veya reseller üzerinde multi-tenant mail tasarlarken kritik sorulardan biri şu: “Tüm müşteriler aynı paylaşımlı IP’den mi mail atmalı, yoksa bazılarına dedicated IP mi vermeliyim?”

Sağlayıcının izin verdiği gönderim hacmi, ek IP tahsisi ve yönlendirme yetkileri doğrulandıktan sonra şu tasarım seçenekleri değerlendirilebilir:

• Küçük hacimli kurumsal mail trafiği olan müşterileri paylaşımlı IP üzerinde toplamak,
• Büyük hacimli pazarlama veya transactional gönderim yapan kritik markalar için ayrı bir IP havuzu tanımlamak,
• Yeni IP’leri bir anda binlerce maille boğmak yerine kademeli IP ısıtma stratejisi uygulamak.

Bu konuda çok detaylı bir rehberi zaten hazırladık: “Dedicated IP ısıtma ve e‑posta itibarı yönetimi”. Multi-tenant senaryoda fark, bu süreci müşteriler arasında önceliklendirme ve kota yönetimiyle birleştirmeniz.

Her gönderim IP’si için PTR (Reverse DNS) kaydını ve MTA’nın HELO/EHLO kimliğini planlayın. PTR’nin gösterdiği host adının A veya AAAA kaydı aynı gönderim IP’sine dönmelidir. PTR, müşteri zone’una eklenen sıradan bir kayıt gibi yönetilemeyebilir; IP sağlayıcısının sürecini izleyin. Geçerli ileri/ters DNS ve TLS, örneğin Gmail’in gönderici gereksinimleri arasındadır; bunların sağlanması tek başına teslim garantisi değildir. PTR yapılandırmasının e‑posta teslimine etkisini anlattığımız PTR rehberi, tek VPS üzerinde kendi MTA’nızı yönetirken başvurabileceğiniz bir kaynaktır.

Tenant Başına İzolasyon, Kota ve Rate Limit

Multi-tenant mimaride müşteriler aynı SMTP kuyruğunu paylaşıyorsa, bir müşterinin trafiği diğerlerinin teslimatını da geciktirebilir. Bu yüzden:

• Her müşteri için günlük / saatlik gönderim limiti belirleyin (panel veya MTA seviyesinde),
• Şüpheli bir müşteri (çok bounce alan, çok spam şikâyeti gelen) tespit ettiğinizde gönderimini sınırlandırın veya durdurun; hesap güvenliğini ve alıcı listesini inceleyin. Ayrı IP veya SMTP nodu izolasyon sağlayabilir, ancak sorunun nedenini gidermenin yerine geçmez,
• Loglarda tenant bazlı filtreleme yaparak “hangi müşteri ne kadar hata üretiyor”u görebilin.

Bu tür politikalar, blacklist veya itibar sorunlarının riskini ve diğer müşterilere etkisini azaltmaya yardımcı olur. Eğer tek VPS üzerinde kendi Postfix/Dovecot+rspamd yapınızı kurmak istiyorsanız, VPS’te e‑posta sunucusu kurulumu rehberimiz size oldukça yol gösterecektir.

İleri Seviye: MTA-STS, TLS-RPT, BIMI ve MTA Güvenliği

Kurumsal müşteriler için değerlendirilebilecek ileri seviye taşıma güvenliği ve marka görünürlüğü seçenekleri de var:

• MTA-STS ile, politikayı destekleyen gönderici sunucuların alan adınıza posta tesliminde geçerli sertifikalı TLS kullanmasını enforce modunda şart koşmak; TLS-RPT ile destekleyen göndericilerden TLS teslimat raporları toplamak,
• BIMI ile, ilgili sağlayıcının doğrulama ve uygunluk koşulları sağlandığında destekleyen e‑posta hizmetlerinde marka logosunun gösterilmesine olanak tanımak,
• DANE/TLSA ile DNSSEC üzerinden ek bir güvenlik katmanı eklemek.

MTA-STS, TLS-RPT ve BIMI için DNS kayıtlarını ve ilgili gereksinimleri ele alan MTA-STS, TLS-RPT ve BIMI rehberi, multi-tenant DNS mimarinize bu katmanları sağlam şekilde oturtmanız için ideal bir referans.

Tek Sunucuda Güvenlik, Yedekleme ve İzleme

Onlarca müşterinin mail kutuları ve DNS kayıtları ortak altyapıda tutuluyorsa, bu yapı ajans için kritik bir hizmet noktasıdır. Reseller hizmeti mutlaka tek fiziksel makine anlamına gelmez; sağlayıcının servis yerleşimini ve yedeklilik kapsamını öğrenin. Ayrı müşteri hesapları erişimi sınırlandırabilir, ancak ortak sunucu arızasını veya tüm kaynak ve itibar etkilerini ortadan kaldırmaz. Güvenlik, yedekleme ve izleme planını bu ortak risklere göre hazırlayın.

Panel ve Sunucu Erişimi

• cPanel/DirectAdmin/WHM gibi panellere iki faktörlü kimlik doğrulama (2FA) zorunlu olmalı.
• Ajans ekibinde kim hangi hesaba erişebilir; bunu netleştiren bir yetkilendirme matrisi kurun. Bunun için hazırladığımız ajanslar için hosting paneli erişim yönetimi rehberi somut bir başlangıç sağlar.
• VPS kullanıyorsanız, SSH erişimlerini anahtar tabanlı yapın. Yetkili bir normal kullanıcıyla anahtarlı girişin ve sudo erişiminin çalıştığını doğruladıktan sonra doğrudan root SSH girişini kapatın; güvenlik duvarında yönetim ve posta servisleri için gerekli erişimleri koruyarak ufw/fail2ban gibi sertleştirme araçlarını yapılandırın.

Yedekleme ve Felaket Kurtarma

Tek sunucuda tüm müşterilerin mail ve DNS verisinin tutulması, ortak veri kaybı riskini artırır. Kabul edilebilir veri kaybını ve hizmete dönüş süresini belirleyerek aşağıdaki modeli bir başlangıç noktası olarak değerlendirin; yedekleme ve geri yükleme sıklığını bu hedeflere göre ayarlayın:

• Günlük tam veya artımlı hesap yedekleri (web+mail+DNS); panel yedeklerinin posta kutularını, ilgili yapılandırmaları ve DNS zone verilerini gerçekten içerdiğini doğrulayın. Harici yetkili DNS kullanılıyorsa bu kayıtlar için ayrıca düzenli dışa aktarma veya sağlayıcının desteklediği yedekleme yöntemini ve sorumlusunu belirleyin.
• Yedeklerin en az bir kopyasının farklı bir fiziksel lokasyonda tutulması; registrar erişimi, NS delegasyonu ve glue bilgilerini ayrıca belgeleyin. DNSSEC kullanılıyorsa imzalama ve üst zone’daki DS kaydı için sağlayıcıya özgü kurtarma sürecini de kaydedin.
• Haftalık veya aylık bazda geri yükleme testi (restore drill) yapılması; tek posta kutusu ve DNS zone’unun diğer müşterilerin verilerinin üzerine yazılmadan kurtarılabildiğini sınayın.

Bu yapıyı 3-2-1 kuralıyla birlikte ele aldığımız 3‑2‑1 yedekleme stratejisi rehberi, özellikle tek VPS üzerinde ajans platformu kuranlar için olmazsa olmaz okumalık.

İzleme, Loglama ve Alarm Mekanizmaları

Multi-tenant yapıda sorunların müşteriniz fark etmeden önce sizin radarınıza düşmesi gerekir. Bunun için:

• Sunucu yönetim yetkiniz varsa CPU, RAM, disk, I/O ve network kullanımını izleyen bir monitoring (Netdata, Prometheus+Grafana vb.) kurun; reseller ortamında erişebildiğiniz panel metriklerini ve hizmet izleme kontrollerini kullanın.
• Mail kuyruğu boyu, bounce oranları ve SMTP hata kodları için basit metrikler çıkarın. SMTP hata kodları ve bounce mesajları rehberimizi operasyon dokümanınıza eklemeniz, destek ekibinin işini çok kolaylaştırır.
• DNS tarafında yanlışlıkla silinen kritik kayıtlar veya beklenmedik değişiklikleri tespit eden bir süreç (manuel veya otomatik rapor) oluşturun.

Operasyonel Akış: Yeni Müşteri Açılışından Taşıma Süreçlerine

Teknik mimari kadar önemli olan bir diğer konu da ajans içi süreçler. Multi-tenant e‑posta ve DNS yapınız varsa, her yeni müşteri için tekrar eden işleri otomatikleştirmek büyük zaman kazandırır.

Yeni Müşteri İçin Önerilen Adım Adım Akış

1. Alan adı durumu: Domain sizde mi, müşteride mi, kimin registrar hesabında?
2. Geçiş hazırlığı: Mevcut DNS kayıtlarını ve kullanılan servisleri envanterleyin; yeni DNS ve posta hizmetleri hazır olmadan nameserver değişikliği yapmayın.
3. Hesap açılışı: VPS veya reseller üzerinde müşteri için ayrı bir hosting hesabı oluşturun.
4. DNS şablonu: A/AAAA, MX, SPF, DKIM, DMARC ve CAA gibi gerekli kayıtları gerçek servis değerleriyle oluşturun; mevcut kullanılan kayıtları koruyun. MTA-STS kullanacaksanız DNS kaydına ek olarak HTTPS üzerinden sunulan politika dosyasını da hazırlayın.
5. E‑posta kutuları: Kurumsal e‑posta adreslerini açın, kota ve şifre politikalarını uygulayın.
6. Test ve devreye alma: Önce yeni yetkili DNS sunucularındaki kayıtları, posta kabulünü ve gönderici doğrulamasını sınayın. Ardından registrar tarafında NS geçişini yapın; DNSSEC kullanılıyorsa DS geçişini de planlayın. Geçiş sonrası gelen/giden test postalarıyla SPF/DKIM/DMARC sonuçlarını kontrol edin; önbellek geçişi ve varsa son posta senkronizasyonu tamamlanana kadar eski hizmeti açık tutun.

DNS ve nameserver geçişlerinde kesinti riskini azaltmak için TTL stratejileriyle sıfır kesinti taşıma rehberindeki hazırlıkları bu akışa dahil edin. TTL değişikliğini yalnızca NS geçişi anında yapmak yeterli değildir; eski TTL ile önbelleğe alınmış kayıtları hesaba katarak önceden planlayın. Bu önlemler kesintisizlik garantisi vermez.

Mevcut E‑Posta Altyapısını Taşırken Dikkat Edilecekler

Var olan bir müşterinin e‑posta altyapısını kendi multi-tenant yapınıza alırken kaçınmanız gereken hatalar şunlardır:

• Yeni sunucuda posta kabulünü doğrulamadan ve eski sunucuya gelen son iletiler için ek senkronizasyon planlamadan MX kayıtlarını güncellemek,
• Yeni gönderim servislerini SPF kaydına eklememek veya hâlâ posta gönderen eski servisleri kayıttan erken çıkarmak,
• DMARC politikası sıkı (reject/quarantine) iken yeni gönderim yolunda From alan adıyla hizalı SPF veya DKIM doğrulamasını test etmeden geçiş yapmak.

Bu geçişlerde adım adım yol haritası için e‑posta altyapısını taşırken kesinti yaşamamak yazımızı, ayrıca cPanel tarafında IMAP senkronizasyonu ve DNS cutover detayları için cPanel e‑posta hesaplarını yeni sunucuya taşımak rehberimizi sürecinize eklemenizi öneririz.

Ajanslar İçin Örnek Mimari Senaryolar

Aşağıdaki üç varsayımsal senaryo, farklı portföyler için mimari seçenekleri somutlaştırır. Müşteri sayıları kapasite garantisi değildir; kaynak ihtiyacı site yüküne, posta hacmine ve saklama süresine göre belirlenmelidir.

1) Küçük Ajans: Reseller + Standart DNS/E‑Posta

• 20–40 arası kurumsal site ve düşük hacimli e‑posta trafiği,
• Müşteri başına ayrı hesap ve gereken e‑posta kotalarını destekleyen bir reseller hosting paketi,
• Paketin desteklediği panele göre her müşteri için ayrı cPanel/DirectAdmin veya eşdeğer hesap,
• Sağlayıcının belirlediği NS’ler; panel destekliyorsa otomatik SPF/DKIM kurulumu ve yetkili DNS’te kayıtların doğrulanması,
• DMARC raporlarıyla p=none aşamasında izleme; meşru gönderimlerin hizalaması doğrulandıktan sonra p=quarantine veya p=reject politikasına geçiş.

Sunucu işletimi sağlayıcının sorumluluğundaysa bu modelde ajans, günlük işlerini ağırlıklı olarak panel ve DNS üzerinden yürütebilir. Hesap güvenliği, kotalar ve yedekleme için sorumluluk paylaşımı ayrıca belirlenmelidir.

2) Orta Ölçek Ajans: Tek Güçlü VPS Üzerinde Multi-Tenant Panel

• 40–100+ müşteriden oluşan varsayımsal portföy, karma trafik hacimleri,
• DCHost dahil değerlendirilen sağlayıcılarda posta kullanım koşulları doğrulanarak CPU/RAM, disk kapasitesi ve I/O gereksinimlerine göre seçilmiş bir VPS,
• İşletim sistemi uyumluluğu ve lisansı doğrulanmış cPanel/DirectAdmin veya benzeri panel,
• Kendi ns1/ns2.ajansdns.com gibi temsili ad sunucusu adları (gereken glue kayıtlarıyla); yedeklilik için yetkili DNS’in ayrı hata alanlarına yerleştirilmesi,
• Paylaşımlı çıkış IP’si; ihtiyaç, tahsis koşulları ve MTA yönlendirmesi uygunsa ek dedicated IP’ler,
• SPF, DKIM, DMARC; gereksinimleri karşılanan müşterilerde MTA-STS ve BIMI.

Bu senaryoda bazı müşterilerin transactional mailleri ayrı bir tenant grubuna alınabilir. IP itibarı açısından ayrım hedefleniyorsa yalnızca gruplama yetmez; bu grubun gönderimleri ayrı çıkış IP’lerine yönlendirilmelidir.

3) Büyük Ajans / SaaS Benzeri Platform: Çok VPS + Ayrı Mail Nodları

• 100+ müşteriden oluşan varsayımsal portföy, yüksek hacimli transactional ve pazarlama mailleri,
• DCHost gibi bir VPS sağlayıcısında, posta ve ağ koşulları doğrulanarak web, mail ve DNS rollerinin farklı sunuculara ayrılması,
• Merkezi DNS yönetimi + ayrı mail node’ları (örneğin Postfix/Dovecot bileşenleriyle tasarlanan bir küme),
• Ek IP tahsisi ve MTA yönlendirme olanakları uygunsa farklı müşteri segmentleri için farklı IP havuzları ve rate-limit politikaları,
• Seçilen servislerin API ve entegrasyon desteğine göre Terraform/Ansible ile müşteri kurulumu, DNS ve TLS sertifikası işlemlerinin otomasyonu.

Bu model, SaaS benzeri veya kurumsal barındırma hizmeti sunmayı hedefleyen varsayımsal bir ajans için değerlendirilebilir. Roller ayrıldıkça posta verisinin saklanması ve eşitlenmesi, yedekleme ve arıza devri de ayrıca tasarlanmalıdır.

Sonuç: Ajanslar İçin Yol Haritası ve Sonraki Adımlar

Onlarca müşterinin alan adı, DNS ve e‑posta altyapısını dağınık halde yönetmek, ilk bakışta “alıştık artık” denip geçilecek bir durum gibi görünebilir. Ancak bir müşterinin alan adı süresi dolduğunda, MX kaydı yanlış güncellendiğinde veya paylaşımlı IP’niz blacklist’e girdiğinde bu dağınıklık müdahaleyi zorlaştırabilir. Multi-tenant e‑posta ve DNS mimarisi, uygun izolasyon ve operasyon süreçleriyle yönetimi sadeleştirmeye yardımcı olabilir.

Ajanslar için önerilen uygulamalar şunlar:

• Alan adı ve DNS erişimlerini merkezi envanterde belgeleyin; farklı sağlayıcılar kullanılsa bile tutarlı bir yönetim ve NS stratejisi oluşturun.
• SPF, DKIM ve DMARC için müşterinin gerçek servis değerleriyle doğrulanan şablonlar hazırlayın; rDNS’i gönderim IP’si bazında sağlayıcının süreciyle yönetin.
• Şüpheli gönderimleri önce sınırlandırın veya durdurun; hesap güvenliğini ve alıcı listesini inceleyerek sorunun nedenini giderin. Ayrı çıkış IP’leri ve rate-limit politikaları diğer müşterilere etkiyi azaltabilir, ancak sorunlu göndericiyi başka IP’ye taşımak tek başına çözüm değildir.
• Yedekleme, izleme ve erişim yönetimini baştan tasarlayın; sağlayıcının posta koşullarını ve ajansın yönetim yetkilerini plan seçiminden önce doğrulayın.

Eğer siz de ajans olarak “artık bu karmaşayı toparlayalım” diyorsanız, ilk adımınız mevcut portföyünüzü haritalandırmak ve ardından yukarıda anlattığımız üç mimari modelden hangisinin size daha uygun olduğuna karar vermek olmalı. DCHost VPS seçeneğini değerlendirirken işletim sistemi, uygulamalar, güvenlik ve veri koruma yönetiminin, ayrıca bir hizmet kararlaştırılmadıkça, size ait olduğunu planınıza dahil edin.

Sonraki adım olarak özellikle e‑posta teslim edilebilirliğini adım adım yükseltme rehberimizi ve ajanslar için DNS erişim yönetimi yazımızı okumanızı öneririm. Bu rehberlerdeki adımları kendi mimarinize uyarlamak, e‑posta ve DNS yönetimini daha öngörülebilir hale getirmeye yardımcı olabilir; ölçeklenebilirlik ise kapasite ve operasyon tasarımına bağlıdır.