Kurumsal E-Posta mı Google Workspace mi? Hangisi Yeterli

Şirket maili alma sırası geldiğinde soru hep aynı biçimde kuruluyor: kurumsal e-posta mı Google Workspace mi, yani hosting paketine zaten dahil olan mail hesaplarıyla mı idare edilir yoksa kullanıcı başına aylık ücret ödenen bir bulut e-posta servisine mi geçilir? Beş kişilik bir ekipte bu karar önemsiz görünür; on beş kişiye çıktığınızda faturaya yansır, kırk kişide ise geri dönmesi zor bir altyapı kararına dönüşür. İşin kötüsü, konuyu anlatan içeriklerin çoğu ya bulut servis bayisi ya da barındırma firması tarafından yazılmış oluyor ve iki tarafın da anlatmadığı kalemler tam da kararı belirleyen kalemler.

Bu yazıda ikisini yan yana koyup gerçekten fark yaratan altı başlığı tek tek açıyorum: teslim edilebilirlik ve SPF/DKIM/DMARC sorumluluğunun kimde olduğu, kutu başına depolama ve bunun ne kadar sürede dolduğu, arşiv ile yedeğin bu iki dünyada neden aynı şey olmadığı, mobil ve çoklu cihaz senkronizasyonunun protokol farkı, kullanıcı sayısı arttıkça maliyet eğrisinin nasıl büküldüğü ve yönetim/denetim tarafındaki farklar. Sonunda hangi ölçekte hangisinin mantıklı olduğuna dair somut bir karar tablosu ve çoğu yerde hiç konuşulmayan karma model var.

Hosting E-Postası ile Google Workspace Arasındaki Temel Fark#

Temel fark, e-postanın nerede saklandığı değil, kimin işlettiğidir. Hosting'e dahil e-postada mail sunucusu (tipik olarak Exim/Dovecot ya da Postfix/Dovecot) barındırma hesabınızın olduğu makinede çalışır; kutular disk kotanızdan yer kaplar, kimlik doğrulama ve spam filtresi sunucudaki yapılandırmaya bağlıdır. Google Workspace'te ise kutular Google'ın altyapısında durur, siz sadece alan adınızın MX kayıtlarını oraya yönlendirirsiniz.

Bu farkın doğrudan sonuçları şunlardır:

• Alan adı her iki durumda da sizindir. @sirketiniz.com adresi servise değil, alan adına bağlıdır; taşınmak istediğinizde MX kaydını değiştirirsiniz.
• Disk hesabı farklıdır. Hosting e-postasında mail kutuları web sitenizle aynı diski paylaşır. Workspace'te web sitesi ile e-posta tamamen ayrı yaşar.
• Arıza yüzeyi farklıdır. Hosting sunucunuz yoğunlaşırsa hem site hem mail etkilenir; MX'i dışarı verdiğinizde sitede yaşanan bir sorun maili etkilemez.
• Kontrol farklıdır. Kendi sunucunuzda kural yazabilir, günlükleri okuyabilir, bir mesajın neden reddedildiğini satır satır görebilirsiniz. Bulut serviste bu görünürlük yönetim panelinin size gösterdiği kadardır.

E-posta hesabı açmanın temel adımlarına aşina değilseniz önce kutu oluşturma ve DNS bağlama işini görmek işinizi kolaylaştırır; bu yazı o adımların üzerine karar katmanını ekliyor.

Teslim Edilebilirlik: SPF, DKIM ve DMARC Kimin Sorumluluğunda#

Teslim edilebilirlikte belirleyici olan servis değil, DNS kayıtlarınızın doğruluğu ve gönderim itibarınızdır — ve bu sorumluluk her iki modelde de büyük ölçüde sizde kalır. Yaygın yanılgı, "Workspace'e geçersem maillerim spama düşmez" cümlesidir. Doğrusu şudur: bulut servis size yüksek itibarlı bir gönderim havuzu ve otomatik DKIM imzalama imkânı verir, ama SPF ve DMARC kaydını yine sizin alan adınıza siz yazarsınız ve yanlış yazarsanız sonuç değişmez.

Kayıtlar tipik olarak şöyle görünür:

; SPF — sadece TEK bir SPF (TXT) kaydı olmalı
sirketiniz.com.   IN TXT  "v=spf1 include:_spf.saglayici.com -all"

; DKIM — seçici (selector) adı servise göre değişir
varsayilan._domainkey.sirketiniz.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

; DMARC — önce izleme modunda başlayın
_dmarc.sirketiniz.com.  IN TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

Kontrol için:

dig +short TXT sirketiniz.com
dig +short TXT varsayilan._domainkey.sirketiniz.com
dig +short TXT _dmarc.sirketiniz.com
dig +short MX sirketiniz.com

İki modelin sorumluluk dağılımı şöyle ayrışır:

En sık gördüğüm hata, geçiş sırasında eski SPF kaydının silinmeyip yenisinin eklenmesidir. İki SPF kaydı olan alan adında doğrulama permerror verir ve iyi niyetli maliniz bile şüpheli sayılır. İkinci sık hata, DMARC'ı doğrudan p=reject ile başlatmaktır; henüz imzalanmayan bir alt sistem (ör. site iletişim formu, e-ticaret bildirim maili) varsa o mailler bir gecede kaybolur. Kayıtların anlamı ve doğru sıralaması için spf dkim dmarc yazısı ayrıntılı; mailler yine de spama düşüyorsa teşhis akışı mailler spama düşüyor yazısında adım adım var.

Kritik nokta şu: hangi servisi seçerseniz seçin, siteden çıkan otomatik mailler ayrı bir dünyadır. Sipariş onayı, şifre sıfırlama, form bildirimi gibi mesajlar genellikle web sunucusundan çıkar ve MX'inizi Workspace'e vermeniz bunları imzalamaz. Bu maillerin de düzgün gitmesi için ya sunucuyu SMTP kimlik doğrulamasıyla servise bağlarsınız ya da ayrı bir gönderim yolu kurarsınız.

Depolama: Kutu Başına Alan ve Doldurma Hızı#

Depolamada ayrım şudur: hosting e-postasında kutular paylaşılan bir havuzdan yer alır, bulut serviste kullanıcı başına tahsis edilmiş alan vardır. Bu, faturadan çok daha somut bir farktır.

Paylaşımlı hosting hesabında toplam disk alanı hem public_html hem de mail/ dizinini kapsar. Yani bir kullanıcının 8 GB'lık ekiyle dolu kutusu, sitenizin yedek alanını yiyebilir. Disk dolduğunda iki şey aynı anda olur: yeni mailler over quota ile reddedilmeye başlar ve site tarafında yazma gerektiren işlemler hata verir. Kotanın kutu bazında sınırlanması bu yüzden şart:

# Hangi kutular ne kadar yer kaplıyor (cPanel tipi bir düzende)
du -sh ~/mail/sirketiniz.com/* | sort -h | tail -20

# Toplam mail alanı
du -sh ~/mail

Kutu kotalarını panelden kullanıcı bazında ayarlamak için cpanel e-posta kotası yazısındaki adımları izleyin. Kotayı "sınırsız" bırakmak, tek bir kullanıcının tüm hesabı kilitlemesine açık kapı bırakır.

Doldurma hızını hesaplamak zor değil. Ortalama bir ofis kullanıcısı günde 40-80 mesaj alır; ekli mesajların ağırlığı ortalamayı belirler. Ekleri bol bir satış veya muhasebe biriminde kutu yılda birkaç GB büyür. Karar verirken şunu sorun: beş yıl sonra bu kutu ne kadar olacak ve o alan hosting paketimin neresinden çıkacak? Cevap "paketimin yarısı" ise mail'i siteden ayırma vakti gelmiş demektir.

Bulut tarafında alan kullanıcıya tahsislidir ve dolduğunda o kullanıcı için ek alan satın alınır; site diskinizi etkilemez. Buna karşılık ekiplerin klasik alışkanlığı olan "hiçbir şeyi silmeme" davranışı burada doğrudan tekrar eden maliyete dönüşür.

Arşiv ve Yedek: İki Dünyada Aynı Şey Değil#

Yedek ile arşiv karıştırıldığı için burada çok veri kaybediliyor. Yedek, kaza sonrası geri dönüş içindir; arşiv, kaydın uzun süre değiştirilemez biçimde saklanması içindir. İki modelde ikisi de farklı çalışır.

Hosting e-postasında kutularınız sunucunun yedekleme döngüsüne dahildir. Bu iyi haber ama tek başına yeterli değil: yedekler genellikle belirli sayıda geriye gider ve "üç ay önce silinmiş bir mesaj" o pencerenin dışında kalır. Avantajı, verinin tamamının standart Maildir/mbox biçiminde elinizde olması ve istediğiniz zaman kendi yedeğinizi alabilmenizdir:

# Tek bir kutunun tam kopyası (Maildir yapısı korunur)
rsync -avz ~/mail/sirketiniz.com/ad.soyad/ /yedek/ad.soyad-$(date +%F)/

# IMAP üzerinden sunucudan bağımsız kopya
imapsync --host1 mail.sirketiniz.com --user1 [email protected] \
         --host2 yeni.sunucu.com --user2 [email protected] \
         --ssl1 --ssl2

Bulut serviste veri sizin diskinizde değildir; dolayısıyla "kendi yedeğim" ancak bir dışa aktarma aracıyla veya üçüncü taraf yedekleme çözümüyle mümkündür. Servisin çöp kutusu ve saklama politikası bir yedek değildir — hesabı yanlışlıkla silerseniz belirli bir süre sonra veri gerçekten gider. Kurumsal denetim, dava veya vergi yükümlülüğü nedeniyle uzun süreli saklama gerekiyorsa arşiv özelliğini ayrıca yapılandırmanız gerekir.

Resmî yazışmaların hukuki geçerliliği söz konusuysa e-posta iki modelde de tek başına yeterli değildir; bunun ayrı bir çözümü var ve kep adresi nedir yazısında ne zaman zorunlu olduğunu anlattım.

Mobil ve Çoklu Cihaz Senkronizasyonu#

Çoklu cihazda yaşanan sorunların neredeyse tamamı protokol seçiminden çıkar, servisten değil. Hosting e-postası IMAP ve POP3 sunar; POP3 mesajı indirip sunucudan silme eğilimindedir ve ikinci bir cihazda "maillerim yok" şikâyetinin ana kaynağıdır. Kurumsal kullanımda tek doğru seçim IMAP'tir. İkisinin davranış farkı için imap pop3 farkı yazısına bakın.

Bağlantı ayarları da kararı etkiler. Hosting tarafında istemciye elle port ve şifreleme girmek gerekir:

Port ve şifreleme eşleşmesini yanlış kurmak, Outlook'ta en sık görülen "sunucuya bağlanılamadı" hatasının kaynağıdır; hangi portun hangi şifrelemeyle çalıştığını mail portları yazısında ayrıntılandırdım.

Bulut servislerde bağlantı genelde tek tıkla kurulur ve takvim/kişi senkronizasyonu e-postayla aynı hesaptan gelir. Hosting tarafında takvim ve kişi paylaşımı CalDAV/CardDAV ile mümkündür ama kurulumu kullanıcıya elle anlatmanız gerekir. Ekip on kişiyi geçtiğinde bu "elle anlatma" işi görünmez bir maliyet kalemine dönüşür — çünkü her yeni işe alımda tekrarlanır.

Kullanıcı Sayısı Arttıkça Maliyet Eğrisi#

Maliyet eğrisi iki modelde temelden farklı biçimlidir: hosting e-postasının maliyeti basamaklıdır, bulut servisin maliyeti doğrusaldır.

Hosting e-postasında ilk kullanıcı ile onuncu kullanıcı arasında ek maliyet yoktur; paket zaten alınmıştır. Maliyet ancak disk veya kaynak sınırına dayandığınızda, yani bir üst pakete geçtiğinizde artar — o da bir basamaktır, sonra yine düz gider. Bulut serviste ise her yeni kullanıcı doğrudan aylık faturaya eklenir; 40. kullanıcı ile 4. kullanıcı aynı birim bedeli getirir.

Eğrileri kabaca şöyle okuyun:

Ama tabloyu tek başına okumayın; eğriye şu üç görünmez kalemi eklemeden karar yanlış çıkar:

1. Yönetim zamanı. Hosting tarafında kotayı, spam filtresini, kara liste sorgusunu ve istemci ayarlarını birinin yapması gerekir. Bu, faturada görünmeyen ama gerçek bir maliyettir.
2. Kesinti bedeli. Mailin durduğu bir gün, kaç kişinin kaç saatini durdurur? On beş kişilik bir ekipte bu, aylık farkın çok üzerinde olabilir.
3. Taşıma maliyeti. Yanlış modelde ilerleyip iki yıl sonra taşımak zorunda kalmak, iki yılın farkından pahalıya gelebilir. Taşımayı gözünüzde büyütmeyin ama planlayın: e-postaları yeni sunucuya taşıma yazısı süreci adım adım anlatıyor.

Yönetim, Güvenlik ve Denetim Farkları#

Yönetim tarafında hosting e-postası size daha fazla kontrol, bulut servis daha fazla hazır politika verir.

Hosting tarafında elinizde olan güçlü araçlar: sunucu düzeyinde filtre kuralları, catch-all adres, otomatik yanıtlayıcı, iletme kuralları ve en önemlisi günlükler. Bir mesajın neden reddedildiğini görmek istediğinizde cevap tek komut uzaktadır:

# Exim tabanlı sunucularda bir alıcıya giden son kayıtlar
grep "[email protected]" /var/log/exim_mainlog | tail -30

# Postfix tabanlı sunucularda
grep "[email protected]" /var/log/mail.log | tail -30

Bu görünürlük, bir müşteri "mailinizi almadım" dediğinde tartışmayı bitirir. Bulut serviste karşılığı yönetim panelindeki mesaj izleme ekranıdır; yeterlidir ama sunucu günlüğü kadar ayrıntılı değildir.

Güvenlik tarafında iki modelin zayıf noktaları farklıdır. Hosting e-postasında en yaygın olay, zayıf şifreli bir kutunun ele geçirilip sunucudan spam gönderilmesidir; sonuç kara listeye düşen bir IP ve kesilen tüm mail trafiğidir. Buna karşı iki basit önlem büyük fark yaratır: her kutuda uzun ve benzersiz parola, mümkünse webmail girişinde IP kısıtı. Bulut tarafında en yaygın olay kimlik avıyla ele geçirilen hesaptır; buna karşı iki adımlı doğrulamayı zorunlu kılmak tek başına riskin çoğunu kapatır.

Denetim ihtiyacı olan şirketlerde şu soruyu erken sorun: "Bir çalışanın gönderdiği mesajı, o çalışan silse bile bulabilmem gerekiyor mu?" Cevap evetse, ikisinde de varsayılan yapılandırma yetmez; hosting tarafında sunucu düzeyinde arşiv kopyası, bulut tarafında arşiv/saklama politikası ayrıca kurulmalıdır.

Pazarlama ve Toplu Gönderim: İkisi de Bunun İçin Değil#

Her iki model de bülten ve kampanya gönderimi için tasarlanmamıştır ve bu, en pahalı hataların çıktığı yerdir. Paylaşımlı hosting üzerinden binlerce alıcıya mail atmak saatlik gönderim limitine takılır; takılmadığı durumda ise IP itibarını bozarak günlük yazışmalarınızı da spam klasörüne düşürür. Bulut serviste ise hesap başına günlük gönderim limiti aşıldığında hesap geçici olarak kısıtlanır.

Doğrusu, işlem maillerini (sipariş onayı, şifre sıfırlama) ve pazarlama maillerini birbirinden ve günlük yazışmadan ayırmaktır. Üç kanal, üç ayrı itibar havuzu demektir; birinin bozulması diğerini etkilemez. Toplu gönderim tarafında liste hijyeni, ısınma (warm-up) ve geri dönen adreslerin temizlenmesi zorunludur; süreci toplu mail nasıl gönderilir yazısında ayrıntılandırdım. Kendi gönderim yığınını sıfırdan kurmak isteyenler için Postfix, Dovecot ve spam filtresinin bir arada geldiği hazır dağıtımlar da bir seçenektir.

Hangisini Seçmeli: Senaryolara Göre Karar#

Aşağıdaki senaryolar, danışılan durumların büyük çoğunluğunu kapsıyor.

1. 1-5 kişilik ekip, günlük yazışma ağırlıklı. Hosting'e dahil e-posta yeterlidir. Kotaları kutu bazında sınırlayın, IMAP kullanın, SPF/DKIM/DMARC'ı doğru kurun. Ek servise gerek yok.
2. 6-15 kişi, ekli dosya trafiği yoğun. Sınırda bir durum. Disk büyümesini bir çeyrek boyunca ölçün; mail alanı paketin yarısını geçiyorsa e-postayı siteden ayırın.
3. Ortak takvim, ortak sürücü ve döküman iş birliği gerekiyor. Bulut servis açık ara önde. Konu artık e-posta değil, iş birliği paketidir; hosting e-postası bu ihtiyacı karşılamak için tasarlanmadı.
4. Site ve mail aynı sunucuda ve site yoğun. MX'i dışarı almak tek başına iyi bir fikirdir: sitedeki bir yük artışı maili etkilemez.
5. Gönderim hacmi yüksek, bildirim ve kampanya maili çok. Karar e-posta kutusu değil, gönderim altyapısıdır. Ayrı bir SMTP çözümü kurun; günlük yazışma nerede olursa olsun.
6. Sektörel saklama/denetim yükümlülüğü var. Hangi modeli seçerseniz seçin arşivi ayrıca kurgulayın ve "yedek arşiv yerine geçmez" cümlesini not edin.

Karma Model: Kimsenin Anlatmadığı Orta Yol#

Karma model, günlük yazışmayı bir tarafta, otomatik ve toplu gönderimi başka tarafta tutmaktır ve çoğu KOBİ için en verimli kurgudur. Örneğin kutular hosting'de kalır, siteden çıkan işlem mailleri ayrı bir SMTP sunucusundan gönderilir. Ya da tam tersi: MX bulut serviste, gönderim ise kendi SMTP'nizde.

Kurulumda dikkat edilecekler:

; MX bulut serviste, gönderim kendi sunucunuzda ise
; SPF her iki gönderim yolunu da kapsamalı
sirketiniz.com.  IN TXT "v=spf1 include:_spf.saglayici.com ip4:203.0.113.10 -all"

Sık yapılan hata, gönderim yolunu ekleyip SPF'i güncellememektir; sonuç, siteden çıkan maillerin sessizce spam'e düşmesidir. İkinci hata, MX'i dışarı verdikten sonra sunucuda yerel teslimatı kapatmamaktır — sunucu sirketiniz.com adresini hâlâ kendi kutusu sanır ve dışarı göndermez. cPanel tarafında bunun ayarı e-posta yönlendirici (routing) seçeneğidir ve Remote Mail Exchanger olarak işaretlenmelidir. Bu tek kutucuk, MX değişikliğinden sonra "kendi çalışanlarıma mail atamıyorum" şikâyetinin neredeyse tek sebebidir.

Sıkça Sorulan Sorular#

Hosting paketine dahil e-posta kurumsal kullanım için yeterli mi#

Küçük ekiplerde ve günlük yazışma ağırlıklı kullanımda fazlasıyla yeterlidir. Kutu sayısı, kota ve IMAP desteği modern paketlerde standarttır; SPF, DKIM ve DMARC doğru kurulduğunda teslim edilebilirlik de sorun olmaz. Yetersiz kaldığı yer ortak takvim, ortak sürücü ve gelişmiş denetim gibi iş birliği özellikleridir. Ayrıca mail kutuları site diskini paylaştığı için disk büyümesini düzenli izlemeniz gerekir.

Google Workspace'e geçersem maillerim spama düşmez mi#

Düşebilir, çünkü spam kararını veren şey servis değil kimlik doğrulama kayıtlarınız ve gönderim davranışınızdır. Bulut servis size yüksek itibarlı bir gönderim havuzu verir ama SPF ve DMARC kaydını yine siz yazarsınız; yanlış veya eksik yazılmışsa sonuç değişmez. Ayrıca sitenizden çıkan otomatik mailler MX değişikliğinden etkilenmez, onlar ayrı bir yoldan gider ve ayrıca imzalanmaları gerekir.

MX kaydını değiştirince eski maillerim silinir mi#

Silinmez, ama yeni gelen mailler artık eski sunucuya düşmez. Eski kutulardaki mesajlar olduğu yerde durur; onları yeni ortama taşımak ayrı bir iştir ve genellikle IMAP üzerinden kopyalama araçlarıyla yapılır. Bu yüzden geçiş sırasında eski hesabı hemen kapatmayın, en az birkaç hafta açık tutun. Taşıma bittikten sonra eski kutuların bir kopyasını dosya olarak arşivlemek en güvenli yoldur.

Kaç kullanıcıdan sonra bulut e-posta servisi mantıklı olur#

Sayı tek başına belirleyici değildir; belirleyici olan ihtiyacın türüdür. Sadece e-posta gerekiyorsa hosting çözümü yüksek kullanıcı sayılarında bile ekonomik kalır, çünkü maliyeti kullanıcı başına artmaz. Ortak takvim, döküman iş birliği ve merkezi cihaz yönetimi gerekiyorsa on kişilik bir ekipte bile bulut servis kendini haklı çıkarır. Kararı "kaç kişiyiz" ile değil, "e-postanın dışında neye ihtiyacımız var" ile verin.

E-postayı siteden ayırmak neden tavsiye ediliyor#

Çünkü arıza yüzeyini böler. Site ve mail aynı sunucuda çalışırken sitedeki bir yük artışı, saldırı ya da disk dolması doğrudan mail trafiğini de durdurur. MX'i başka bir yere aldığınızda site tamamen kapansa bile yazışma sürer, ki çoğu şirkette e-postanın durması siteden daha maliyetlidir. Ayrıca mail kutularının disk büyümesi artık web hesabınızın alanını yemez.

Ayrılan bir çalışanın e-posta hesabını ne yapmalıyım#

Önce şifresini değiştirip erişimi kesin, sonra gelen mesajları bir yöneticiye iletmeye alın ve kutunun tam bir kopyasını arşivleyin. Hesabı hemen silmek en sık yapılan hatadır; müşteri yazışmalarının tamamı bir anda kaybolur ve geri dönüş yedeğe kalır. Arşivi aldıktan sonra adresi bir süre yönlendirmede tutmak, iş sürekliliği açısından en güvenli yoldur.

Kendi mail sunucumu kurmak mantıklı mı#

Teknik ekibiniz ve kalıcı bir IP itibarınız varsa mantıklıdır, aksi halde en zahmetli yoldur. Kendi sunucunuzda tam kontrol, sınırsız kutu ve ayrıntılı günlük erişimi olur; buna karşılık spam filtresi, kara liste takibi, yedekleme ve güvenlik yamaları tamamen sizin sorumluluğunuza geçer. Özellikle yeni bir IP'nin itibar kazanması zaman alır ve bu süreçte teslim edilebilirlik dalgalanır. Sadece gönderim için ayrılmış bir sunucu kurmak, tüm mail yükünü taşımaktan çok daha yönetilebilir bir başlangıçtır.

Kapanış#

Kurumsal e-posta mı Google Workspace mi sorusunun cevabı ekip büyüklüğünde değil, ihtiyacın cinsinde saklı. Sadece @sirketiniz.com uzantılı düzgün çalışan kutular istiyorsanız hosting'e dahil e-posta doğru kurulduğunda uzun süre yeter ve maliyeti kullanıcı sayısıyla büyümez; ortak takvim, döküman iş birliği ve merkezi yönetim gerekiyorsa bulut servis kendini erken haklı çıkarır. Her iki modelde de teslim edilebilirliğin sorumluluğu büyük ölçüde sizde kalır: tek bir SPF kaydı, doğru seçiciyle yayımlanmış DKIM ve izleme modunda başlatılmış bir DMARC politikası olmadan hiçbir servis sizi spam klasöründen kurtarmaz. Arşiv ile yedeği ayırmayı ve toplu gönderimi günlük yazışmadan koparmayı da bu kararın parçası yapın.

Kurulum tarafında yol almak isterseniz: kutularınızı ayrı bir yerde toplamak ve MX'inizi oradan yürütmek için e-posta çözümleri sayfasındaki paketlere, kutularla birlikte kurumsal bir site altyapısı arıyorsanız kurumsal hosting tarafına bakabilirsiniz. Bildirim ve kampanya maillerini günlük yazışmadan ayırmak istiyorsanız kurulu bir gönderim yığınıyla gelen SMTP sunucu doğru adres; kutuların bağımsız bir kopyasını düzenli olarak dışarı almak içinse yedekleme hizmetini devreye alabilirsiniz.