Google Workspace vs Kendi Mail Sunucun: 2026 Maliyet Karşılaştırması

E-posta; alan adı, teslim edilebilirlik (deliverability), güvenlik ve süreklilik zincirinin merkezinde. Google Workspace kullanmak ile kendi mail sunucunu (self-hosted) kurmak arasında karar verirken sadece “aylık ücret”e bakmak yanıltıcı olur. Bu rehberde, Google Workspace ile kendi mail sunucun yaklaşımını 2026 için maliyet kalemlerine ayırıp net bir maliyet çerçevesi kuracağız. Sonunda da hangi senaryoda hangi seçimin daha ekonomik ve daha kontrollü olduğunu, somut kriterlerle belirleyeceksiniz.

Maliyetleri hangi kalemlere ayırmalısın?

Mail sistemi maliyeti üç katmanda çıkar: (1) lisans/abonelik, (2) altyapı ve işletme, (3) güvenlik ve operasyon. Google Workspace bu kalemlerin büyük kısmını paketler; kendi sunucunda ise her kalemi ayrı ayrı yönetirsin.

1) Lisans ve abonelik maliyeti

• Google Workspace: Kullanıcı başına aylık abonelik (planlar: Business Starter/Standard/Plus gibi). Ayrıca ek depolama veya ek yeteneklerde plan farkları olur.
• Kendi mail sunucu: Sunucu işletim sistemi lisansı genellikle “kurulum” açısından ek ücret gerektirmez (Linux yaygın), fakat mail yazılımı (ör. Postfix + Dovecot + SOGo/Roundcube) için lisans genelde düşük ya da yoktur. Asıl maliyet “operasyon” tarafındadır.

2) Altyapı ve bant genişliği

• Google Workspace: E-posta iletimi, depolama ve yedeklilik altyapısı Google’a aittir. Senin ayrıca mail için “VM kapasitesi” planlaman gerekmez.
• Kendi mail sunucu: Şunları satın alman gerekir:
• Mail için bir VPS/VDS (virtual private server) veya dedicated sunucu
• Disk kapasitesi (posta kutuları + ekler)
• CPU/RAM (özellikle yoğun trafik, indeksleme, spam filtreleme)
• Yedekleme (backup) için ayrıca depolama
• Gerekiyorsa mail arşiv

3) Güvenlik, teslim edilebilirlik ve operasyon

• Google Workspace: DKIM/DMARC/SPF gibi kimlik doğrulama, spam altyapısı, yönlendirme ve raporlama Google ekosisteminde daha hazır çalışır.
• Kendi mail sunucu: Teslim edilebilirlik için; ters DNS (PTR), doğru SPF/ DKIM/ DMARC, spam/graylisting politikaları, abuse yönetimi ve log takibi gerekir. Bu alanlarda “maliyet” zaman ve uzmanlık olarak ortaya çıkar.

Google Workspace maliyeti: kullanıcı başı modelin pratik sonucu

Google Workspace’te maliyetin en büyük bileşeni “kullanıcı sayısı x aylık abonelik”tir. Ek olarak domain bağlantısı, yönetim konsolu kullanımı, kullanıcı yaşam döngüsü (aktif/pasif), arşivleme gibi fonksiyonlar plana göre değişir.

Google Workspace’te toplam maliyeti etkileyen başlıca değişkenler

• Kullanıcı sayısı
• Plan seçimi (depolama ve ek özellik farkları)
• Ek depolama gereksinimi
• Arşiv/uyumluluk ihtiyacı (türüne göre maliyet artar)

“Gizli maliyet” var mı?

Varsa bile genellikle kendi sunucundaki gibi “altyapı + operasyon ekipmanları” biçiminde değildir. Örneğin kendi sunucunda saat bazlı iş çıkaran şeyler (log izleme, yedekleme, güvenlik yamaları) Google tarafında yönetilir. Sen yine de admin tarafında temel kontrolleri yaparsın (MX kaydı, DKIM/DMARC ayarı, kullanıcı yönetimi).

Kendi mail sunucunun maliyeti: VM + bakım + güvenlik denklemi

Kendi mail sunucunda maliyet tek kalem değildir; özellikle ilk kurulumdan sonra “sürekli bakım” ve “güvenlik/doğrulama” işleri düzenli gider yaratır.

Hangi altyapı seviyeleri gerçekçi?

Mail trafiği ve kullanıcı sayısına göre en yaygın üç yaklaşım: 1. Tek VDS/VM (küçük ekip) 2. İki katman (SMTP giriş katmanı + depo katmanı, daha kontrollü) 3. Dedicated + mimari (yüksek hacim/kurumsal gereksinimler)

NetKıyas’ta sık görülen tablo: mail için kullanılan VDS/VPS’in kaynakları (CPU/RAM) tek başına yeterli değildir; disk IOPS ve depolama düzeni de süreçte rol oynar (özellikle arama, indeksleme, büyük ek dosyaları).

Kendi sunucunda maliyet kalemleri

Aşağıdaki liste, bütçeleme yaparken unutulmaması gereken başlıkları özetler: - Sunucu (VDS/VPS/Dedicated): aylık kiralama - Disk: posta kutuları büyüdükçe artar - Yedekleme (backup): hem yerel hem uzak hedef (ör. farklı depolama) - Güvenlik: güncelleme, sertifika yenileme, saldırı yüzeyi yönetimi - Teslim edilebilirlik: PTR, SPF/DKIM/DMARC, IP itibar (reputation) yönetimi - Spam/virus filtresi: servisler ve konfigürasyon - Operasyon zamanı: log analizi, kuyruğa takılan iletiler, hata ayıklama

Operasyon maliyetini sayısallaştırmanın net yolu

Saat maliyeti şudur: “yapılan bakım/arıza saati x kişi saat maliyeti”. Kendi sunucunda genellikle en çok zaman harcananlar: - DKIM/DMARC sorunları (yanlış anahtar/yanlış kayıt) - Teslim edilmeyen e-postalar (queue, blackhole, itibar sorunları) - Güncelleme sonrası uyumsuzluk - Disk dolması, quota aşımı

2026 için örnek maliyet kıyası (kural: tek sayı yerine senaryo)

Tek bir “kesin rakam” vermek doğru olmaz; çünkü Google plan fiyatları, kendi sunucunun disk ihtiyacı ve ekip saat maliyeti senaryoya bağlı. Bu yüzden en net kıyas yöntemi: kullanıcı sayısı ve saklama ihtiyacına göre üç senaryo.

Senaryo varsayımları

• Kullanıcı sayısı: 5 / 15 / 30
• Depolama: kullanıcı başına değişken (ekler ve posta hacmine bağlı)
• Kendi sunucunda temel hedef: e-posta güvenilirliği + yedek + teslim edilebilirlik kontrolleri

Karşılaştırma matrisi (bütçe planlama için)

Aşağıdaki tablo “maliyeti ne belirler?” sorusunun cevabını netleştirir. Burada amaç, hangi kalemlerin Google’da azaldığını; kendi sunucunda neden arttığını görmektir.

Eşik (break-even) nasıl hesaplanır? Net formül

“Google daha ucuz mu, kendi sunucum daha ucuz mu?” sorusunun doğru cevabı, şu eşitlik etrafında bulunur:

Kendi sunucu toplam maliyet = (VM/VDS + yedek depolama + güvenlik/operasyon zamanı + olağan bakım) + beklenen arıza/riske maliyet

Google maliyeti: (kullanıcı sayısı x aylık Google abonelik) + (ihtiyaca göre ek plan/dep. değişkenleri)

Beklenen arıza maliyeti nasıl dahil edilir?

E-posta kesintisi “soğuk bir arıza” değildir; iletişim ve iş akışını etkiler. Beklenen arıza maliyeti için pratik yöntem: - Geçmişte oluşan downtime örnekleri yoksa: ilk 6 ay “kurulum/ince ayar” kaynaklı daha yüksek risk varsay. - “Olası bir problemde” çözmek için gereken ortalama saat x saat maliyeti - Bu değeri aylığa bölerek ekle.

Kendi sunucunda ilk aylarda bu kalem daha belirgindir; Google’da bu kalem daha küçüktür.

Kendi sunucunu seçersen maliyeti kontrol altına alan 8 net aksiyon

Kendi sunucunu ekonomik ve yönetilebilir tutmak için “operasyon maliyetini azaltan” kararlar gereklidir.

1) Yedekleme stratejisini doğru kur

• Posta geri dönüşü için yalnızca dosya kopyalamak yetmez; uygulama seviyesinde restore doğrulaması yapılmalıdır.
• Yedek (backup) hedefini ayrı depolama üzerine taşı.

2) Güncelleme planı oluştur

• Postfix/Dovecot/antivirus/spam filtre bileşenleri düzenli güncellenmeli.
• Güncelleme sonrası temel doğrulamalar için kontrol listesi tut.

3) DMARC politikasını adım adım uygula

• “Quarantine/Reject” gibi katı politikalar aniden uygulanınca teslimat etkilenebilir.
• Önce “monitoring (none)” ile rapor topla, sonra sıkılaştır.

4) Spam/virus kuyruğunu (queue) izleme

• Queue büyürse CPU/RAM ve disk IOPS baskılanır.
• Basit metrikler: bekleme süresi, ortalama gecikme, günlük iletim sayısı.

5) Disk dolmasını engelleyen otomasyon

• Mail sistemlerinde en büyük gerçek problem: disk dolması ve quota taşmaları.
• Log retention ve rotasyon ile disk planını birlikte düşün.

6) Doğru kaynak planlaması: IOPS ve disk performansı

• Mail depolaması ve indeks süreçleri için düşük performans “mail gecikmesi” olarak döner.
• Disk gereksinimi yalnızca GB değildir; IOPS/latency da maliyete yansır.

7) Basit ama etkili erişim güvenliği

• SSH/servis erişimini kısıtla, portları minimumda tut.
• Sertifika yenilemelerini takip et.

8) En az bir “felaket senaryosu” prova et

• Sunucu düşerse ne yapacaksın? Yedekten restore mi, hazır replikasyon mu?
• Bu prova, gelecekte arıza maliyetini düşürür.

Sonuç: Hangi durumda hangisi daha ekonomik?

Eğer hedefin “yönetim yükü düşük, teslim edilebilirliği yüksek, öngörülebilir aylık maliyet” ise Google Workspace, çoğu küçük-orta ekipte kendi sunucuna göre daha net bir toplam maliyet sunar; özellikle e-posta bakımını “ek bir operasyon” olarak görmüyorsan. Kullanıcı sayısı yükseldikçe ve arşiv/uyumluluk gibi ihtiyaçlar netleştiğinde Google tarafının tahmin edilebilirliği artar.

Eğer hedefin “kurumsal mimari kontrol, özel ihtiyaçlar, uzun vadede işletme ekibiyle yönetim” ise kendi mail sunucun ekonomik olabilir; ancak bunu ancak yedek/restore doğrulama, DMARC adım adım, disk/IOPS planı ve operasyon provaları olmadan “ucuz” diye seçmek doğru değildir.

Aksiyon önerisi: Önce kullanıcı sayını ve beklenen posta hacmini (aylık gelen-giden + ek boyutları) çıkar, sonra iki senaryonun toplamını aynı kalemlerle hesapla: Google için “kullanıcı başı abonelik”, kendi sunucu için “VM + yedek + saat cinsinden operasyon + arıza/restore riski”. Bu iki toplamı aynı tabloda netleştirdiğinde doğru karar hemen görünür.