cPanel ve VPS’te E‑Posta Arşivleme: Journaling, Depolama ve Yasal Saklama Politikaları

E‑posta arşivleme ve yasal saklama neden bu kadar kritik?

E‑posta, birçok şirkette resmî yazışma, sözleşme teyidi, personel süreçleri ve hatta finansal onayların geçtiği birincil kanal haline geldi. Bu kadar kritik bir kanalın sadece kullanıcıların gelen kutusuna emanet edilmesi, hem operasyonel hem de hukuki açıdan ciddi risk oluşturuyor. Özellikle KVKK, GDPR ve sektör regülasyonları (finans, sağlık, kamu ihaleleri vb.) devreye girdiğinde, e‑posta arşivleme ve yasal saklama politikaları artık “güzel olur” değil, zorunlu hale geliyor.

DCHost tarafında yaptığımız proje planlama toplantılarında, orta ölçekli birçok firmanın aynı soruyla geldiğini görüyoruz: “Hem cPanel üzerinde çalışan e‑postalarımı, hem de kendi VPS’imde kurduğum mail sunucusunu; kim ne zaman ne göndermiş net görecek şekilde, güvenli ve kurallı biçimde nasıl arşivlerim?” Bu yazıda tam olarak bunu ele alacağız. cPanel ve VPS ortamında journaling mantığını nasıl uygularsınız, hangi depolama modelleri işinize yarar, retention (saklama süresi) politikalarını teknik olarak nasıl hayata geçirirsiniz; adım adım ve gerçekçi senaryolarla anlatacağız.

Daha genel bir bakış açısı arıyorsanız, e‑posta arşivlemeye giriş niteliğinde yazdığımız işletmeler için e‑posta arşivleme ve yasal saklama rehberi makalesini de göz atmalık bir kaynak olarak yan sekmede tutabilirsiniz.

Temel kavramlar: Journaling, arşiv, yedek ve log farkları

Önce kavramları netleştirelim; çünkü pratikte en çok karışan yer burası.

Journaling nedir?

Journaling, en basit tanımıyla, bir posta kutusuna giren ve çıkan tüm e‑postaların bir kopyasını merkezi bir arşiv kutusuna veya sunucuya otomatik olarak göndermek anlamına gelir. Kullanıcı e‑postayı silse bile, journaling kutusunda kopyası kalmaya devam eder. Amaç:

• Hukuki ispat (kim, kime, ne zaman, ne göndermiş)
• İç denetim ve uyum kontrolleri
• Olay inceleme (incident response) süreçlerinde kanıt

Journaling genellikle sunucu tarafında yapılır; yani kullanıcıların e‑posta istemcisine (Outlook, mobil uygulama vb.) güvenmek zorunda kalmazsınız.

Arşiv nedir, yedekten farkı ne?

E‑posta arşivi, belirli bir yapıya göre, genellikle uzun süreli saklamak amacıyla tutulan e‑posta koleksiyonudur. Yedekten farkları:

• Yedek, felaket anında sistemi eski haline getirmek içindir. Genellikle tüm sistemi (veya hesabı) belli bir tarihe geri sararsınız.
• Arşiv, geçmiş veriyi uzun süreli ve erişilebilir şekilde tutmak içindir. Genellikle değişmez (WORM benzeri) yapı tercih edilir ve arama/filtreleme imkânı önemlidir.

Yani “haftalık cPanel tam yedeği alıyoruz, o zaman arşive gerek yok” cümlesi maalesef yanlış bir güven duygusu yaratır. Yedekler, arşivi tamamlar ama yerine geçmez.

Log saklama nerede duruyor?

Posta sunucularının logları (günlük kayıtları) başka bir katman. Loglar, “şu tarihte şu IP’den şu adrese bir e‑posta teslim edildi / reddedildi” gibi teknik bilgiler taşır, fakat genellikle e‑postanın içeriğini barındırmaz.

Yani hukuki açıdan “bu e‑posta gerçekten gönderildi mi?” gibi sorularda loglar yardımcıdır; ancak e‑postanın metnini, eklerini, içerik bağlamını loglardan değil arşiv/journaling sisteminden okursunuz. Log saklama süreleri tarafında derinleşmek isterseniz, hosting ve e‑posta altyapısında log saklama süreleri yazımızı teknik detaylarla birlikte inceleyebilirsiniz.

cPanel üzerinde e‑posta arşivleme yaklaşımları

Birçok işletme için e‑posta, cPanel üzerinde barındırılan paylaşımlı hosting veya reseller hesapları üzerinden çalışıyor. Bu senaryoda, tam anlamıyla kurumsal bir journaling özelliği yok; ancak aynı sonucu pratik yöntemlerle büyük oranda elde etmek mümkün.

1) cPanel’de journaling benzeri BCC kopyalama

cPanel tarafında işin anahtarı, global e‑posta filtreleri ve/veya adres düzeyinde yönlendirmelerdir. Temel fikir: Gelen ve giden her e‑postanın bir kopyasını, arşiv için ayırdığınız özel bir posta kutusuna BCC (gizli kopya) ile göndermek.

Örnek bir yaklaşım:

1. Arşiv için ayrı bir adres açın, örneğin [email protected].
2. cPanel hesabında Account-Level Filtering (Hesap Düzeyi Filtreler) bölümüne girin.
3. Tüm e‑postaları yakalayacak bir kural oluşturun (örneğin “To” alanı boş değil ise gibi çok geniş bir koşul).
4. Eylem (Action) olarak “Redirect to email” seçin ve [email protected] adresine yönlendirin.

Bu, gelen e‑postalar için işinizi görür. Giden e‑postalar içinse, kullanıcıların SMTP kimliği üzerinden filtreleme, ya da e‑posta istemcisine kural yazarak “gönderilenlerin bir kopyasını BCC ile şu adrese gönder” kuralı tanımlamak gerekebilir. Sunucu taraflı tam kapsama ulaşmak istiyorsanız genellikle VPS üzerinde kendi mail sunucunuzu kurmak daha esnek olur; birazdan bunu detaylandıracağız.

2) cPanel “Archive” / e‑posta disk kullanımının doğru yönetimi

Bazı sunucu kurulumlarında cPanel’in arşiv (Archive) özelliği aktif olabilir. Bu özellik, belirli protokoller (POP3/IMAP) ve webmail erişimlerine göre, gelen/giden e‑postalardan otomatik kopyalar tutabilir. Ancak:

• Her hosting sağlayıcısı bu özelliği açık tutmaz.
• Disk kullanımını hızla şişirebilir; kotaları iyi yönetmek gerekir.

Bu noktada yapılması gerekenler:

• Arşiv hesabı için yüksek kotaya sahip ayrı bir alan tanımlamak (gerekirse ayrı bir paket veya üst seviye çözüme geçmek).
• cPanel’deki “E‑posta Disk Kullanımı” ekranını düzenli takip ederek, hangi hesabın ne kadar alan tükettiğini görmek.
• Belirli klasörler (örneğin 7+ yıl öncesi) için manuel veya otomatik silme / dışa aktarma politikaları uygulamak.

3) Harici e‑posta arşivi ile entegrasyon (IMAP tabanlı)

Eğer cPanel tarafında disk kotası sınırlıysa, işin bir kısmını harici bir arşiv sistemine kaydırabilirsiniz. Örneğin:

• cPanel’de arşiv posta kutusunu sadece geçici buffer gibi kullanıp,
• Harici bir sunucuya veya depolama sistemine IMAP senkronizasyonu (örneğin belirli aralıklarla çalışan bir script) ile mesajları taşıyıp,
• cPanel tarafındaki eski mailleri, belirli bir süreden sonra otomatik silmek.

Bu modelde “sıcak” arşiv cPanel üzerinde, “soğuk / uzun dönemli” arşiv ise daha uygun maliyetli bir depolama üzerinde tutulur. Uzun dönemli depolama için nesne tabanlı çözümler kullanmak isterseniz, önce S3 uyumlu depolamanın mantığını ve ardından da object vs block vs file storage karşılaştırmasını okumanız, maliyet/performans dengesini kurarken size ciddi avantaj sağlar.

VPS üzerinde kurumsal seviye e‑posta journaling mimarisi

Kendi VPS’iniz üzerinde Postfix + Dovecot gibi bileşenlerle mail sunucusu çalıştırıyorsanız, journaling ve arşivleme konusunda çok daha esnek ve güçlü seçeneklere sahipsiniz. Burada artık iş, sunucu konfigürasyonu + depolama mimarisi + retention politikası üçlüsünü iyi tasarlamaya kalıyor.

VPS üzerinde sıfırdan e‑posta altyapısı kurmaya yeni başladıysanız, önce Postfix + Dovecot ile VPS’te e‑posta sunucusu kurulum rehberimizi okumanızı öneririz; orada temel MTA/MDA yapısını kurduktan sonra, bu yazıdaki journaling ve arşiv katmanını üzerine inşa etmek çok daha kolay olacaktır.

Postfix tarafında journaling: always_bcc ve bcc_maps

Postfix’te en pratik journaling yöntemlerinden biri, always_bcc veya sender_bcc_maps / recipient_bcc_maps parametrelerini kullanmaktır:

• always_bcc = [email protected] → Sunucudan geçen tüm e‑postalara BCC kopyası ekler.
• sender_bcc_maps → Gönderen adrese göre farklı journaling kuralları uygulamanıza izin verir (örneğin yalnızca @firma.com kullanıcıları için).
• recipient_bcc_maps → Hedef adrese göre kural yazabilirsiniz (örneğin sadece yöneticiler için).

Böylece:

• Kullanıcı bir e‑postayı silse bile,
• Arşiv posta kutusunda veya arşiv sunucusunda tam kopya kalmaya devam eder.

Bu ayarları yaparken mutlaka:

• Arşiv için ayrı bir domain veya alt alan adı (ör. arsiv.firma.iç) tercih etmeyi,
• Arşiv kutusuna sadece yetkili kişilerin erişebildiğinden emin olmayı,
• Trafiğin tamamında TLS şifreleme kullanmayı

İpucu: Arşiv için ayrı bir VPS veya dedicated sunucu kullanıyorsanız, bu sunucuya erişimi sadece VPN veya IP kısıtlaması üzerinden vermek, güvenlik açısından büyük fark yaratır.

Dovecot/Sieve ile klasör bazlı arşivleme

Journaling’in yanında, kullanıcı tarafındaki IMAP klasör yapısını da arşiv süreçlerine dahil edebilirsiniz. Dovecot ile:

• Belirli klasörlere taşınan e‑postaların (ör. “Arşiv/2023”) sunucu tarafında farklı bir diske veya harici sisteme kopyalanmasını,
• Sieve filtreleri ile belirli yaşın üzerindeki (ör. 3 yıldan eski) e‑postaların otomatik olarak arşiv hesabına taşınmasını

sağlayabilirsiniz. Böylece hem journaling ile “her şeyin kopyasını aldığınız” bir katmanınız, hem de kullanıcıların kendi isteklerine göre e‑postaları klasörlere ayırdığı bir arşiv düzeniniz olur.

Tek VPS’te basit journaling senaryosu (örnek)

Diyelim ki 40 kişilik bir hukuk bürosu, tüm mail trafiğini kendi VPS’i üzerinde barındırıyor. Hedef:

• Tüm gelen/giden e‑postaların kopyasının tutulması (KVKK uyumlu şekilde),
• İhtiyaç halinde belirli kullanıcı ve tarihler için hızlı arama yapılabilmesi,
• Depolama maliyetinin kontrolde kalması.

Örnek çözüm:

1. VPS üzerinde [email protected] benzeri bir posta kutusu açın.
2. Postfix’te recipient_bcc_maps ile sadece @firma.com alan adı için journaling tanımlayın.
3. Dovecot tarafında arşiv kutusuna sadece iki yetkili kullanıcının (ör. hukuk ve BT yöneticisi) erişmesine izin verin.
4. Her gece çalışan bir cron job ile 3 yıldan eski e‑postaları sıkıştırılmış formatta (ör. .gz) “soğuk arşiv” dizinine taşıyın.
5. Soğuk arşiv dizinini haftalık olarak, uzak bir depolama alanına (ör. nesne depolama) şifreli yedekleyin.

Bu modelde hukuki gereklilikler büyük oranda karşılanırken, VPS üzerindeki operasyonel riskler ve depolama maliyetleri de yönetilebilir seviyede tutulmuş olur.

Depolama planlama: disk, nesne depolama ve ölçeklenebilirlik

cPanel veya VPS üzerinde e‑posta arşivleme planlarken en çok atlanan konulardan biri, orta/uzun vadeli depolama ihtiyaçlarının hesaplanması. Özellikle journaling ile her şeyin kopyasını almaya başladığınızda, veri hacmi beklediğinizden çok daha hızlı büyüyebilir.

Basit kapasite hesabı nasıl yapılır?

Kaba bir tahmin için şu soruları yanıtlayın:

• Kaç aktif kullanıcı var? (ör. 50)
• Kişi başı günlük ortalama kaç e‑posta alıp gönderiyor? (ör. 80 mail)
• Ortalama e‑posta boyutu nedir? (metin ağırlıklı ise 75–150 KB, ekli dosya ağırlıklı ise 300 KB–1 MB arası düşünülebilir)
• Kaç yıl saklamak istiyorsunuz? (ör. 5 yıl)

Örneğin: 50 kullanıcı × 80 mail/gün × 0,3 MB ortalama boyut × 365 gün × 5 yıl ≈ 21,9 TB gibi bir hacim ortaya çıkabilir. Sıkıştırma, spam filtreleme ve bazı maillerin arşiv dışı kalmasıyla bu rakam düşecektir ama kabaca terabayt seviyesinde depolama planlamanız gerektiği görülüyor.

Sıcak / soğuk arşiv ayrımı

Bu noktada, depolama maliyetini kontrol altında tutmak için tipik yaklaşım şu olur:

• Sıcak arşiv: Son 6–12 aya ait e‑postalar; sık erişilen, hızlı disk (NVMe/SATA SSD) üzerinde tutulur.
• Soğuk arşiv: 1 yıldan eski e‑postalar; daha maliyet etkin disklerde veya nesne depolamada saklanır, erişim süresi biraz daha uzun olabilir.

DCHost altyapısında, örneğin:

• cPanel veya VPS’iniz üzerinde sıcak arşivi tutup,
• Soğuk arşivi ayrı bir VPS, dedicated sunucu ya da nesne depolama çözümü üzerinde saklayarak

hem performansı hem de maliyeti dengelemeniz mümkün. Nesne depolamayı yedek ve arşiv için kullanmayı düşünüyorsanız, S3 depolama nedir yazısından sonra, restic/borg ile S3 uyumlu uzak yedekleme stratejilerini de incelemenizi öneririz.

Retention (saklama süresi) politikaları: KVKK, GDPR ve şirket içi kurallar

Teknik tarafı ne kadar iyi kurarsanız kurun, ne kadar süreyle hangi veriyi saklayacağınızı yazılı bir politika haline getirmediğiniz sürece, KVKK/GDPR tarafında kendinizi rahat hissedemezsiniz.

Hukuki çerçeveye kısaca bakış

KVKK ve GDPR, özetle şu prensibi ortaya koyar:

• Veriyi, işleme amacının gerektirdiği süre boyunca saklayabilirsiniz.
• Gereksiz yere uzun süre saklamak, sorumluluk doğurur.
• Veri sahibinin “unutulma hakkı” gibi haklarını kullanabilmesi için, teknik olarak da silmeyi uygulayabilmeniz gerekir.

Dolayısıyla “biz her şeyi sonsuza kadar tutuyoruz, ne olur ne olmaz” yaklaşımı, günümüz mevzuatında riskli bir stratejidir. KVKK ve GDPR boyutunu daha geniş çerçevede ele aldığımız KVKK ve GDPR uyumlu hosting seçimi rehberi, veri yerelleştirme ve silme süreçleri için iyi bir tamamlayıcı okuma olabilir.

Pratik retention örnekleri

Şirketler arasında sık gördüğümüz basitleştirilmiş modeller:

• Genel kullanıcı kutuları: 3–5 yıl saklama, sonrasında otomatik silme.
• Finans / muhasebe: 5–10 yıl (yerel mevzuata göre değişebilir).
• Hukuk / sözleşme: Davaların zamanaşımı sürelerine göre 10–15 yıl.
• İK / özlük: Çalışma ilişkisi sona erdikten sonra belirli yıl sayısı (ülke mevzuatına göre).

Bunlar elbette hukuki danışmanlık yerine geçmez; ancak teknik planlama yaparken “herkese aynı süre” yerine departman bazlı farklı retention düşünmeniz gerektiğini gösterir.

Retention’ı teknik olarak nasıl uygularsınız?

cPanel ve VPS tarafında retention’ı hayata geçirmenin birkaç yaygın yolu var:

• IMAP Auto-Expunge / Auto-Archive: Belirli klasörlerde belirli gün sayısını aşan e‑postaların otomatik silinmesi.
• Dovecot plugin’leri veya script’ler: Örneğin, her gece çalışan bir cron ile ilgili posta kutusunda 5 yıldan eski e‑postaları arayıp silen veya “soğuk arşiv”e taşıyan script.
• cPanel tarafında periyodik dışa aktarma: Özellikle küçük yapılarda, her yıl sonunda ilgili klasörleri .zip/.mbox olarak indirip, sunucu tarafında bu eski klasörleri temizlemek.

Burada dikkat edilmesi gereken kritik nokta: Silme işlemleri geri alınabilir mi? Yani, retention politikası gereği e‑postayı hem canlı sistemden hem de arşivden silmek zorunda kalırsanız, yedeklerden geri dönmemeniz gerekiyor. Aksi halde “unutulma hakkı” pratikte gerçekleşmemiş sayılır. Bu nedenle, retention kurallarınızı yazarken, yedekleme stratejiniz ile çelişmeyecek bir denge kurmanız kritik.

Gerçekçi örnek senaryolar

Senaryo 1: 25 kişilik ajans, cPanel üzerinde hızlı çözüm istiyor

Durum:

• Tüm e‑postalar cPanel üzerinde.
• Henüz VPS’e geçmeye gerek yok; trafik ve hacim küçük/orta seviyede.
• Müşterilerle yazışmalar kritik, kaybolmaması lazım.

Önerilen çözüm:

1. cPanel’de [email protected] adresini açın, yüksek kota verin.
2. Hesap düzeyi filtreyle tüm gelen e‑postaların bir kopyasını bu adrese yönlendirin.
3. Kullanıcıların e‑posta istemcilerine (Outlook vb.) “tüm gidenlere BCC: [email protected]” kuralı ekletin.
4. Arşiv hesabını ayda bir inceleyin; 2 yıldan eski klasörleri .zip olarak indirip, sunucudan silin. Arşiv .zip dosyalarını şifreleyip, güvenli bir depolama alanında saklayın.
5. cPanel hesabının tamamı için haftalık otomatik yedekleri açın ve yedeklerin başka bir sunucuda saklandığından emin olun.

Bu model, küçük ajanslar için hızlı, düşük maliyetli ve pratik bir başlangıç sağlar. Zamanla e‑posta hacmi ve regülasyon baskısı arttığında, VPS tabanlı daha kurumsal bir journaling mimarisine geçmek planlanabilir.

Senaryo 2: 80 kişilik SaaS şirketi, VPS üzerinde tam journaling istiyor

Durum:

• Şirketin hem kendi müşterilerine gönderdiği bildirim e‑postaları, hem de iç yazışmalar kritik.
• Veri merkezi ve hosting tarafta sürdürülebilirlik, güvenlik ve ölçeklenebilirlik önemli.

Önerilen çözüm:

1. DCHost üzerinde bir VPS kümesi tasarlayın: Biri uygulama, biri e‑posta, biri de arşiv/backup odaklı olabilir. Veri merkezi tarafındaki sürdürülebilirlik ve kapasite planlama konularına ilginiz varsa, veri merkezi sürdürülebilirliği yazımız güzel bir arka plan sunar.
2. E‑posta VPS’inde Postfix + Dovecot kurun, SPF/DKIM/DMARC yapılandırmasını ilgili rehberimizdeki adımlarla tamamlayın.
3. Postfix’te sender_bcc_maps ve recipient_bcc_maps kullanarak tüm @firma.com trafiğini [email protected] adresine BCC’leyin.
4. Arşiv VPS’inde journal posta kutusunu çok daha geniş disk alanı ve nesne depolama entegrasyonu ile çalıştırın; 1 yıldan eski mailleri otomatik olarak soğuk arşive taşıyın.
5. Retention politikalarına göre (ör. 7 yıl) belirli tarihten eski e‑postaları hem sıcak hem soğuk arşivden script’lerle silin; silme işlemlerini loglayın.
6. 3‑2‑1 yedekleme stratejisini uygulayın: 3 kopya, 2 farklı ortam, 1 tanesi farklı lokasyonda olacak şekilde; bunu nasıl kurgulayacağınızı 3‑2‑1 yedekleme stratejisi rehberimizde detaylı anlattık.

Bu senaryoda, hem hukuki gereklilikler hem de teknik en iyi pratikler büyük ölçüde karşılanmış olur. Ek olarak, VPS log yönetimini merkezi bir forma çekmek isterseniz, VPS log yönetimi rehberimiz size çok yardımcı olacaktır.

DCHost altyapısında doğru yaklaşımı seçerken nelere dikkat etmeli?

Son olarak, cPanel ve VPS tarafında hangi yolu seçeceğinizi netleştirirken göz önünde bulundurmanız gereken başlıca noktaları toparlayalım.

• Kullanıcı sayısı ve trafik hacmi: 10–20 kullanıcılı küçük bir ekip için cPanel’de BCC tabanlı çözüm çoğu zaman yeterli olur. 50+ kullanıcı, yüksek ek trafiği ve regülasyon baskısı varsa, VPS veya dedicated alana geçmek daha mantıklı.
• Regülasyon seviyesi: Finans, hukuk, sağlık gibi alanlarda faaliyet gösteriyorsanız, journaling’i mutlaka sunucu tarafında (VPS/dedicated) kurup, arşivi ayrı disk/nesne depolama ile desteklemeyi düşünün.
• Teknik ekip yetkinliği: Kendi VPS’inizi yönetmeye hazır mısınız? Değilseniz, yönetilen (managed) hizmetleri veya DCHost mühendisleriyle birlikte planlanmış çözümleri tercih etmek operasyonu sadeleştirir.
• Depolama maliyeti: En baştan 3‑5 yıllık projeksiyon yapın. Sadece bugünün disk ihtiyacına bakarsanız, 2–3 yıl sonra ani kapasite krizleriyle karşılaşabilirsiniz.
• Güvenlik ve erişim kontrolleri: Arşiv posta kutusuna kimler erişecek, hangi işlemleri yapabilecek? Tüm bu soruları cevaplayıp, rol bazlı yetkilendirme yapmak şart.

DCHost olarak bizim yaklaşımımız, e‑posta arşivleme ve yasal saklama konusunu sadece “fazladan disk alanı” gibi görmemek. Doğru kurgulanmış bir journaling ve retention mimarisi, olası bir uyuşmazlıkta veya güvenlik olayında şirketinizin elini güçlendirirken; KVKK/GDPR gibi regülasyonlara uyum sürecinizi de hem teknik hem operasyonel olarak çok daha rahat hale getiriyor.

Özet ve sonraki adımlar

Bu rehberde, cPanel ve VPS ortamında e‑posta arşivleme, journaling, depolama planlaması ve retention politikalarını uçtan uca ele aldık. Özetle:

• Journaling, tüm e‑posta trafiğinin değiştirilemeyen bir kopyasını oluşturur; kullanıcının posta kutusundan bağımsızdır.
• Arşiv, yedekten farklıdır; uzun dönemli, aranabilir, tutarlı bir yapıya ihtiyaç duyar.
• cPanel’de BCC ve filtre tabanlı çözümlerle, küçük/orta ölçekli yapılar için makul bir başlangıç sağlamak mümkündür.
• VPS üzerinde Postfix + Dovecot ile tam teşekküllü journaling, sıcak/soğuk arşiv ve ince ayarlı retention politikaları kurabilirsiniz.
• KVKK ve GDPR, veriyi “mümkün olan en kısa süre” prensibiyle yönetmenizi; yani hem saklamayı hem de zamanında silmeyi zorunlu kılar.

Şimdi atabileceğiniz pratik adımlar şunlar olabilir:

1. Mevcut e‑posta yapınızı envanterleyin: cPanel mi, VPS mi, hibrit mi?
2. Hukuk ve İK ile birlikte, departman bazlı saklama sürelerini yazılı hale getirin.
3. Küçük başlayın: Önce basit bir journaling kutusu açıp, sadece belirli departmanları dahil edin.
4. Depolama grafiğini 1‑3 yıllık projeksiyonla planlayın; sıcak/soğuk arşiv ayrımını netleştirin.
5. Yedekleme ve silme süreçlerinin birbiriyle çelişmediğinden emin olun.

Eğer “bizim senaryomuz biraz daha karmaşık, hem cPanel, hem VPS, hem de harici servisler var” diyorsanız, DCHost ekibiyle birlikte somut bir mimari tasarlamak çoğu zaman en hızlı yol oluyor. Mevcut e‑posta altyapınızı ve regülasyon ihtiyaçlarınızı birlikte değerlendirip, teknik olarak uygulanabilir, sürdürülebilir ve maliyeti yönetilebilir bir arşiv/journaling çözümünü adım adım planlayabiliriz.