Teknik·
25 Mart 2026
Bir e-posta kampanyasının başarısı yalnızca içerik kalitesine bağlı değildir; mesajların alıcı kutusuna ulaşıp ulaşmadığı, gönderim hızı ve sunucu kararlılığı en az içerik kadar belirleyicidir. E-posta sunucunuzun performansı düştüğünde gönderimler gecikir, IP itibarı zedelenir ve teslim oranları hızla çöker. Bu rehber, sunucu performansını somut metriklerle nasıl ölçeceğinizi ve sistematik biçimde nasıl optimize edeceğinizi açıklamaktadır.
Sunucu performansını değerlendirmek için önce hangi metriklerin ölçüleceğini netleştirmek gerekir. Sektör standartlarında kullanılan başlıca göstergeler şunlardır:
| Metrik | Tanım | Kabul Edilebilir Eşik |
|---|---|---|
| Teslim Oranı (Delivery Rate) | Alıcı sunucusu tarafından kabul edilen mesaj yüzdesi | %95 ve üzeri |
| Sert Geri Dönme (Hard Bounce) | Kalıcı olarak ulaşılamayan adreslerin oranı | %2'nin altı |
| Yumuşak Geri Dönme (Soft Bounce) | Geçici nedenlerle (dolu posta kutusu, sunucu meşgul) reddedilen mesajlar | %5'in altı |
| Şikâyet Oranı (Complaint Rate) | Spam olarak işaretlenen mesajların alıcılara oranı | %0,1'in altı (Google/Yahoo 2024 kuralı) |
| Kuyruk Derinliği (Queue Depth) | Gönderim bekleyen mesaj sayısı | Anlık trafik hacmiyle orantılı; saatler boyu büyüyen kuyruk sorun işareti |
| Ortalama Gönderim Gecikmesi | Mesajın kuyruğa girişiyle alıcıya ulaşması arasındaki süre | Tipik iş e-postası için <5 dakika |
| Bağlantı Başarı Oranı (Connect Rate) | Hedef MTA'ya (Posta Aktarım Ajanı) başarıyla açılan TCP bağlantılarının yüzdesi | %98 ve üzeri |
Bu eşikler sektörün fiilî pratiklerine dayanır; Google ve Yahoo'nun Şubat 2024'te zorunlu kıldığı yeni gönderen gereksinimleri şikâyet oranı için %0,1 sınırını resmi hâle getirmiştir.
Sunucu performansının en kritik katmanı, alıcı sunucusunun mesajınıza güvenip güvenmeyeceğini belirleyen DNS kayıtlarıdır. Üç standart birbirini tamamlar:
SPF (Sender Policy Framework) — RFC 7208 ile standartlaştırılmıştır. Hangi IP adreslerinin alan adınız adına e-posta gönderebileceğini belirtir. Yanlış yapılandırılmış bir SPF kaydı, meşru mesajların spam klasörüne düşmesine yol açar. SPF kaydı, DNS TXT kaydı olarak yayımlanır; örnek biçim: v=spf1 ip4:203.0.113.0/24 include:connect365.com.tr ~all.
DKIM (DomainKeys Identified Mail) — RFC 6376 ile tanımlanan bu standart, gönderilen mesajlara kriptografik imza ekler. Alıcı sunucu, imzayı DNS'teki açık anahtarla doğrular. 2048 bit anahtar uzunluğu, 1024 bitin yerini almaktadır; büyük alıcı platformlar (Gmail, Microsoft) uzun anahtarları tercih eder.
DMARC (Domain-based Message Authentication, Reporting & Conformance) — RFC 7489 ile tanımlanmıştır. SPF veya DKIM başarısız olduğunda ne yapılacağını (hiçbir şey yapmama, karantinaya alma, reddetme) ve raporların nereye gönderileceğini belirtir. p=reject politikası en güçlü korumayı sağlar ancak önce p=none ile izleme aşamasından geçilmesi önerilir.
DNS kayıtlarınızı doğrulamak için MXToolbox (mxtoolbox.com) veya Google Admin Toolbox gibi araçları kullanabilirsiniz. Hatalı bir kayıt, tüm sunucu optimizasyonunu anlamsız kılar.
Yeni bir IP adresinin itibarı sıfırdan inşa edilmek zorundadır; bu süreç "IP ısınması" (IP warming) olarak adlandırılır. Alıcı sunucular, daha önce hiç görmedikleri IP'lerden yüksek hacimli trafik geldiğinde mesajları otomatik olarak şüpheyle karşılar.
Isınma sürecinde gönderim hacmi kademeli artırılır: ilk hafta yüzlerle başlanır, ikinci haftada binlere çıkılır ve birkaç hafta içinde hedef hacme ulaşılır. Bu süreçte sert geri dönme ve şikâyet oranları yakından takip edilmelidir; oranlar kabul edilebilir eşiğin üstüne çıkarsa hacim artışı durdurulmalıdır.
IP itibarını izlemek için Spamhaus (check.spamhaus.org), Barracuda ve Talos gibi kara liste (blacklist) kontrol servisleri düzenli olarak sorgulanmalıdır. IP'nin herhangi bir listede görünmesi, bir sonraki kampanyadan önce mutlaka çözülmesi gereken kritik bir sorundur.
MTA yazılımı (Postfix, Exim, sendmail veya ticari alternatifler) doğru yapılandırılmadan sunucu kaynakları israf edilir ve gönderimler yavaşlar. Kritik yapılandırma noktaları şunlardır:
Bağlantı havuzu (connection pooling): Alıcı MTA'ya her mesaj için ayrı TCP bağlantısı açmak yerine mevcut bağlantıları yeniden kullanmak (SMTP PIPELINING, RFC 2920) hem gecikmeyi azaltır hem de karşı taraftaki hız sınırlamalarını (rate limit) aşmayı kolaylaştırır.
Eşzamanlı bağlantı sınırları: Büyük alıcı sağlayıcılar (Gmail, Outlook) belirli bir IP'den eşzamanlı açılabilecek bağlantı sayısını kısıtlar. Bu sınırın aşılması geçici redlere (421, 450 SMTP hata kodları) yol açar ve mesajlar kuyruğa yığılır.
TLS şifreleme: STARTTLS (RFC 3207) zorunlu tutulmalıdır. Şifrelenmemiş SMTP bağlantıları hem güvenlik açığı oluşturur hem de bazı kurumsal filtrelerde doğrudan reddedilir. MTA-STS (RFC 8461) ise TLS politikasını DNS üzerinden duyurarak ortadaki adam saldırılarına karşı ek koruma sağlar.
Kuyruk yönetimi: Sürekli büyüyen bir kuyruk, sunucunun gönderim kapasitesini aştığının ya da hedef sunucuların mesajları geciktirdiğinin işaretidir. Postfix'te mailq komutu, Exim'de exim -bpc komutu anlık kuyruk derinliğini gösterir. Otomatik uyarı eşikleri tanımlanmalı ve kuyruk derinliği belirli bir sayıyı geçtiğinde sistem yöneticisine bildirim gönderilmelidir.
Performans sorunlarını geriye dönük analiz etmek yerine gerçek zamanlı izlemekle önlemek, tepkisel yönetimden proaktif yönetime geçişin temelidir. Kullanılabilecek araçlar iki kategoriye ayrılır:
Altyapı izleme: Prometheus ile sunucu metrikleri toplanabilir, Grafana ile görselleştirilebilir. Postfix için postfix_exporter gibi araçlar MTA metriklerini Prometheus formatında sunar. Alternatif olarak Zabbix ve Nagios gibi geleneksel izleme platformları da yaygın kullanılmaktadır.
E-posta teslim izleme: DMARC raporları (rua ve ruf etiketleri), her gün alıcı sunuculardan gelen XML raporlarını toplar. Bu raporlar, SPF/DKIM başarı/başarısızlık istatistiklerini ve hangi IP'lerden ne kadar mesaj gönderildiğini gösterir. dmarcian (dmarcian.com) ve Postmark'ın DMARC Digests gibi araçlar bu raporları insan tarafından okunabilir hâle getirir.
Geri dönme yönetimi: Her sert geri dönme, listeden hemen çıkarılması gereken bir adrese işaret eder. Sert geri dönen adresleri aktif listede tutmak IP itibarını hızla aşındırır. Bounce işleme otomasyonu, bu temizliğin kampanya başlamadan önce yapılmasını sağlar.
Türkiye'de ticari e-posta gönderimleri, teknik performansın yanı sıra yasal çerçeveye de uymak zorundadır. İki temel düzenleme geçerlidir:
6563 sayılı Ticari İletişim ve Ticari Elektronik İletiler Hakkında Kanun (ETK) — Ticari nitelikteki elektronik iletilerin yalnızca alıcının önceden onayıyla gönderilebileceğini hükme bağlar. Her iletide gönderenin kimliği, iletişim adresi ve abonelikten çıkış (ret) seçeneği bulunması zorunludur. Bu kanuna dayanılarak çıkarılan Ticari Elektronik İletilere İlişkin Yönetmelik (son güncelleme: Resmî Gazete, 4 Ocak 2020, Sayı 30998), "ret" bildiriminin en geç üç iş günü içinde işleme alınmasını şart koşar.
6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK) — E-posta adresi kişisel veri kapsamındadır; toplanması, saklanması ve işlenmesi KVKK'ya uygun açık rızaya dayanmalıdır. Kişisel verilerin yurt dışına aktarılması Kişisel Verileri Koruma Kurulu'nun onayına tabidir (Madde 9). Teknik açıdan bu, e-posta listelerinin işlendiği sunucuların konumunun ve veri aktarım akışlarının kayıt altına alınması anlamına gelir.
Uyumsuzluk durumunda Bilgi Teknolojileri ve İletişim Kurumu (BTK) idari para cezası uygulayabilir; ETK kapsamında bu cezalar yüz binlerce Türk lirasına ulaşabilmektedir.
Teslim oranı, alıcı sunucunun mesajı teknik olarak kabul etme yüzdesidir. Ulaşılabilirlik ise mesajın gelen kutusu (inbox) mu yoksa spam klasörü mü olduğuna bakılmaksızın alıcıya ulaşıp ulaşmadığını ifade eder. Bir mesaj teslim edilmiş sayılabilir ama spam klasörüne düşmüş olabilir; bu yüzden her iki metrik ayrı ayrı izlenmelidir.
~all (softfail) yetkisiz kaynaklardan gelen mesajların işaretlenmesini ancak reddedilmemesini önerir. -all (hardfail) ise bu mesajların reddedilmesini belirtir. Yeni bir yapılandırmada önce ~all ile başlayıp tüm meşru gönderim kaynaklarını doğruladıktan sonra -all'a geçmek güvenli bir yaklaşımdır.
Sabit bir zorunluluk yoktur; ancak anahtarın tehlikeye girdiğine dair işaret varsa veya düzenli güvenlik politikası gereği rotasyon yapılıyorsa yenilenmelidir. Bazı kuruluşlar yıllık rotasyon uygular. Anahtar değiştirilirken eski anahtarı DNS'ten silmeden önce yeni anahtarın tüm mesaj akışlarında aktif olduğundan emin olunmalıdır.
Önce neden listeye girildiğini anlamak gerekir: spam şikâyeti, kötü amaçlı yazılım tespiti veya toplu şüpheli trafik olabilir. Kaynak sorun giderildikten sonra ilgili kara listenin kaldırma (delisting) talebini başlatmak gerekir. Spamhaus gibi büyük listeler, kendi web siteleri üzerinden bu süreci yönetmektedir.
En yaygın nedenler şunlardır: eski veya satın alınmış e-posta listeleri, typo ile yazılmış adresler, domain'i kapanan alıcılar ve büyük ekler nedeniyle reddedilen mesajlar. Listenin düzenli olarak temizlenmesi ve yeni abonelik formlarında doğrulama (double opt-in) uygulanması bu sorunu azaltır.
Yüksek hacimli ticari gönderimler için dedicated IP şiddetle tavsiye edilir. Shared IP kullanıldığında aynı IP'yi paylaşan başka bir gönderenin kötü davranışı sizin itibarınızı da zedeler. Düşük hacimli gönderiler için bazı ESP'lerin (E-Posta Servis Sağlayıcısı) iyi yönetilen shared IP havuzları yeterli olabilir.
DMARC raporları, her alıcı sunucunun gönderiminizle ilgili yaptığı kimlik doğrulama işlemlerini XML formatında sunar. dkim=pass ve spf=pass satırları başarılı kimlik doğrulamayı gösterir; fail değerleri ise yapılandırma hatası veya sahte gönderim (spoofing) girişimine işaret eder. dmarcian gibi görselleştirme araçları bu XML'i okuması daha kolay hâle getirir.
Evet. 6563 sayılı ETK gereği ticari elektronik ileti göndermek için alıcının önceden onayı zorunludur. Bu onay, elektronik ortamda alınabilir; ancak ispat yükümlülüğü gönderene aittir. Her mesajda abonelikten çıkış seçeneği sunulması da kanunun açık gereğidir.
Doğrudan bir bağlantı vardır. Mesajlar spam klasörüne düştüğünde açılma oranı görünürde düşer. Gönderim gecikmeleri ise zaman hassasiyeti olan kampanyaların (flash indirim, son gün hatırlatması) etkisini azaltır. Yüksek şikâyet oranı da gelecek gönderimler için inbox yerleşimini olumsuz etkiler.
MTA-STS (RFC 8461), gönderen sunuculara alıcı domain'in TLS şifreleme gerektirdiğini bildiren bir DNS/HTTPS tabanlı politika mekanizmasıdır. SMTP TLS Raporlama (RFC 8460) ise TLS bağlantı başarısızlıklarını raporlar. Bu iki standart birlikte kullanıldığında TLS ile ilgili teslim sorunlarını erken tespit etmek mümkün olur.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.