Teknik·
27 Mayıs 2026
E-posta altyapısı durduğunda satış fırsatları kaçar, müşteri bildirimleri gecikerek şikâyete dönüşür ve itibar kaybı dakikalar içinde ölçülebilir bir zarara yol açar. Kurumsal e-postada SLA'yı doğru anlamak ve hedef olgunluk düzeyini belirlemek, bu riski yönetilebilir hâle getirir.
Hizmet Seviyesi Anlaşması (Service Level Agreement — SLA), iki taraf arasında tanımlanan performans taahhütleri bütünüdür. Geleneksel BT SLA'ları genellikle "uptime" yüzdesiyle ölçülse de e-posta altyapısı çok boyutlu bir hizmet olduğundan tek bir metrikle değerlendirilemez. IETF'in e-posta iletim protokolünü tanımlayan RFC 5321, bir mesajın alıcı Mail Transfer Agent'a (MTA) ulaşana dek hangi gecikme ve yeniden deneme davranışlarının bekleneceğini açıkça ortaya koyar. Bu çerçevede e-posta SLA'sı en az dört temel boyutu kapsamalıdır:
Yüzde ifadeleri soyut göründüğünde gerçek kesinti süreleri konuyu somutlaştırır. Aşağıdaki tablo, yaygın kullanılan dokuz hedeflerini yıllık ve aylık kesinti sürelerine çevirir:
| SLA Seviyesi | Yüzde | Yıllık Kesinti | Aylık Kesinti | Hedef Sektör |
|---|---|---|---|---|
| İki Dokuz | %99,00 | ≈87 saat 36 dak. | ≈7 saat 18 dak. | Küçük ölçekli, düşük kritiklik |
| Üç Dokuz | %99,90 | ≈8 saat 46 dak. | ≈43 dakika | KOBİ, orta düzey kurumsal |
| Üç Buçuk Dokuz | %99,95 | ≈4 saat 23 dak. | ≈21 dakika | E-ticaret, SaaS platformları |
| Dört Dokuz | %99,99 | ≈52 dakika | ≈4 dakika | Finans, sağlık, kamu altyapısı |
| Beş Dokuz | %99,999 | ≈5 dakika 15 sn. | ≈26 saniye | Kritik altyapı, telekomünikasyon |
Beş dokuz hedefi cazip görünse de bunu sürdürmek gerçek zamanlı yük devretme (failover), aktif-aktif veri merkezi mimarisi ve saniye düzeyinde izleme gerektirir; dolayısıyla maliyeti katlanarak artar. Google Workspace ve Microsoft 365 gibi büyük sağlayıcılar genellikle %99,9 ile %99,99 arasını garanti eder; ancak bu garantiler hizmet koşullarında ayrıntılı kısımlarla sınırlandırılmış olabilir.
Bir e-posta, teknik olarak teslim edilmiş olsa bile alıcı sunucu tarafından reddedilirse veya spam klasörüne düşerse iş süreçleri açısından teslim edilmemiş sayılır. Bu nedenle kimlik doğrulama başarısı oranı, uptime kadar kritik bir SLA metriğidir.
RFC 7208 olarak standardize edilmiş SPF (Sender Policy Framework), gönderen alan adı adına hangi IP adreslerinin posta gönderebileceğini DNS TXT kaydıyla tanımlar. Yanlış yapılandırılmış bir SPF kaydı — özellikle 10'dan fazla DNS araması içeriyorsa (PermError) — meşru iletilerin %100'ünün reddedilmesine yol açabilir. RFC 6376 ile tanımlanan DKIM (DomainKeys Identified Mail) ise mesaj başlığına kriptografik imza ekler; anahtar rotasyonu unutulduğunda veya 1024-bit gibi yetersiz anahtar uzunluğu kullanıldığında imza doğrulaması başarısız olur ve teslim oranları ani düşüş yaşar.
DMARC (RFC 7489) bu iki mekanizmayı politika katmanıyla birleştirir. p=reject politikası aktifleştirilmeden önce en az 30 günlük DMARC aggregate raporu izlenmesi, Google Postmaster Tools ve Microsoft SNDS (Smart Network Data Services) gibi araçlardan geri bildirim alınması önerilir. Aksi takdirde meşru bir gönderim kaynağı atlanmış olabilir ve politika devreye girdiği anda bu kaynaktan gelen tüm iletiler silinir.
RFC 5321, Section 4.5.4.2, bir MTA'nın iletim denemelerini en az beş gün boyunca sürdürmesini tavsiye eder; ancak bu, gecikmeli teslimi meşrulaştırmak için değil, geçici hataları (4xx dönüş kodları) tolere etmek için tasarlanmıştır. Kurumsal SLA perspektifinden bakıldığında:
Postfix, Exim veya Microsoft Exchange gibi MTA'larda kuyruk derinliği ve gecikme metrikleri Prometheus exporter'ları veya SNMP traps aracılığıyla Grafana panolarına aktarılabilir. Gerçek zamanlı görünürlük olmadan SLA ihlalleri saatlerce fark edilmeyebilir.
Dört dokuz veya üstünü hedefleyen kurumlar için tek bir veri merkezine bağımlı mimari yeterli değildir. Yüksek erişilebilirlik için benimsenmesi gereken yaklaşımlar şunlardır:
SLA taahhüdü vermek kadar onu ölçmek ve raporlamak da önemlidir. Yaygın kullanılan ölçüm yöntemleri arasında sentetik izleme (synthetic monitoring) öne çıkar: belirli aralıklarla test mesajları gönderilir, uçtan uca teslim süresi ve başarısı kayıt altına alınır. Zabbix, Datadog, Nagios ve Checkmk gibi araçlar SMTP ve IMAP servis kontrollerini nativ olarak destekler. Bunların yanı sıra Google Postmaster Tools, gönderen itibarı (sender reputation) ve spam oranı gibi alıcı taraf verilerini ücretsiz sunar; Microsoft'un benzer aracı olan SNDS ise Hotmail/Outlook ağlarında IP itibarını izler. Bu iki kaynak, üçüncü taraf perspektifinden teslim kalitesini değerlendirmek için birbirini tamamlar.
SLA ihlali tespit edildiğinde reaktif müdahalenin hızı, toplam kesinti süresini doğrudan belirler. Kurumsal ortamlarda olgunlaşmış bir eskalasyon matrisi şu katmanları içermelidir: Birinci katmanda operasyon merkezi (NOC) veya görevli sistem yöneticisi anlık uyarıları alır ve beş dakika içinde ilk müdahaleyi başlatır. On beş dakika içinde sorun çözülmezse ikinci katmana — e-posta altyapısı uzmanına — yükseltilir. Otuz dakikayı aşan kesintilerde CTO veya BT direktörü bilgilendirilir ve iş sürekliliği planı (BCP) devreye girer. Bu prosedürün yazılı olması, tatbikat yapılması ve SLA belgesiyle birlikte muhafaza edilmesi gerekir.
Web sitesi SLA'sı genellikle HTTP(S) yanıt süresi ve erişilebilirliğiyle sınırlıdır. E-posta SLA'sı ise SMTP iletimi, IMAP/POP3 erişimi, kimlik doğrulama (SPF, DKIM, DMARC) başarısı ve uçtan uca teslim gecikmesini kapsayan çok boyutlu bir yapıya sahiptir.
Kesin rakam altyapı tercihine göre değişse de dört dokuz hedefi genellikle yedekli veri merkezi, aktif-aktif MTA kümesi ve gerçek zamanlı izleme gerektirdiğinden toplam sahip olma maliyeti (TCO) iki ila dört kat artabilir. Bu nedenle iş gereksinimlerini analiz etmeden yüksek SLA taahhüdüne geçilmemesi önerilir.
RFC 7489 uyarınca uygulanan p=reject politikası, doğrulanmamış iletilerin alıcı sunucu tarafından silinmesine neden olur. Eksik veya hatalı yapılandırılmış DKIM/SPF nedeniyle meşru iletiler de bu kapsamda değerlendirilebilir; bu durum fiilen teslim SLA'sını sıfıra düşürür. DMARC geçişi öncesinde aggregate raporların en az 30 gün izlenmesi zorunludur.
Evet, ancak yalnızca alıcı taraf için. Birincil MX sunucusu yanıt vermediğinde gönderen MTA, RFC 5321'e göre daha düşük öncelikli MX kaydına yönelir. Bu mekanizma gelen e-postaların kaybolmasını önler; ancak giden trafik için ayrı bir yük devretme stratejisi gereklidir.
Evet. Büyük sağlayıcıların sunduğu SLA, altyapı katmanını kapsar; kurumun iç iş süreçleri, özel uygulamalar ve entegrasyonlar bu SLA'nın dışında kalır. Sağlayıcı SLA'sı ile uçtan uca iş süreci SLA'sı birbirinden bağımsız olarak tanımlanmalı ve izlenmelidir.
Açık kaynaklı çözümler arasında Zabbix, Nagios ve Checkmk SMTP/IMAP kontrollerini nativ olarak destekler. Ticari seçenekler arasında Datadog, Dynatrace ve New Relic öne çıkar. Alıcı taraf itibar izlemesi için Google Postmaster Tools ve Microsoft SNDS ücretsiz ve değerli kaynaklardır.
İç ağ iletimi için 30 saniye, dışarıya giden iletim için 5 dakika yaygın kabul gören eşiklerdir. Ancak bu değerler sektör, mesaj hacmi ve alıcı sunucu politikalarına göre esneyebilir. SLA belgesinde "p95 teslim süresi" (yüzde 95'lik dilimde teslim süresi) gibi istatistiksel ölçütlerin kullanılması ortalamaya göre daha güvenilir bir taahhüt sağlar.
RFC 7208'e göre SPF değerlendirmesi en fazla 10 DNS araması (lookup) içerebilir. Bu sınır aşıldığında değerlendirme sonucu "PermError" olur ve alıcı sunucu politikasına bağlı olarak iletiyi reddedebilir. Özellikle birden fazla üçüncü taraf servis (CRM, destek sistemi, pazarlama aracı) SPF kaydına eklendiğinde bu sınıra kolayca ulaşılır; düzenli SPF denetimi SLA devamlılığı için zorunludur.
Proofpoint, Mimecast veya Barracuda gibi bulut e-posta geçitleri ek bir güvenlik ve filtreleme katmanı ekler. Bu katmanın kendine ait SLA'sı bulunur ve zincirdeki herhangi bir halkada yaşanan kesinti uçtan uca SLA'yı olumsuz etkiler. Geçit sağlayıcısının SLA koşulları, kurumun kendi taahhütleriyle uyumlu olmalıdır.
KOBİ'ler için %99,9 (üç dokuz) hedefi, makul maliyet ve yeterli güvenilirlik arasında dengeli bir başlangıç noktasıdır. Bu seviye yıllık yaklaşık 8 saat 46 dakika planlı veya plansız kesintiye izin verir; yedekli MX kaydı, temel SPF/DKIM/DMARC yapılandırması ve günlük yedekleme ile desteklendiğinde büyük çoğunluk için yeterli olur.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.
Kurulum + migrasyon ücretsiz. KVKK uyumlu, Türkiye'de barındırma. 7/24 Türkçe destek.
Kampanya 30 Haziran'a kadar geçerlidir.