Kısa cevap: Üç seçenek var: hosting paketinize dahil e-posta, Google Workspace ve Microsoft 365. Hosting maili küçük ve posta hacmi düşük işletmeler için çalışır ama teslim güvenilirliği sizin elinizde değildir; posta, sunucudaki diğer sitelerle aynı adresten çıkar. Microsoft 365 masaüstü Office programlarıyla ve Outlook alışkanlığıyla çalışan ekiplerde daha az direnç üretir; Google Workspace tarayıcıda çalışan ve ortak doküman üzerinden ilerleyen ekiplerde. Kararı fiyatla değil şu dört soruyla verin: kaç kutu, kaç yıl arşiv, paylaşılan kutu gerekiyor mu, ayrılan çalışanın verisi nasıl devredilecek.
Üç seçenek ve gerçek maliyet kalemleri
Bu soru genellikle abonelik bedeli sorusu olarak sorulur, oysa kurumsal e-postanın maliyeti üç yerde birikir ve ikisi fatura üzerinde görünmez. Birincisi doğrudan bedel. İkincisi yönetim yükü: kutu açmak, parola sıfırlamak, yeni cihaz bağlamak, dolan kutuyu boşaltmak. Üçüncüsü ve en pahalısı, teslim edilemeyen e-postanın bedelidir; müşterinize gönderdiğiniz teklifin spam klasörüne düşmesi hiçbir yerde kalem olarak görünmez ama en çok tutan maliyettir.
Bu yazıda fiyat vermiyoruz; sağlayıcıların planları ve kampanyaları değişiyor, güncel değeri yalnızca sağlayıcının kendi sayfasından okumak doğru olur. Onun yerine kararı verdirecek kriterleri sıralıyoruz. Seçim yapıldıktan sonra kurulum tarafı için kurumsal e-posta kurulumu yazısı port ve MX ayarlarını anlatıyor.
Hosting mailinin gerçek sorunu
Hosting paketine dahil e-posta “ücretsiz” göründüğü için uzun yıllar sürüklenir. Teknik olarak çalışır: kutuyu açarsınız, IMAP ile bağlanırsınız, posta gelir. Sorun teslim tarafındadır. Paylaşımlı bir hosting sunucusunda posta, o sunucudaki diğer sitelerle aynı adresten çıkar. Aynı sunucuda duran başka bir sitenin bülten yazılımı şikâyet toplarsa, o adresin itibarı düşer ve sizin hiçbir kusurunuz olmadan sizin postanız da spam klasörüne düşmeye başlar. Bunu düzeltmek sizin elinizde değildir; komşunuzun davranışına bağlıdır.
İkinci sorun kotadır. Hosting mailinde kutu genellikle paketin disk alanını paylaşır. Alan dolduğunda yalnızca posta değil site de etkilenebilir ve dolan kutuya gelen iletiler reddedilmeye başlar. Üçüncü sorun arama ve arşivdir: yıllara yayılmış bir kutuda bir ekin hangi yazışmada geldiğini bulmak, ayrı bir posta servisinin arama altyapısı olmadan zahmetli bir iştir. Dördüncüsü devirdir; bir çalışan ayrıldığında kutusunun yöneticiye devredilmesi elle yapılır ve çoğu zaman yapılmaz, kutu silinir.
Bunların hiçbiri hosting mailinin her durumda yanlış olduğu anlamına gelmez. İki üç kutusu olan, günde az sayıda e-posta gönderen ve arşiv ihtiyacı sınırlı bir işletme için makul bir başlangıçtır. Ama teklif gönderiyorsanız, fatura bildirimi atıyorsanız ya da müşteri yazışması işinizin merkezindeyse, teslim güvenilirliği bir lüks değil zorunluluktur.
Karar kriterleri yan yana
| Kriter | Hosting maili | Google Workspace | Microsoft 365 |
|---|---|---|---|
| Teslim güvenilirliği | Posta diğer sitelerle aynı adresten çıkar; komşunun itibarı sizi etkiler | Sağlayıcının kendi posta altyapısı | Sağlayıcının kendi posta altyapısı |
| Kota ve arşiv | Paket diskiyle paylaşılır; dolunca gelen posta reddedilir | Kutu başına plana bağlı kota | Kutu başına plana bağlı kota |
| Ortak takvim ve dosya | Genellikle yok | Takvim ve ortak sürücü dahil | Takvim ve ortak depolama dahil |
| Mobil ve cihaz politikası | Merkezi yönetim yok | Yönetim konsolundan | Yönetim merkezinden |
| Ayrılan çalışanın verisi | Kutu elle yedeklenir; genellikle yedeklenmeden silinir | Kutu devri ve arşivleme konsoldan yapılır | Kutu paylaşılan kutuya çevrilip devredilebilir |
| Günlük yönetim yükü | Az görünür; sorun çıktığında yük hosting desteğine kalır | Tek konsolda merkezi | Tek merkezde merkezi |
| Çıkış kolaylığı | Posta IMAP ile taşınır; başka veri yok | Posta IMAP ile taşınır; doküman ve takvim ayrı dışa aktarılır | Posta IMAP ile taşınır; dosya ve takvim ayrı dışa aktarılır |
Tablodaki son satır çoğu kararın atladığı kalemdir. Posta kutusunun kendisi her üç seçenekten de IMAP ile taşınabilir, yani e-posta tarafında kilitlenme düşüktür. Kilitlenme dokümanlarda, ortak sürücüde ve takvimde başlar; o veriler IMAP ile taşınmaz ve ayrı bir dışa aktarma gerektirir. Sağlayıcı değiştirme olasılığınız varsa ortak dosyaları nerede tuttuğunuzu baştan düşünmek gerekir; aynı mantığı işletme yazılımını buluta taşımak yazısında da ele alıyoruz.
Hangi ekip hangisinde daha az direnç gösterir
İki büyük sağlayıcı arasındaki fark, özellik listesinden çok ekibin mevcut alışkanlığında ortaya çıkar. Microsoft 365, masaüstü Office programlarıyla çalışan ve Outlook alışkanlığı olan ekiplerde daha az direnç üretir; Excel dosyasını masaüstü uygulamada açmaya alışmış bir muhasebe ekibini tarayıcıya taşımak eğitim maliyeti doğurur. Google Workspace ise işi tarayıcıda yürüten ve ortak doküman üzerinde eşzamanlı ilerleyen ekiplerde daha doğal oturur; aynı dosyayı aynı anda iki kişinin düzenlediği bir ekip için bu akış daha hızlıdır.
Bu yüzden kararı “hangisi daha iyi” sorusuyla değil, “ekibim bugün hangi programda çalışıyor” sorusuyla vermek daha az sürtünme üretir. Her iki sağlayıcı da kurumsal e-posta, takvim, ortak depolama ve merkezi yönetim sunar; farkı yaratan, ekibin yeni araca ne kadar hızlı uyum sağladığıdır.
Adım adım: seçim akışı
Aşağıdaki altı soruyu sırayla cevaplarsanız karar kendiliğinden daralır. Soruları atlayıp doğrudan abonelik bedeline bakmak, kararı bir yıl sonra yeniden vermek anlamına gelir.
- Kaç kutu ve kaç yıl arşiv? Kutu sayısı bugünkü değil iki yıl sonraki sayı olmalı. Arşiv süresi de bir tercih değil, çoğu zaman sözleşme ve mevzuat gereğidir; geriye dönük yazışmaya ulaşmanız gerekiyorsa kota kararı buradan çıkar.
- Ekip hangi masaüstü programlarla çalışıyor? Outlook ve masaüstü Office ağırlıklı bir ekip için Microsoft tarafı, tarayıcıda çalışan bir ekip için Google tarafı daha az eğitim gerektirir. Bu soruyu yöneticiye değil, günlük işi yapan kişilere sorun.
- Paylaşılan kutu ve ortak takvim gerekiyor mu? Birden fazla kişinin aynı adresi görmesi gerekiyorsa (destek, satış, muhasebe) bu ihtiyaç hosting mailini büyük ölçüde devre dışı bırakır. Rol adreslerinin nasıl kurulacağını takma ad ve yönlendirme yazısı ayırıyor.
- Ayrılan çalışanın verisi nasıl devredilecek? Bir çalışan ayrıldığında kutusunun kime geçeceği, hangi yazışmaların korunacağı ve adresin ne kadar süre açık kalacağı baştan kararlaştırılmalı. Merkezi yönetimi olmayan bir sistemde bu işlem her seferinde elle ve eksik yapılır.
- Deneme sürümünde tek kutuyla ölçün. Seçtiğiniz sağlayıcıda tek bir test kutusu açın, kendi alan adınızın bir alt adıyla ya da ayrı bir test adresiyle gerçek iş akışını deneyin. Mobil bağlantı, takvim paylaşımı ve arama hızı ancak böyle anlaşılır.
- Taşıma planını yazın. Kutuları açma, eski postaları kopyalama, MX kaydını çevirme ve kimlik doğrulama kayıtlarını yazma adımlarını sıraya koyun. Planı yazmadan MX kaydına dokunmayın; sıranın nedenini eski e-postaları yeni sunucuya taşıma yazısı anlatıyor.
İki sağlayıcının istediği DNS kayıtları
Hangi sağlayıcıyı seçerseniz seçin, işin DNS tarafı aynı mantıkla yürür: gelen postayı MX kaydı yönlendirir, giden postanın kimliğini TXT kayıtları doğrular. İki sağlayıcının istediği kayıtlar aşağıda yan yana.
| Kayıt | Google Workspace | Microsoft 365 |
|---|---|---|
| Alan adı doğrulama | Sihirbazın verdiği TXT, host @ | Sihirbazın verdiği TXT, host @ |
| MX | Tek kayıt: smtp.google.com, öncelik 1 | (MX-token).mail.protection.outlook.com, TTL 3600, öncelik diğer kayıtlardan düşük bir sayı |
| SPF | v=spf1 include:_spf.google.com ~all | v=spf1 include:spf.protection.outlook.com -all |
| DKIM | Varsayılan seçici google, kayıt adı google._domainkey | Yönetim merkezinde üretilir; kayıt adı ve değeri oradan alınır |
| Autodiscover | Gerekmez | CNAME: autodiscover, hedef autodiscover.outlook.com |
| Teams için SRV | Gerekmez | sipfederationtls, TCP, öncelik 100, ağırlık 1, port 5061, hedef sipfed.online.lync.com |
Microsoft tarafındaki MX hedefi her alan adı için farklıdır: yönetim merkezindeki Domains bölümünün Fix issues ekranından alınır ve alan adının noktaları tireye dönüşür. Google tarafında 2023 ve sonrasında açılan hesaplar için tek bir MX kaydı yeterlidir; daha eski hesaplarda aspmx ile başlayan çoklu bir kayıt seti bulunabilir ve bu set hâlâ desteklenir, yani çalışan bir yapıyı yalnızca “eski görünüyor” diye değiştirmek gerekmez. Aşağıdaki kutuda alan adı ve anahtar değerleri YER TUTUCUDUR.
; Google Workspace @ 3600 MX 1 smtp.google.com. @ 3600 TXT "v=spf1 include:_spf.google.com ~all" google._domainkey 3600 TXT "v=DKIM1; k=rsa; p=(genel anahtar)" ; Microsoft 365 (MX-token yonetim merkezinden alinir) @ 3600 MX 1 (MX-token).mail.protection.outlook.com. @ 3600 TXT "v=spf1 include:spf.protection.outlook.com -all" autodiscover 3600 CNAME autodiscover.outlook.com. _sipfederationtls._tcp 3600 SRV 100 1 5061 sipfed.online.lync.com.
Hangi sağlayıcıyı seçtiyseniz, kayıtlar yazıldıktan sonra sıra kimlik doğrulamanın sağlamlaştırılmasına gelir. SPF değerleri yukarıda duruyor ama tek başlarına yeterli değil; DKIM imzalamanın açılması ve DMARC politikasının kademeli sıkılaştırılması için SPF, DKIM ve DMARC nasıl kurulur yazısına bakın.
Yaygın hatalar
- “Ücretsiz geliyor” diye hosting mailinde kalıp teslim sorununu yıllarca sürüklemek. Abonelik bedelinden kaçınırsınız ama gönderdiğiniz teklifin karşı tarafa ulaşmadığını hiç ölçmediğiniz için maliyeti göremezsiniz. Bu kalem faturada değil, kaybedilen işte görünür.
- İki sağlayıcıyı aynı anda MX kaydına yazmak. Geçiş sırasında “ikisi de çalışsın” diye eski ve yeni MX kayıtlarını birlikte bırakmak postayı iki sistem arasında böler. Bir ileti eskiye, sonraki yeniye düşer; kimse hangi iletinin nerede olduğunu bilemez.
- Google tarafında yeni tek MX kaydını eski
aspmxsetinin yanına eklemek. İki yapıdan birini seçmek gerekir; ikisini birlikte bırakmak gereksiz karmaşa ve beklenmedik teslim davranışı üretir. - Eski sağlayıcının SPF kaydını silmeyip ikinci bir SPF satırı eklemek. Bir alan adında yalnızca bir SPF kaydı olabilir. İki kayıt gören alıcı sunucular politikayı geçerli saymaz ve giden postanız doğrulamayı tamamen kaybeder.
- Seçimi yalnızca fiyatla yapıp arşiv ve devir maliyetini atlamak. İki yıl sonra kutular dolduğunda ya da bir çalışan ayrıldığında ortaya çıkan iş, ilk günkü fiyat farkını kolayca geçer. Kararı dört soruyla verin: kutu sayısı, arşiv süresi, paylaşılan kutu ihtiyacı, devir yöntemi.
- Taşıma öncesi eski postaları indirmemek. Yeni sağlayıcıya geçtiğinizde eski kutular kendiliğinden taşınmaz. MX kaydı çevrilmeden önce arşivin kopyalanması gerekir; aksi hâlde yıllık yazışma kapanacak bir hesabın içinde kalır.
Ne zaman uzmana bırakmalı
Sağlayıcı seçmek için danışmana ihtiyacınız yok; yukarıdaki altı soru çoğu işletme için kararı veriyor. Yardım gerektiren kısım geçişin kendisidir. Hâlihazırda çalışan bir posta sistemi, yıllık arşivi olan kutular, dışarıya yönlendirilmiş rol adresleri, kendi sunucusundan posta atan bir fatura yazılımı ve kimin ne zaman eklediği bilinmeyen eski DNS kayıtları varsa, geçiş bir planla yürütülmezse posta kaybı üretir.
Bu geçişleri web sitesi ve e-ticaret çalışmalarının bir parçası olarak yürütüyoruz: gönderen envanteri çıkarılır, kutular ve arşiv taşınır, MX ile kimlik doğrulama kayıtları birlikte çevrilir ve eski sistem bir süre açık tutulur. Mevcut yapınızı konuşmak için iletişim sayfasından yazabilirsiniz.
Devamını okumak için
Kararı verdiyseniz kurulum sırası için kurumsal e-posta kurulumu yazısına geçin. Arşivin taşınması için eski e-postaları yeni sunucuya taşıma, giden postanın doğrulanması için SPF, DKIM ve DMARC nasıl kurulur yazısı sırayı anlatıyor. Diğer işletme yazılımlarını da buluta almayı düşünüyorsanız işletme yazılımını buluta taşımak yazısı aynı kriterleri genişletiyor. Tüm başlıklar blog sayfamızda, çalışma alanlarımız ana sayfamızda.