E-posta & SMTP Sunucu

    Exchange mi Kendi Mail Sunucum mu

    Barındırılan Exchange ile kendi kurduğun mail sunucusu arasındaki gerçek maliyet ve sorumluluk farkı.

    11 dk okuma Güncellendi: 25 Ağustos 2026

    Şirket büyüdükçe bir gün mutlaka şu soru masaya gelir: kurumsal e-postayı Microsoft'un Exchange altyapısında mı tutalım, yoksa kendi sunucumuzu mu kuralım? Soru genellikle "hangisi daha ucuz" diye sorulur ama karşılaştırmanın gerçek ekseni fiyat değil, sorumluluğun nerede durduğudur. Kullanıcı başına aylık ücret ödediğinde, posta kutularının ayakta kalmasından, yedeklenmesinden ve Gmail'in seni engellememesinden başkası sorumludur. Kendi mail sunucunu kurduğunda ise bu üçünün tamamı senin masandadır ve bunun bir maliyeti vardır: sadece para değil, dikkat maliyeti.

    Bu yazıda Exchange tabanlı barındırılan bir posta hizmetiyle kendi kurduğun Postfix/Dovecot ya da Zimbra tabanlı bir mail sunucusunu altı somut başlıkta karşılaştıracağım: gerçek toplam maliyet, teslimat ve gönderici itibarı, bakım yükü, veri egemenliği ve KVKK, felaket kurtarma süresi ve istemci uyumluluğu. Sonunda da "şu durumdaysan şunu seç" diyen net bir karar tablosu bırakacağım. Amacım seni bir tarafa itmek değil; iki tarafın da gizli maliyetlerini görünür kılmak.

    Karşılaştırmanın Gerçek Ekseni: Neyi Devrediyorsun#

    Bir e-posta sistemi aslında beş ayrı işin toplamıdır: mesajın kabulü ve teslimi (MTA), depolama ve erişim (IMAP/POP3), spam ve virüs filtreleme, kimlik doğrulama ve dizin yönetimi, son olarak yedekleme ve kurtarma. Barındırılan bir Exchange hizmeti bu beşinin tamamını devralır ve sana yalnızca kullanıcı yönetimini bırakır. Kendi sunucunda ise beşini de sen kurar, sen izler, sen tamir edersin.

    Bu devretme kararının bedeli açıktır ve kullanıcı başına aylık ücret olarak faturana yansır. Ama devretmemenin bedeli gizlidir: bir cumartesi sabahı disk dolduğu için maillerin kuyrukta beklemesi, IP'nin bir spam listesine düşmesi, güncelleme sonrası TLS'in bozulması. Bu olayların hiçbiri "belki olur" kategorisinde değildir; yeterince uzun süre mail sunucusu işletirsen üçünü de yaşarsın. Karar verirken sorman gereken asıl soru şudur: bu olaylar olduğunda müdahale edecek bir insan ve o insanın ayıracak zamanı var mı?

    Sorumluluk alanıBarındırılan ExchangeKendi mail sunucun
    Sunucu donanımı ve işletim sistemiSağlayıcıSen
    Yazılım güncellemeleri ve güvenlik yamalarıSağlayıcıSen
    Spam/virüs filtrelemeSağlayıcı (dahil)Sen (Rspamd/SpamAssassin)
    IP itibarı ve teslimatSağlayıcıSen
    Yedekleme ve geri dönüşPlana göre değişirSen
    Kullanıcı ve kota yönetimiSen (panel)Sen (komut satırı)
    Veri nerede duruyor bilgisiSağlayıcının bölgesiSenin seçtiğin veri merkezi

    Barındırılan Exchange Ne Sunar, Neyi Sunmaz#

    Exchange Online tarafının en güçlü yanı istemci uyumluluğudur. Outlook ile arasında tam entegre bir protokol vardır; takvim davetleri, serbest/meşgul bilgisi, paylaşılan posta kutuları, kaynak (toplantı odası) rezervasyonu ve mobil senkronizasyon kutudan çıkar gibi çalışır. Kullanıcıların çoğunun Outlook'a alışkın olduğu bir kurumda bu, eğitim maliyetini neredeyse sıfırlar. Plana göre 50 GB'tan başlayan posta kutusu boyutu, arşivleme ve saklama politikaları da idari yükü azaltır.

    Sunmadığı şeyleri de net konuşalım. Birincisi, yedekleme değildir. Çöp kutusu ve saklama politikaları geri dönüş imkânı verir ama bunlar bir yedekleme sistemi değildir; bir hesabın yanlışlıkla silinmesi ya da fidye yazılımıyla şifrelenmiş bir istemciden gelen senkronizasyon, saklama süresi dolduktan sonra veriyi geri getirmez. Bu yüzden büyük kurumların çoğu Exchange üzerine ayrıca üçüncü taraf yedekleme satın alır ve bu, karşılaştırmaya sonradan eklenen bir kalemdir. İkincisi, gönderim limitleri vardır. Alıcı sayısı ve günlük gönderim üst sınırları toplu bilgilendirme mailleri için dardır; pazarlama e-postası göndermeye kalktığında hesabın kısıtlanır. Toplu gönderim yapıyorsan yine ayrı bir altyapıya, yani SMTP relay ya da özel bir gönderim servisine ihtiyacın olur.

    Şirket içine kurulan Exchange Server sürümü ise ayrı bir hikâyedir ve bugün küçük/orta ölçekli çoğu şirket için savunulması zor bir seçenektir: Windows Server lisansı, Exchange lisansı, kullanıcı erişim lisansları ve bunların üstüne ciddi bir uzmanlık gerekir. Microsoft'un şirket içi Exchange lisanslama modeli de abonelik yönünde değişti; bu yola girmeden önce güncel lisans şartlarını mutlaka teyit et.

    Kendi Mail Sunucunu Kurmak Gerçekte Ne Demek#

    Kendi sunucunu kurmak, "bir VDS al, Postfix kur, bitti" demek değildir. Çalışan bir üretim mail sunucusu en az şu bileşenleri gerektirir: MTA (Postfix), IMAP/POP3 sunucusu (Dovecot), spam filtresi (Rspamd), virüs tarayıcı, TLS sertifikası ve otomatik yenileme, DKIM imzalama, kimlik doğrulama katmanı, kota yönetimi, yedekleme ve izleme. Hepsini tek panelden yönetmek istiyorsan Zimbra kurulumu bu bileşenleri paketleyen bir üst katman sunar; hafif bir yığın istiyorsan Postfix + Dovecot ikilisiyle daha az kaynakla çalışırsın.

    Kurulumun teknik kısmı aslında en kolay kısmıdır. Zorluk, kurulumdan sonraki üç ayda ortaya çıkar. İşte gerçek bir üretim sunucusunda düzenli olarak yaptığın işler:

    # Kuyruk sağlığı — her sabah bakılacak ilk yer
    postqueue -p | tail -1
    
    # Reddedilen/geri dönen mailleri sınıflandır
    grep -c "status=bounced" /var/log/mail.log
    grep "status=deferred" /var/log/mail.log | tail -20
    
    # Disk doluluğu — mail sunucusunu öldüren bir numaralı sebep
    df -h /var/vmail
    
    # TLS sertifikasının kaç gün ömrü kaldı
    openssl x509 -enddate -noout -in /etc/letsencrypt/live/mail.firmaniz.com/cert.pem
    
    # IP'nin kara listede olup olmadığını kontrol et
    dig +short 56.34.12.185.zen.spamhaus.org
    

    Son satır özellikle önemlidir: kara liste sorgusu IP'nin ters çevrilmiş hâliyle yapılır. 185.12.34.56 adresini sorgulamak için 56.34.12.185.zen.spamhaus.org yazarsın. Bir cevap dönüyorsa IP listelenmiştir ve maillerin bir kısmı sessizce düşüyordur. Bu kontrolleri elle yapmak yerine bir izleme sistemine bağlamak, kendi sunucunu işletmenin temel şartıdır.

    Maliyet Hesabı: Kullanıcı Başı Ücret mi, Sunucu Artı Zaman mı#

    Maliyet karşılaştırması genelde yanlış yapılır çünkü yalnızca faturaya bakılır. Doğru hesap şudur: barındırılan hizmette maliyet kullanıcı sayısıyla doğrusal artar, kendi sunucunda ise sabit bir taban maliyeti vardır ve kullanıcı sayısı arttıkça kullanıcı başına düşen maliyet düşer. Kırılma noktası genellikle 15-25 kullanıcı civarındadır ama bu noktayı belirleyen asıl değişken kullanıcı sayısı değil, senin saatinin fiyatıdır.

    Şöyle düşün: kendi sunucunda ayda ortalama 3 saat bakım harcıyorsan ve bir sistem yöneticisinin saati şirkete belirli bir maliyet yaratıyorsa, bu emek kalemi çoğu zaman sunucu kirasından büyüktür. Karşılaştırmayı dürüst yapmak için tabloya şu kalemleri eklemelisin:

    KalemBarındırılan ExchangeKendi sunucun
    Aylık tabanKullanıcı × aylık ücretSunucu kirası (sabit)
    YedeklemeGenelde ek ücretYedek depolama + zaman
    Spam filtresiDahilDahil (kendi kurduğun)
    SSL sertifikasıDahilÜcretsiz (Let's Encrypt)
    Bakım emeğiYok denecek kadar azAyda 2-5 saat
    Kesinti riskinin bedeliSağlayıcının SLA'sıSenin müdahale hızın
    ÖlçeklenmeKullanıcı ekle, ücret artsınKaynak ekle, ücret aynı kalsın

    Kesinti maliyetini somutlaştırmak istersen uptime ve SLA hesaplayıcı aracıyla, kabul ettiğin erişilebilirlik oranının yılda kaç saat kesintiye denk geldiğini görebilirsin. %99,9 kulağa çok iyi gelir ama yılda yaklaşık 8,7 saat kesinti demektir; bu sürenin mail trafiğinin durduğu bir gün içine sıkışması ihtimalini de hesaba kat.

    Teslimat ve Gönderici İtibarı: Asıl Ayrım Burada#

    Kendi mail sunucunu kurmanın en çok hafife alınan tarafı teslimattır. Büyük sağlayıcıların IP'leri yıllardır ısınmış, itibarı oturmuş adreslerdir; senin yeni aldığın IP'nin ise hiçbir geçmişi yoktur ve alıcı taraf için "bilinmeyen" demek, "şüpheli" demeye yakındır. Bu yüzden ilk günlerde Gmail'e giden mailler Spam klasörüne düşebilir, Outlook tarafında ise doğrudan reddedilebilir. Bunun çözümü tek bir ayar değil, bir disiplindir:

    1. PTR (rDNS) kaydını IP sağlayıcından iste; eksikse birçok alıcı en baştan reddeder.
    2. SPF, DKIM ve DMARC kayıtlarının üçünü de kur ve gerçekten geçtiğini doğrula.
    3. IP'yi ısıt: ilk hafta düşük hacimle başla, kademeli artır.
    4. Geri dönen mailleri (bounce) izle; sert bounce oranını düşük tut.
    5. Gönderdiğin adres listesini temiz tut, satın alınmış listeyle asla başlama.

    Büyük sağlayıcıların gönderici kuralları da sıkılaşmaya devam ediyor; toplu gönderim yapan herkesten kimlik doğrulama ve kolay abonelikten çıkma bekleniyor. Bu kuralların ayrıntısı için Gmail ve Yahoo gönderici kuralları yazısı iyi bir başlangıç. Kurulumundan sonra maillerin gerçekten kimlik doğrulamasını geçip geçmediğini görmek için SMTP test aracı ile üretilen openssl ve swaks komutlarını kullanabilir, DMARC raporlarını okumayı öğrenerek hangi kaynakların senin adına mail gönderdiğini takip edebilirsin.

    Barındırılan tarafta bu işlerin çoğu senin görevin değildir; sadece DNS kayıtlarını eklersin ve sağlayıcı IP itibarını kendi yönetir. Teslimat konusunda deneyimin yoksa ve şirketin geliri gelen maillere bağlıysa, bu tek başına terazinin barındırılan tarafa yatmasına yeter.

    Veri Egemenliği, KVKK ve Felaket Kurtarma#

    Bazı kurumlar için karar teknik değil hukukidir. Kişisel veri içeren yazışmaların hangi ülkede, hangi hukuki rejim altında saklandığı; bir denetimde kimin hangi kayıtları sunabildiği; bir mahkeme talebinde verinin nasıl temin edileceği. Kendi sunucunda veri fiziksel olarak senin seçtiğin veri merkezindedir ve erişim kayıtları senin elindedir. Yurt içinde barındırma gerekliliği olan bir sektördeysen bu, kendi sunucun lehine güçlü bir argümandır.

    Felaket kurtarma tarafında ise iki senaryoyu ayırmak gerekir. Barındırılan hizmette hizmet kesintisi riski sağlayıcıdadır ve senin yapabileceğin bir şey yoktur; beklersin. Buna karşılık veri kaybı riski büyük ölçüde sende kalır, çünkü yanlışlıkla silinen ya da şifrelenen içerik saklama süreleriyle sınırlıdır. Kendi sunucunda ise her iki risk de sende olduğu için ikisini de sen planlarsın: hangi sıklıkla yedek alınacağı, yedeğin nerede duracağı ve geri dönüşün ne kadar süreceği. Bu planın nasıl kurulacağını mail sunucusu yedekleme stratejisi yazısında ayrıntılı anlattım; oradaki en önemli cümleyi buraya da taşıyayım: denenmemiş yedek, yedek değildir.

    Hangi Senaryoda Hangisi#

    Yıllardır aynı sorulara verdiğim cevapları bir tabloya sıkıştırayım. Kendini hangi satırda görüyorsan, o satırın önerisi senin için doğru başlangıçtır.

    DurumunÖneriNeden
    1-10 kullanıcı, teknik ekip yokBarındırılan posta kutusuBakım yükü sıfıra yakın, maliyet düşük
    Outlook takvim/toplantı odası kritikExchange tarafıİstemci entegrasyonu rakipsiz
    25+ kullanıcı, sistem yöneticisi varKendi sunucunKullanıcı başı maliyet çöker
    Yurt içi veri saklama zorunluluğuKendi sunucunVeri merkezini sen seçersin
    Günde binlerce işlemsel mailAyrı SMTP altyapısıPosta kutusu hizmetleri limitler
    Mail geliri doğrudan etkiliyorBarındırılan + izlemeTeslimat riskini devret
    Karma: kutular hazır, gönderim kendindeHibritHer işi doğru araca ver

    Son satırdaki hibrit yaklaşım, pratikte en sık önerdiğim modeldir: kullanıcıların günlük posta kutuları barındırılan bir hizmette dursun, uygulamaların gönderdiği şifre sıfırlama, fatura ve sipariş mailleri ise ayrı bir gönderim altyapısından çıksın. Böylece hem kullanıcı deneyiminden ödün vermezsin hem de uygulama trafiği kimsenin posta kutusu limitine takılmaz. Bu ayrımın mantığını işlemsel e-posta nedir yazısında bulabilirsin.

    Sıkça Sorulan Sorular#

    Kendi mail sunucumu kurmak ucuz mu#

    Kâğıt üzerinde evet, pratikte duruma bağlı. Sunucu kirası sabittir ve kullanıcı sayısı arttıkça kullanıcı başına düşen maliyet hızla düşer. Ancak hesaba bakım emeğini, yedek depolamayı ve bir kesinti anında kaybedeceğin iş saatlerini de katman gerekir. 10 kullanıcının altında kendi sunucun neredeyse hiçbir zaman ucuza gelmez; 25 kullanıcının üstünde ve elinde bakım yapacak biri varsa fark açılmaya başlar.

    Kendi sunucumdan gönderdiğim mailler neden Gmail'de spam'e düşüyor#

    En yaygın üç sebep şunlardır: PTR (rDNS) kaydının eksik olması, SPF/DKIM/DMARC üçlüsünden birinin doğru kurulmamış olması ve IP'nin yeni olup hiçbir gönderim geçmişi bulunmaması. Üçü de düzeltilebilir ama sırayla ilerlemen gerekir: önce PTR, sonra kimlik doğrulama kayıtları, sonra düşük hacimle başlayan bir IP ısıtma dönemi. Kara liste kontrolünü de düzenli yapmalısın.

    Exchange yerine ne kullanabilirim#

    Takvim ve grup çalışması özellikleri senin için önemliyse Zimbra en yakın işlevsel alternatiftir; kurumsal dizin, paylaşılan takvim ve webmail'i tek panelde toplar. Sadece posta kutusu yeterliyse Postfix ve Dovecot ikilisi çok daha az kaynak tüketir. Hiç sunucu yönetmek istemiyorsan, IMAP tabanlı barındırılan bir kurumsal posta kutusu hizmeti çoğu senaryoda en pratik çözümdür.

    Kendi mail sunucumda kaç kullanıcı barındırabilirim#

    Kullanıcı sayısından çok posta kutusu boyutu ve eşzamanlı IMAP bağlantısı belirleyicidir. 8 GB RAM ve NVMe diskli tipik bir sunucu, normal yoğunlukta çalışan 50-100 kullanıcıyı rahatça taşır. Sınırı zorlayan şey genellikle CPU değil, disk giriş-çıkışı ve depolama alanıdır; bu yüzden büyümeyi diskten planlamak daha doğrudur.

    Geçiş yaparken maillerim kaybolur mu#

    Doğru yapıldığında hayır. IMAP tabanlı bir geçişte mevcut posta kutuları yeni sunucuya kopyalanır, DNS'teki MX kaydı ancak kopyalama bittikten sonra değiştirilir ve eski sunucu birkaç gün daha ayakta bırakılır. Bu üç adımın sırası kritiktir; MX'i erken değiştirirsen bir kısım mail eski, bir kısmı yeni sunucuya düşer. Geçiş öncesi mutlaka tam bir yedek al.

    Barındırılan hizmette yedekleme var mı#

    Çoğu barındırılan hizmet saklama ve kurtarma politikaları sunar ama bunlar klasik anlamda bir yedekleme sistemi değildir. Yanlışlıkla silinen bir posta kutusu ya da bir fidye yazılımı sonrası senkronize olan bozuk içerik, saklama süresi dolduktan sonra geri getirilemez. Bu yüzden kurumsal kullanımda çoğu şirket, barındırılan hizmetin üstüne ayrıca bağımsız bir yedekleme çözümü koyar.

    Kapanış#

    Bu kararı doğru vermenin yolu, iki tarafın da faturasına değil sorumluluk dağılımına bakmaktan geçiyor. Aklında kalması gereken dört şey var: küçük ekipte barındırılan hizmet neredeyse her zaman kazanır, kırılma noktasını kullanıcı sayısı değil senin bakıma ayırabildiğin zaman belirler, teslimat kendi sunucunda ayrı bir uzmanlık alanıdır ve hangi yolu seçersen seç yedeklemeyi kendi başına planlaman gerekir. Hibrit model —posta kutuları hazır bir serviste, uygulama gönderimi ayrı bir altyapıda— çoğu şirket için en dengeli çözümdür.

    Kendi mail sunucunu kurmaya karar verdiysen NVMe diskli VDS paketlerimiz Postfix/Dovecot ya da Zimbra yığını için uygun bir taban sunar, kurulum ve bakım yükünü üstlenmek istemezsen sunucu yönetimi hizmetimiz devreye girer. Yalnızca gönderim tarafını ayırmak istiyorsan hazır kurulu SMTP sunucu paketimiz uygulama maillerini posta kutularından bağımsız taşır; kullanıcı kutularını hiç yönetmek istemiyorsan e-posta çözümlerimiz aynı alan adı altında hazır olarak çalışır.

    ExchangeMail SunucusuKarşılaştırma

    Uygulamaya geçmeye hazır mısınız?

    NVMe SSD, ücretsiz SSL ve %99.9 uptime garantisiyle Clou.TR hosting ve sunucu çözümleriyle projenizi hayata geçirin.